oemof / DHNx

District heating system optimisation and simulation models
MIT License
27 stars 12 forks source link

Features/update naming #43

Closed MaGering closed 3 years ago

MaGering commented 4 years ago

With this PR the naming is adjusted from 'edges' to 'pipes' as suggested in issue https://github.com/oemof/DHNx/issues/38

jnnr commented 3 years ago

Should add in components.csv's description that pipes have a defined direction.

joroeder commented 3 years ago

it seems that sometimes edges is sometimes more appropriate, e.g. if you do this logical distinction that edges are pipes before everything (like flow direction, capacity) is defined, then, I am wondering about the optimization part. There, in this sense, you have pipes only after the optimization. Before, these are kind of “potential” pipe locations. And in a mashed grid with multiple producers, there can be different load states and flow directions as well. So, I am not sure, if the flow direction should be a must-have for pipes. But, at the moment, I do not have a good idea how to handle. Maybe we need two network attributes: edges and pipes?

jnnr commented 3 years ago

it seems that sometimes edges is sometimes more appropriate, e.g. if you do this logical distinction that edges are pipes before everything (like flow direction, capacity) is defined, then, I am wondering about the optimization part. There, in this sense, you have pipes only after the optimization. Before, these are kind of “potential” pipe locations. And in a mashed grid with multiple producers, there can be different load states and flow directions as well. So, I am not sure, if the flow direction should be a must-have for pipes. But, at the moment, I do not have a good idea how to handle. Maybe we need two network attributes: edges and pipes?

The idea of this PR is to rename edges to pipes because that name is more concrete. At some places in functions that handle networkx graphs I decided that it is more natural to keep talking of edges, as the function is more abstract (see the last commits).

What you propose is to use the two terms, edges and pipes, to discriminate beetween potential pipes and existing pipes. I would like to call them one of the two, edges or pipes. As we discussed this in an issue and there were no objections for quite a while, I would like to stay with 'pipes'.

Then we indicate the distinction of presence or not by setting the attribute 'pipe_type', 'capacity' to None and 0 if it does not exist and some value if it exists. See #44.

joroeder commented 3 years ago

What you propose is to use the two terms, edges and pipes, to discriminate beetween potential pipes and existing pipes. I would like to call them one of the two, edges or pipes. As we discussed this in an issue and there were no objections for quite a while, I would like to stay with 'pipes'.

Okay, let's do it this way.