Hi
I had seen a similar issue on the forum but the information did not help with my issue- communities.bentley.com/.../98342. My model was working but now has this error -
Error 51007 - Pipe/channel network must end with an outfall node. Add an outfall to downstream end of network that includes elements: CH_MH_00681; CH_MH_00572; CH_MH_00555.
Source: Hydraulic Results
These manholes are in the model and connected to a pump station. I am not sure what issue has occurred to make this model fail.
Thanks
Lee
If that forum post didn’t help you then , please upload your model so that we can look into the issue.
There are two options for sharing your model files on BE Communities. If you would like the files to be visible to other members, compress the files into a zip file and upload them as an attachment using the ‘Advanced Reply editor’ before posting. If your data is confidential, you can follow the instructions in the link below to send it to us via Bentley Sharefile. Files uploaded to Sharefile can only be viewed by Bentley.
Be Communities Secure File Upload
If you do upload the file to Sharefile, please post here as well so we know the file was uploaded.
Regards,
Sushma Choure
Bentley Technical Suppport
Jesse DringoliTechnical Support Manager, OpenFlowsBentley Communities Site AdministratorBentley Systems, Inc.
Lee,
What version of SewerGEMS are you using? You can check under Help > About SewerGEMS. The latest is 08.11.04.54.
Changes that you make to an attribute that is stored in a child alternative should not change the base alternative. You shouldn't have any problems with this, so it may be best to take a look at a copy of the model that exhibits this problem. You can either zip and attach it to this forum post using the Advance reply Editor, or submit it privately using the process in the below link. Please include with this the exact steps needed to be taken to observe the problem.
http://communities.bentley.com/p/bentleysecurefilesupload
Without seeing the model, here are two possible reasons why a change in one scenario may seem to reflect in a parent scenario:
1) The attribute that you are changing are stored in a different alternative - one that is used by both scenarios. If in doubt of what alternative a certain attribute is stored in, open one of the alternatives from the alternatives manager, then check the tab corresponding to the element type in question. If the attribute is not seen as a column, then it is stored in a different alternative.
2) You are adding and/or removing elements to your model and the two scenarios in question are using two different Active Topology alternatives (one the child of the other). The presence or absence of an element in a particular scenario is not controlled by any alternative; when an element is added, it is present in all scenarios. However, you can use the Active Topology Alternative to control whether an element is active or inactive.
The key here is that, by default, newly created elements are only set as active in the active topology alternative assigned to the current scenario. New elements will initially have a setting of "false" for "is active?" for all other active topology alternatives. For example a typical workflow may be to create a child active topology alternative for a "future conditions" scenario and lay out a new subdivision for example in the new scenario with the child active topology alternative. Those new elements will be active in that scenario, but will be inactive in the other scenario with the parent active topology alternative (the present conditions scenario where those pipes are not yet in place). SewerGEMS has always has always worked this way. An example of this is shown in the below Support Solution:
http://communities.bentley.com/products/hydraulics___hydrology/w/hydraulics_and_hydrology__wiki/active-topology-management
Again, without seeing the model, it's difficult to tell for sure, but it's possible that in your case, you may have split a pipe when adding the new elements. Meaning, there may have been a single pressure pipe in the parent scenario, which was split into two pipes when placing a new
In this case, the new node element that was added (that split the pipe) will default to being inactive in the parent active topology alternative as mentioned above. The two adjacent pipes would no longer be connected to an active element (as if they did not have an end node) causing the upstream elements to be physically disconnected from the downstream outfall, hence the red user notification "Pipe/channel network must end with an outfall node..."
See animation further below to show this in action.
You can avoid this situation by connecting the new pipe to an existing node instead of splitting a pipe and inserting a new node. You can also make the new node active in the parent scenario.