Naming and handling of input data can be improved

[jakob-wo]

When I went trough the example _import_exportplot it took me a moment to fully understand the logic of the imput data.

1)_Naming

• consumers.csv, forks.csv, and producers.csv hold the geo-positions of the consumers, the splitters, and the heat producers, respectivly.

• edges.csv holds the technical specifications of the heat pipes and specifies what they connect.

I suggest to change the names to be more specific:

• consumers_positions.csv (because it does not specify the consumer itself)

• splitters_positions.csv (the node_type is split, why not call the file the same way?)

• producers_positions.csv

• pipe_specs.csv (Edge is a mathematical term but has no meaning in the context of district heating. Also, this file is the only one not holding geo-positions but actually specifying a physical component)

2)_Handling

It would be very convenient to have the posibility to use tags or unique names for specific nodes. To specify the _fromnode and/or _tonode (in edges.csv) it would be great if one could enter _'centralpp' for the central power plant instead of producer-06 (or whatever position in the producers list the central power plant has). That could be some nice gadget in the future :)

3)_

One general question regarding this example: The input and the output files are identical. That would not realy make sense in a real application... What kind of workflow regarding the input data would I use in a real application? Would I fill in the geo-position lists (csv files) manually?

[jnnr]

1) Naming Good remark. Specific names are useful. However, the files are designed to generally hold more information than just the geopositions. 2) Handling You can do that already, I just tried locally and renamed the id of the producer from 0 to 'power-plant'

Regarding the general question: This is true and due to the fact that the models are not implemented yet. As soon as we have real results, these files will be updated. At the moment, the serve as a sketch for how the results can look like.

The last point: The geocoordinates can be filled in manually, or imported from another source. E.g., there is an example for importing from osm. Other ways of importing can be defined later.

[jnnr]

Hey @jakob-wo, I hope I could answer your questions? Are there any things still open? Is there something that we can draw from this issue, maybe a short extra text to the docs?

[jakob-wo]

I hope I could answer your questions?

@jnnr yes, you did! Thank you.

I have two further questions regarding the Naming-Part:

1. What other information than geodata is consumer.csv going to hold? (I am just curious)

2. With your answers I realize most of my renaming suggestions does not make sense. But one is still open: edges --> pipes. What do you think about that? Is edges.csv going to hold/specify anything else but pipes?

maybe a short extra text to the docs?

Well, I think in the end it would be nice to have a short description (maybe even a visualisation) of the workflow. Or if there is no such think as the workflow, it could be about the typical or some possible workflows.

[jnnr]

1. What other information than geodata is consumer.csv going to hold? (I am just curious)

We will provide some more detailled benchmark examples/tests for the simulation. I will assign you as a reviewer so you can see.

2. With your answers I realize most of my renaming suggestions does not make sense.
   But one is still open: _edges_ --> _pipes_. What do you think about that? Is edges.csv going to hold/specify anything else but pipes?

I think this is a good idea. I did not call it pipes in the beginning, as it is not a single pipe but mostly two of them. But now I think that pipes is a good general term. It is also energy system specific, as the others component names.

maybe a short extra text to the docs?

Well, I think in the end it would be nice to have a short description (maybe even a visualisation) of the workflow. Or if there is no such think as the workflow, it could be about the typical or some possible workflows.

This is on its way in #36 and #37. If you have time, we are happy if you can give a review!

[jnnr]

I opened a new issue for the pipes and close this. Protest if you disagree, @jakob-wo :)