Bidirectional networks and nodes

[TBeckhoelter]

In the current verison there is no possibility to picture bidirectional networks that uses flow and return for heating and cooling supply. These netwroks consist of different types of substations (heating and cooling, just heating or just cooling demand). Espacially the function to load an uesgraph from json file doesn't support node types for heating and cooling, just heating or cooling. Therefore I would like to implement the new network_type bidirectional and a new node_type supply_bidirectional.

[TBeckhoelter]

Ok, node_type should contain one of the keywords network, building or street, so I should change the new node_type to building_bidirectional.

[TBeckhoelter]

It's a little bit difficult to differentiate between buildings and supplies, as it is done in the current version of uesgraphs. The bidirectional nodes (substations) are both, buildings with demands on the one hand and supplies for heating and cooling, each the opposite of demand, on the other hand. I will figure out an solution for this, for example treat the bidirectional substations as buildings with node_type building_bidirectional.

[marcusfuchs]

@jsc-tbe You write

It's a little bit difficult to differentiate between buildings and supplies, as it is done in the current version of uesgraphs.

Actually, I think that the current version of uesgraphs does not differentiate between buildings and supplies. To my understanding, what we usually call a "building" is just a building node with none of the "is_supply_{}".format(network_type) attributes set to True. In heating or cooling networks, we usually use building nodes with is_supply_heating or is_supply_cooling set to True when we talk about a "supply" node.

In my opinion, this would also be a chance to represent bidirectional low temperature networks. You could just set both is_supply_heating and is_supply_cooling to True. For the network_type, I would just choose heating (as my guess is that more people would consider such a network a "district heating network" rather than a "district cooling network" - that's not ideal, but in my opinion it can work). And then you could have your downstream code interpret this setup according to your needs. Could this approach work for you, maybe without adding new network and node types?

[TBeckhoelter]

@marcusfuchs you are right. Normally the current boolean attributes should last for our needs. But espacially the json export/import function didn't work for the bidirectional case (node_type just heating or cooling).

Maybe I should explain, why I'm doing all these changes here: I'm working on an automated model generation using uesmodel (I forked it, there's no branch - have to change it). To differentiate between all models used in the bidirectional network model I tried to classify them in the following way:

model	is_supply_bidirectional	is_supply_heating	is_supply_cooling
substation heating/cooling	X	X	X
substation heating	-	X	-
substation cooling	-	-	X
plant	X	-	-

In the uesgraph the boolean "is_supply_heating" doesn't have to be declared, we could also use an other arbitrary attribute in attr_dict of the node. But all these cases have to be requested in uesmodel. So I thought we could outsource some common attributes to uesgraph and thus enable it to describe bidirectional networks.

But if you think, uesgraph should stay more general, it would be possible to work just with node attributes from the attr_dict. In this case, I just have to change the json import/export so that the building node can be supply heating and cooling at the same time.

[marcusfuchs]

@jsc-tbe Thanks for the explanation. In my opinion, this is a use case that uesgraphs does not support perfectly. To change that, I think it we would have to fundamentally think about how to represent different network types and the roles of nodes as supplies, demands and prosumers. Unfortunately, this would require quite some effort to get right.

As for your case, you could cover all needed models by only using the is_supply_heating and is_supply_cooling attributes, I would prefer the solution you mention in your last paragraph.