Is using the 'geometry collection field' for deducing the number of bends the ideal way to count the number of bends?

Hello Phanindra,

The geometry collection field counts the geometry of a particular link/pipe element. This includes the start X,Y; stop X,Y; and the bend X,Y's. Hence the collection number will be always start + end + number of bends. Hence, if the number of bends are say 5; then the geometry collection would be 7.

I am sharing screenshots of an example;

Hope this helps.

Hello Yashodhan,

Thank you for your reply. I understand how geometry collection works. However what I mean to say is that while laying down Cast Iron or Ductile Iron underground piping, we can deflect the pipe upto a 5 degree angle without requiring 'bend' fittings.

Consider the diagram provided below. The junction J-2 and J3 has 22°30' bends. However the point J4 doesnt have a 'bend fitting' but is being deflected by a 5° angle without using any bends. The diagram below is created in AutoCAD. While creating L-section drawings from surveys, a CAD drawing is intially prepared and then is extracted using modelbuilder into Watergems. 

Now I would like to import this entire span from J1 to J5 as a single pipe into WaterGems. Now in this span there should be two 'bends'. However when we import the model in Watergems, and look into the geometry collection, the point (J4 as per the AutoCAD drawing) is also being counted in since there is a defelection in the pipe angle at this point. However in the actual piping model there is no 'bend fitting' at this point.

In short what I mean to say is that all the points that is being counted as a bend in WaterGems may not have an 'actual bend' in the piping model.

In a complex model consisting of several pipes and long spans, at several locations the pipes are going to be 'deflected without using bend fittings'. However if we rely on the 'geometry collection' as a means for counting the number of bend fittings in the pipes, then it may not provide accurate results with respect to the actual piping model. Hence will counting bends by using 'geometry collection' provide a practical solution?

Hello Phanindra,

Thanks for elaborating your query. The geometry as it appears in AutoCAD while laying out your network will be imported as it is in WaterGEMS. Hence when laying a network in AutoCAD if you introduce a deflection of 5 degrees in the AutoCAD polyline it will be recognized as a bend in WaterGEMS.

When importing a DXF, the software will treat the network layout as geometry and import line breaks (WaterGEMS will create nodes on both sides of a line) and bends in a polyline as "bends". When you create a network in AutoCAD only the graphical properties are accounted for. The 5 degree bend can be represented graphically as a deflection but it is not possible for the software to ignore this as a bend.

Also, it should be known that the model prepared in WaterGEMS is a hydraulic model and is representative of your actual system. The geometrical intricacies are generally accounted for hydraulically. In your case you can define the minor loss due to the 5 degree bend by specifying the coefficient or you can add the 5 degree bend loss in the library to use it for multiple pipes.

One more alternative for this is identifying pipes with the 5 degree deflection in AutoCAD by adding a property field (maybe as a special name like PIPE_5 degrees). Then you can filter out those pipes while importing the DXF and create your network. After network is created you can model these pipes manually.

Here are some articles which can help you;

Importing an AutoCAD or MicroStation CAD file using ModelBuilder

Using ModelBuilder to Import External Data

Hope this helps.

Hello Yashodhan,

Thanks for your reply. I totally agree to what you said regarding geometrical intricacies being accounted for hydraulically. Hence I think rather than accounting for the number of bends 'geometrically' it is more practical to account them 'hydraulically' as far as WaterGems/Hammer is concerned. In case of a complex model consisting of several pipes, I generally prefer doing so by considering a marginally higher pipe roughness or by considering a 10% increase in headloss (as often stated by Tom Walski and Tanay Kulkarni elsewhere in this forum) so as to simplify the process.

However estimating the number of bends used in the actual piping model using 'gemoetrical collection' in WaterGems may not always render an accurate estimate.

However sometimes Clients do want to know the number of bends and related diameters utilised in the model. In future updates if a separate field can be introduced where the user can manually enter the number of bends and friction factor explicitely (as per actual piping model) associated with each pipe and the same is reflected in the flextables and hydraulic inventory report (alongwith the respective diameter), then may be it can prove to be an additional helpful feature.

Alternatively, an enhancement can be made in future updates such that the number of fittings and their types can be specified by the user in the 'minor loss collection items' field for relevant pipes. Then this data can be reflected in the hydraulic inventory report based on the associated pipe diameter. For example, the user can associate tees, bends etc for relevant pipes. They can later access the hydraulic inventory report to get a list of the total number of fittings used based on the relevant pipe diameters those fittings have been associated with.

Hello Yashodhan,

Thanks for your reply. I totally agree to what you said regarding geometrical intricacies being accounted for hydraulically. Hence I think rather than accounting for the number of bends 'geometrically' it is more practical to account them 'hydraulically' as far as WaterGems/Hammer is concerned. In case of a complex model consisting of several pipes, I generally prefer doing so by considering a marginally higher pipe roughness or by considering a 10% increase in headloss (as often stated by Tom Walski and Tanay Kulkarni elsewhere in this forum) so as to simplify the process.

However estimating the number of bends used in the actual piping model using 'gemoetrical collection' in WaterGems may not always render an accurate estimate.

However sometimes Clients do want to know the number of bends and related diameters utilised in the model. In future updates if a separate field can be introduced where the user can manually enter the number of bends and friction factor explicitely (as per actual piping model) associated with each pipe and the same is reflected in the flextables and hydraulic inventory report (alongwith the respective diameter), then may be it can prove to be an additional helpful feature.

Alternatively, an enhancement can be made in future updates such that the number of fittings and their types can be specified by the user in the 'minor loss collection items' field for relevant pipes. Then this data can be reflected in the hydraulic inventory report based on the associated pipe diameter. For example, the user can associate tees, bends etc for relevant pipes. They can later access the hydraulic inventory report to get a list of the total number of fittings used based on the relevant pipe diameters those fittings have been associated with.

Hello Phanindra,

The feature to identify minor losses is already available in WaterGEMS. You can specify multiple types such as 45 degree, 90 degree bends, contractions, expansions etc. with their numbers and coefficients by directly importing from the library or specifying as per your requirements. Just keep the "Specify Local Minor Loss" field as "False" and specify each type of minor loss in the "<Collection>" in the "Minor Losses" property for a pipe.

Calculating the number of bends as N-2 (-2 is for deducting start and end nodes) can be used for pipes. However, for DI pipes you have a 5 degree bend which is not actually a bend.

Wen you draw a pipe connecting two points in AutoCAD, with the 5 degree bend AutoCAD will recognize it as a bend too. The 5 degree bend not being a bend is a property for the DI pipe but for AutoCAD or WaterGEMS its a graphical entity. Hence, it will always be imported as a bend.

Using fittings and other appurtenances is a  part of detail engineering. For large projects it would be a cumbersome job to detail each pipe with these components. The hydraulics of these can be accommodated by either increasing the pipe length by 10% or by specifying minor losses in detail.

Hope this helps.

Hello Yashodhan,

Thanks for your patient reply. I am presently working on a transmission pipeline of around 6.8 km for a Sri Lankan Project. The L-Section model and the BOM of the entire pipeline has already been prepared for the entire system. The Client wants us to account for the losses of all the fittings individually in the WaterGems/Hammer model. It is their standard practise to incorporate as much details in the hydraulic model as possible. Hence I already have to manually take care of all the fittings in the system by specifying the friction factors and fittings quantity in the 'minor loss collection items' field for relevant pipes. It is as you said a 'cumbersome job' but it has to be done in this case because the Client requires it and technically is not ready to accept otherwise. Moreover, they would also want us to specify the number of fittings being associated with the pipes of different diameters in the WaterGems model and then would compare that data with the data available from the BOM of the actual piping system. So basically we have to create a 'Fittings table' alongwith the model manually and hand it over to them.

I have faced this issue with another Client previously as well. This is the reason why I was mentioning if this situation can be solved by providing any enhancement in any future update. 

Phanindra,

ModelBuilder could be used to help with the reporting. You can use it to export all minor losses to a spreadsheet (for example) to be able to report all fittings in a model. See: Reporting Details of Fittings (Minor Losses) for Each Pipe

Hey Jesse,

Well, this was extremely helpful. Thanks a lot. This would be saving me a lot of hassle.