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.
↧