Closed JorritvandenHouten closed 1 year ago
De NetNode agents zouden een transport-verlies in rekening kunnen brengen, bij de elektriciteits-nodes zou dat verlies een factor op het doorstromend-vermogen (v_currentLoadElectricity_kW) zijn. Dit werkt vooral als je de node als een station ziet waar stroom doorheen gaat van de subConnections naar de superConnection(s).
Voor een warmtenet zou dat anders moeten werken; daarbij telt inderdaad de fysieke lengte van het net, de watertemperatuur en de isolatiewaarde, en niet zozeer het warmtevermogen dat er doorheen stroomt. Bovendien sluiten we nu alles aan als een subConnection, dus heeft de netNode zelf als het goed is altijd een v_currentLoadHeat_kW = 0 (want energiebalans).
Moeten we dan een temperatuur van het water in het net in acht nemen, en daar het verlies van laten afhangen? En hoe komt die verlies-term terug in de totale warmtebalans van het warmtenet? (die warmtebalans 'lossen we nu op' aan de kant van de warmteproducent+buffer)
De GridNode Heat heeft nu een EA_StorageHeat object, waarvan de temperatuur de temperatuur van het water in het warmtenet vertegenwoordigt. Dit StorageHeat object zorgt ook voor de warmteverliezen in het net. De energie-balans van de GridNode Heat kan nu non-zero zijn, en die 'onbalans' gaat het StorageHeat object in, waardoor dus de temperatuur van het warmtenet ook verandert. Warmte toevoer vanuit de districtHeating GridConnection is nu een functie van temperatuursverschil tussen de warmtebuffer van de districtHeating GridConnection en de temperatuur van het warmtenet, via een warmteoverdrachtscoefficient. De districtHeating GridConnection hoeft dus geen 'kennis' te hebben van de totale warmteafname van het warmtenet.
Warmtenet-afnemers en producenten (ook NetConnection-agenttype, categorie District Heating) connecten nu via agentlinks aan een heatnode. Het warmtenet zelf heeft daarbij nog geen fysieke representatie. Dit is denk ik wel nodig voor berekening van bijv. warmteverliezen en kosten.