Water Tower Component #107
Conversation
…on=0, h_m=3, name=reservoir)
…e calculation of reservoir
- renamed reservoir in water tower - adaption of create and component - adaption of test
Codecov Report
@@ Coverage Diff @@
## develop #107 +/- ##
===========================================
+ Coverage 90.67% 91.09% +0.42%
===========================================
Files 59 60 +1
Lines 3248 3224 -24
===========================================
- Hits 2945 2937 -8
+ Misses 303 287 -16
Continue to review full report at Codecov.
|
| press = density * (water_towers.height_m.values - node_pit[index_wt, HEIGHT]) * \ | ||
| GRAVITATION_CONSTANT / P_CONVERSION * water_towers.in_service.values |
There was a problem hiding this comment.
@SimonRubenDrauz What exactly is the definition of height_m? My guess was the height of the water column in the tower. However, if the junction's height is subtracted, this could lead to negative height, couldn't it?
I'd find it confusing if height_m was in "meters above sea level" but I do not know the conventions.
As a suggestion, maybe it should be renamed to tower_height_m. A scaling factor could be introduced to derive water_column_height_m which then serves as input for the static pressure (rhogwater_column_height_m)
There was a problem hiding this comment.
It actually should be the height above sea level. But I agree. It really seems confusing. It is a convention in SINCAL. But I would change it in our case taking only the height of the water_column.
There was a problem hiding this comment.
Thanks for the adaption! However, thinking about it twice, maybe this leads to a problem regarding communicating vessels. (see my latest comment.) This could be the reason why Sincal uses absolute height.
|
|
||
| class WaterTower(NodeElementComponent): | ||
| """ | ||
|
|
There was a problem hiding this comment.
Could you add some information on the pictured model and important limitations and assumptions?
It seems to me like an infinite diameter is assumed (no change in water column height on withdraw or feed-in), is that correct?
How does it differ from an ext_grid, apart from the different formulations of pressure, and to which extend does it overlap?
There was a problem hiding this comment.
Yes. I will do so.
There are not many differences compared to a ext_grid. The pressure is determined by the height of the water column. It is assumed that the water tower capacity is unlimited and the height of the water column remains constant, correct!
I agree that we could think of making a new parent component for ext_grid and water_tower. But for now I would leave it like this!
…l, renaming the test and adapting the desciption in the create function.
| press = density * water_towers.height_m.values * \ | ||
| GRAVITATION_CONSTANT / P_CONVERSION * water_towers.in_service.values | ||
| juncts_p, press_sum, number = _sum_by_group(junction.values, press, | ||
| np.ones_like(press, dtype=np.int32)) |
There was a problem hiding this comment.
I am not sure whether this is physically possible. The effect of communicating vessels (dt: "kommunizierende Röhren") is not considered, is it?
I'd suggest limiting the number of water towers to 1 per net or raise a warning when towers with different water height are connected.
|
To me it is a bit questionable whether this component makes sense in this form, especially due to the similarity to the ext_grid that @jkisse mentioned. There are several issues connected to this component:
|
…nvert a water tower into an ext grid
|
Thanks for your feedback. I adapted now everything. What do you think? |
Introducing new component: Water Tower