Click on your picture in the top right corner, go to Preferences and select your notification preferences.
Please keep in mind:
1. To only comment on the topic where the discussion is about. Do you have a new question or topic? Please start a new discussion.
2. Be kind to other users!
Pump direction
I've made a large scale water system validation tool that corrects and validates a lot of geometry elements for entire watersystems. Part of this are the pumps. What they need to do is correctly connect two different water bodies. Usually (in NL) they exist as points but using this method I end up with a line in the exact water body I need the pump to be. This results in constructions like this:
The problem however is that I can't dictate the direction. What Tygron does is it looks on both sides of the pump what the water level is and assumes it always goes from the lowest to the highest water level area. In this case I however have one pump which connects two water level areas with the exact same water level. The "autopick" of the pump direction goes the wrong way. I do however know exactly what direction the pump functions and works using the water system network.
My reasoning was that I can use the water system network to dictate the pump angle. This however results in a completely new error. Namely that it completely ignores the existing geometry. Both of the examples below have the exact same geometry as above but only get the weir angle attribute added. (top one is 120 ish, bottom is 270)
The above pump suddenly has a completely different function and longer calculates between the two waterbodies that it's connected to. The blow one does function as I would like it to based on the angle but it's more by chance that the geometry is still somewhat valid (tried this on dozens of pumps, almost all completely break down their function like the top one).
Now the question: How can I dictate the pump direction without destroying the geometry? Angle destorys it and won't make my system work at all. Changing the water level of the upstream part does work but isn't accurate.
Comments
Hi Len,
The Water Overlay begins with the principle that constructions like culverts, weirs, and pumps connect 2 cells. Ideally, a construction is line-shaped, so that the endpoints of that line can be used to determoine which cells are connected.
If the shape of the construction does not match a sensible line (e.g. a point, as is much the case with datasets we've seen), the Water Overlay offers the option to set an angle. The software will then, from the centrepoint of the polygon, redefine a line with 2 endpoints which can be used. The key part here is that by definition, setting an angle effectively ignores the shape of the polygon which represents the pump.
Since you already have appropriate polygons with appropriate endpoints, you needn't set an angle. Instead, you can change the pump direction by making the PUMP_Q value negative. https://support.tygron.com/wiki/Pump_q_(Water_Overlay)
Regards!
Sprawling spreadsheets so intricate Alexander the Great cuts them in half.
This behaviour matches with what I expected. Since I'm working with very large models a manual check for each pump if it's going in the right direction is not reasonable. So I have to understand the logic of how Tygron picks the pump direction so I can automate the adjustments. Your answer doesn't completely answer the question unfortunately. I do know for sure now that the "angle" route is not the way to go, which I expected.
As described above in this part the issue is a bit different: "The problem ... the water system network."
So the case is the following:
For the workaround I know I can use the negative pumping rate. But I do need to know where the negative should be applied. In my example Tygron 'picked' wrong. But might've well picked correctly, depending on the actual logic behind it. In my example the wrong direction making the entire system clog up.
Another workaround is changing the water level in the water level area where it should go to and add + 1 cm water level to it. This would make it the highest and make Tygron 'pick' correctly. Although this can work, the downside is that in other location it might also change and I'm effectively making the data incorrect.
Hi Len,
for the situations where both sides are equal, we currently do not provide an explicit handle on which side will be which for the pump. For that certainty, changing the WATER LEVEL of one side for even a tiny bit can ensure the right direction is enforced.
However, after doing a quick test, for your case you may find a handle in the computed SkeletonLines of the pumps, These are computed by the Platform based on the construction's polygon, and cannot be directly defined. However, it seems that when both sides of the construction are equal, the pump's default direction will be from the first skeletonline coordinate to the last skeletonline coordinate. If you wish to explore this route I urge you to double-check this behavior, also with your larger dataset. However, if you can verify this behaviour to your satisfaction, this may suit your needs.
You can find this property only via the API. The Pump is a Construction, which as a "sections" property. Each "section" has both a polygon (which is the polygon which defines the Construction's location), and a "skeletonLine", which is the centre line which in this case the Platform uses for interpreting the Construction as a line structure.
Regards!
Sprawling spreadsheets so intricate Alexander the Great cuts them in half.
That was the hint I was looking for! I expected there to not be a specific rule for both being equal but likely still a logic (i.e. drawing direction of the line). Polygons do not have a drawing direction but the skeleton line indeed should. I'm very familiar with the skeleton line and used it for multiple other applications before. Great to know that this (might) be the fall back logic.
I should be able to work with this as a route and identify, only for the equal water level pumps, if they should be negative or positive based on the line direction.
Thanks!