I am trying to do flow balance and realized a small discrepancy; The two inlets are In Sag with full capture of the flow of the two catchments as in the screenshot below, I expected to see in the conduit CO-4693 the total flow 29 L/s, the pipe properties show 30 L/s, what is the reason behind that, is something can be done to be matched, the model is uploaded to the share link also.
Regards,
Mohamad
Hello Mohamad,
I checked your model and saw the results. Ideally the flow should match up to the flow carried by both the upstream conduits, GUL-3844 and GUL-3845 i.e. max flow of 0.021 m3/s and 0.018 m3/s. However the conduit CO-4693 is getting pressurized and since the carrying capacity of the conduit is exceeded you are getting the max flow of 0.030 m3/s.
If you increase the conduit diameter you would get the expected flows in the conduit since the carrying capacity is increasing.
The dynamic wave routing method used in the SWMM solver is apt for modeling conduits getting pressurized.
Yashodhan Joshi
Hello Yashodhan,
Thank you for feedback - in the same model test, for the gully (in Sag), if I did not select full capture and change to type "catalog Inlet" with the selection of surface storage type to " Default storage Equation" why the flow (Total In Maximum) became less? since it is in Sag it should capture all surface flow, isn't it?
As of July, 2020 (version 10.03.01.08), when using one of the surface storage options along with "in sag" as the inlet location, catalog inlets are not supported. In this situation you must select a different inlet type such as Full Capture, or the results may not be valid.
This is captured in the below wiki;
Interpreting results when using manhole or catchbasin Surface Storage;
Hope this helps.
My query is about the "In Sag" if I did not select Full Capture and used catalog, why the flow is not similar in both cases, it is bigger when it is full capture; why? and what is more preferable since it is in sage to use catalog or full capture? (consider connect edition 2)
another thing, if you look to on grade inlet (upstream inlet), in the graph of inlet "efficiency calculated" the model shows at zero flow the efficiency is around 60? and how is calculated at the peak is around 20?
how is the software calculate efficiency? would you please verify the calculated number?
Mohamad Azzam said:My query is about the "In Sag" if I did not select Full Capture and used catalog, why the flow is not similar in both cases, it is bigger when it is full capture; why? and what is more preferable since it is in sage to use catalog or full capture? (consider connect edition 2)
The reason is because of the attenuation caused by the surface storage that must be selected in this configuration. You can see this by graphing "flow (total in)" along with "flow (local surface)". This very issue was raised in another recent forum discussion which is still in progress.
If you would like to ignore attenuation effects from the surface storage, change the surface storage type to "ponded area" and use a small surface area such as 1 m^2. I am still discussing this topic with our development team and plan to document all related assumptions and expectations for the various configurations that can arise.
Mohamad Azzam said:another thing, if you look to on grade inlet (upstream inlet), in the graph of inlet "efficiency calculated" the model shows at zero flow the efficiency is around 60? and how is calculated at the peak is around 20? how is the software calculate efficiency? would you please verify the calculated number?
In the model you sent, that catchbasin is set to "in sag" with "full capture". If I change this to on grade and catalog inlet I see the results you mentioned, but it appears they are actually correct based on the captured vs. bypassed flow. If you change the decimal precision to 8 for the captured/bypass flow fields, you will see there is a tiny flow amount, but the distribution does match the noted capture efficiency:
This appears to be due to numerical noise so you should be able to ignore the capture efficiency in this case. I have reported this to our developers as defect #409585 to look into future improvements (for example to only consider a limited number of decimal places to avoid this)
Jesse DringoliTechnical Support Manager, OpenFlowsBentley Communities Site AdministratorBentley Systems, Inc.