Features/tespy simulation

[jnnr]

Adds some facade classes and examples to use tespy for district heating simulations.

• tespy_facades.py: Facades that create tespy components and connections in the background,
• minimal_example.py: A minimal (1 - pipe) example for a network,
• an example tespy_simple_pipe_calculations.py that is benchmarked against a previously written example simple_pipe_calculations.py

Still missing:

• match Hazen Williams roughness to Colebrook White (might be useful: https://www.researchgate.net/publication/245297444_Relationship_between_Hazen-William_and_Colebrook-White_Roughness_Values)
  Comment: It seems like the implemented lamb(re, ks, d) already matches the formula I used in the simple_pipe_calculations.py. Only difference is the parameter for the pipe's roughness. Before, I used the absolute roughness epsilon. Tespy uses the equivalent sand grain roughness. It seems that they are defined differently, but in some cases, they can be assumed to be equal. Until now I did not find a good source that clearly explains the differences in the definition.

• match area independent kA value to U value depending on area
  My previous calculations used the U-value (sometimes called k). To get the area independent heat transfer coefficient kA, I just multiplied by the area.

• setup a network builder

• Allow solving for many timesteps

• retrieve results

• benchmark simple tree-like networks.
  Update: As the representation of looped networks is not straightforward in tespy, we will start with tree-like networks and address the issue of the looped ones in the future.

[fwitte]

Hey @jnnr,
I was just scrolling through this. Instead of

match area independent kA value to U value depending on area

you could easily implement a new equation for the pipe component using ambient temperature, the pipe's and the insulation's dimensions and material as well as the material of the underground to model thermal losses. Just let me know, if you need any assistance :). Also, there is work going on (or has been at least) on a district heating pipe (oemof/tespy#95).
Have a nice sunday!

This could be helpful: https://www.schweizer-fn.de/waerme/waermeleitung/waermeleitung.php#wsrohr, https://www.schweizer-fn.de/waerme/waermeleitung/waermeleitung.php#wserdrohr, https://www.schweizer-fn.de/berechnung/waerme/rohrisol/rohrisol_start.php

[jnnr]

Hey @fwitte, thanks for your message. Good that you point to that. I will have a look at how to implement new equations in tespy and definitely ask for help if necessary :) Could the same be done (adding an alternative equation) with the Colebrook-White formulation of the pipe's roughness?

[fwitte]

Yes, that would be no problem. Colebrook-White is already implemented as standard function: https://github.com/oemof/tespy/blob/dev/tespy/tools/helpers.py#L291-L417. It is used for Reynolds > 2300 and Re*ks/D > 1300.

For other cases of turbulent flow different equations are applied, that (to my knowledge) provide better values for their specific case. However, I checked the differences and the results are very similar. For laminar flow a different equation is applied.

The Hazen-Wiiliams implementation of pressure loss calculation is very different and specific to water only.

If you want to add a new equation to a component, for example the pipe's energy loss, copy the methods "additional_equations" and "additional_derivatives" to the pipe class and add your equations and the corresponding derivatives there.

[jnnr]

Yes, that would be no problem. Colebrook-White is already implemented as standard function: https://github.com/oemof/tespy/blob/dev/tespy/tools/helpers.py#L291-L417. It is used for Reynolds > 2300 and Re*ks/D > 1300.

I plotted tespy's lamb function against the formulations I have been using before, and found that they match quite well.

One source of confusion was the definition of the pipe roughness. In my previous calculations, I used the 'absolute roughness', epsilon. Tespy uses the 'equivalent sand grain roughness', ks. It seems that these two are defined differently, but under certain conditions, they can be assumed to be equal. Until now I did not find a good source that clearly explains the differences in the definition. However, this page gives a hint about the difference:

http://daad.wb.tu-harburg.de/tutorial/flood-probability-assessment/hydrodynamics-of-floods/1d-hydrodynamic-models/example/building-up-the-1d-model/equivalent-sand-roughness/

[fwitte]

One source of confusion was the definition of the pipe roughness. In my previous calculations, I used the 'absolute roughness', epsilon. Tespy uses the 'equivalent sand grain roughness', ks.

It is called ks, but it is indeed the absolute roughness, I think:

I had a look at the VDI-Wärmeatlas. There epsilon is 'relative roughness' just as stated here (https://en.wikipedia.org/wiki/Darcy_friction_factor_formulae). Thus, the Colebrook-White equation uses the absolute roughness. Data are provided in the VDI Wärmeatlas as well or for example here: https://www.schweizer-fn.de/stroemung/rauhigkeit/rauhigkeit.php. Going through the schweizer-fn site, they write about the equivalent sand roughness while the values are identical to the absolute roughness of the VDI Wärmeatlas. The values used in the examples of tespy are within the VDI range, so no adjustments are required there. I will stick to the VDI Wärmeatlas. Maybe the documentation needs an update. As renaming the parameter to k instead of ks would bring a major release, I am not sure, how long I will stick with the old parameter... :D

I added additional equations besides the Colebrook-White equation as the advantage is the explicit formulation.

[fwitte]

Another input from my perspective regarding the looped networks:

It would be really great, if we could get this to work with TESPy. The issue with looped networks is, that the amount of energy balance equations (!!!) at a node of the network (merge or splitter) depends on the flowing direction of the fluid. Therefore, if the flow direction changes within the solution process, the network might get over- or under-determined. I have implemented a workaround using the component node, but this is not working consistently, yet (I think at least). I have another idea, how to tackle this issue, but due to other priorities I did not implement it.

Please let me know, If you are having any trouble with a specific case. I might be able to use that case and test the idea I have in mind.