Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Junction Storage #200

Open
dcedgren opened this issue Oct 28, 2024 · 14 comments
Open

Junction Storage #200

dcedgren opened this issue Oct 28, 2024 · 14 comments
Assignees
Milestone

Comments

@dcedgren
Copy link

It's always bothered me that SWMM doesn't account for water storage in junctions. There's no reason I can't just turn 100% of my manholes into storages instead of junctions. It's just nice to keep storages special so it's immediately clear from the symbology that it's a wet well or a pond or something. I suspect a lot of users currently use junctions and under-represent manhole volume.

Additionally, the minimum nodal surface area parameter in the calculation options would be good enough for my purposes, but my quick online research shows it only adds volume at low depths for numerical stability and would not help add volume during surcharge (which is what I'm after).

Could we add a Storage Area (ft2 or m2) parameter to junctions? This would be very useful to represent a simple manhole which are 95% of the nodes in my models.

@cbuahin cbuahin added this to the v5.4.0 milestone Oct 28, 2024
@cbuahin cbuahin self-assigned this Oct 28, 2024
@dickinsonre
Copy link

Way back when this was the intent. The manhole area was only added to prevent division by zero when there was a gap at the bottom of the manhole between the node invert and the lowest pipe. The area is only used if there is no connecting pipe area. I would be afraid that some people might just make every node 100 square meters to make their model stable but this is a good idea.

@dcedgren
Copy link
Author

dcedgren commented Dec 5, 2024

Robert, I think you're getting at two different ways to accomplish this:

  1. Change the minimum nodal surface area parameter to set a universal junction surface area
  2. Add a new junction "Surface Area" attribute which can vary from junction to junction

I always kind of thought the universal parameter already did this and only recently learned it does not (as you explain it gets used mostly in a trivial capacity for model stability). So it's already confusing. But might be more confusing if the parameter used to not do what it sounds like and then in a future version is made to do what it sounds like. That's the risk of 1) is that it will mess up a bunch of old models when run on the newest version of SWMM.

Either would work for my purposes, but I was envisioning 2) ... it seems safer.

@MattAndersonPE
Copy link

Bob -
That's usually the problem in stormwater networks, with large structures (10-foot-wide culverts) or wide channel sections where a 4-ft round structure contributes to instability.

@dickinsonre
Copy link

In the versions of SWMM5 to 2018 the default area was used ALL of the time for a node that is not a storage node.

The Minimum Nodal Surface Area dynamic wave routing option was being used as surface area always available at a node instead of an amount available only when the surface area of the node's connecting links fell below it.

Build 5.1.013 (05/10/18)

@cbuahin
Copy link
Collaborator

cbuahin commented Dec 6, 2024

I am inclined to agree with @dcedgren on going with the second option. Or, we keep both, model defaults to universal specified area if junction specific values are not provided.

@JoePangster
Copy link

JoePangster commented Dec 6, 2024 via email

@dcedgren
Copy link
Author

dcedgren commented Dec 6, 2024

I'd say the simplest way is to have the Surface Area for a junction be the single authoritative value and leave the Minimum Nodal Surface Area unchanged as only a stability parameter. We could set the default Surface Area for a new junction to 12.57 ft2. (For determining the value to be used in the sump the maximum of the global "Minimum Nodal Surface Area" and the local "Surface Area" of the junction would be taken.)

I like the idea of keeping both in theory...but how would we implement this in practice? If the junction's "Surface Area" parameter is set to 0 it would fall back on using Minimum Nodal Surface Area? I'm afraid 1) this would lead to extra confusion by users having to know to look into two places, and 2) there would be no intuitive way to set junction Surface Area to zero for users wishing to do so (such as for overland channels) since per the current documentation for Minimum Nodal Surface Area "If 0 is entered, then the default value of 12.566 ft2 is used". Maybe you're picturing a better way to implement keeping both.

One more thought. I think that Minimum Nodal Surface Area parameter needs to be better documented. Here's the documentation I currently see in the SWMM 5.2 User's Manual:

Minimum Nodal Surface Area
This is a minimum surface area used at nodes when computing changes in water depth. If 0 is entered, then the default value of 12.566 ft2 (1.167 m2) is used. This is the area of a 4-ft diameter manhole. The value entered should be in square feet for US units or square meters for SI units.

This does not really explain what the parameter currently does. It should be updated. I wonder if we could also rename it "Nodal Stability Surface Area" or some other name that better explains its purpose? "Sump Stability Surface Area"?

@cbuahin
Copy link
Collaborator

cbuahin commented Dec 9, 2024

Good points @dcedgren. I think this is something we need to think a little bit more carefully about. Generally, I think anytime the area or any user provided parameter is adjusted/overridden automatically in the model to improve convergence, ensure parameters physically meaningful, etc., we need to report it, While not significant, using that nodal surface area adds volume to the system. Based on your thoughtful insights, this is what I am inclined to do.

  1. Allow users to prescribe nodal surface area for each node. The default value will be zero.
  2. Change the name of the Minimum Nodal Surface Area global parameter to something that correctly identifies the role it plays.
  3. Use the Minimum Nodal Surface Area global option as is currently implemented when the nodal surface area is zero. Otherwise, the prescribed nodal area is used.
  4. Update the documentation to reflect this implementation.

@MattAndersonPE
Copy link

Should the default Minimum Nodal Surface Area be '*'? This would make the 'use value from somewhere else' fit with the consistency of Inlet Offset and Outlet Offset values in SWMM.

This makes it clear in the INP that we are not using this value.
InvertOffset

@dickinsonre
Copy link

If you are using user-defined area for each node then it should be used as it is in a storage node. The node area should be used for all node depths and not just at the bottom of those nodes with a gap between the invert and the bottom of the connecting links. That would complicate the code and the documentation.

Or you can go back to the way it was used in SWMM5 before Lew changed it.

@JoePangster
Copy link

JoePangster commented Dec 9, 2024 via email

@JoePangster
Copy link

JoePangster commented Dec 9, 2024 via email

@dickinsonre
Copy link

dickinsonre commented Dec 10, 2024

JoePangster = the name makes sense now.

The AI's all agree and say this

Comments on the Proposed Changes for Nodal Surface Area in SWMM5

  1. User-Specified Nodal Surface Area:
    Introducing the capability to define a custom nodal surface area per node adds flexibility and precision to modeling. Currently, SWMM’s assumption about nodal area can be too generic. Allowing the user to tailor this parameter enables more accurate representation of nodes that function as junctions, storage units, or locations with unique geometrical characteristics. Setting the default to zero maintains backward compatibility and ensures that users who do not want to specify per-node areas can still rely on the existing global defaults.

  2. Renaming the Global Parameter:
    Renaming the "Minimum Nodal Surface Area" parameter to something that more clearly describes its role is a sound idea. The current name might cause confusion about whether it’s a lower bound, a fallback, or a default value. A name that clearly distinguishes it as the "Default Nodal Surface Area" or "Global Nodal Area Baseline" would reduce misunderstandings, especially for newer users.

  3. Fallback Logic for Zero User-Specified Areas:
    Keeping the existing global parameter as a fallback when nodal surface area is not specified (i.e., remains zero) is a practical choice. This preserves the current model’s functionality, ensuring that existing models still work as intended without forcing users to redefine every node. It also simplifies the transition for users—those who don’t need specialized nodal areas can ignore this feature and continue relying on the global setting.

  4. Documentation Updates:
    Clear and updated documentation is crucial whenever a new feature is introduced or changed. Explaining how the user-specified area and global parameters interact, clarifying defaults, and providing examples will greatly help users understand and implement this new functionality correctly. This step ensures transparency, reduces user error, and fosters trust in the model’s enhancements.

Overall Wisdom of the Change:
These changes are sensible improvements that enhance modeling flexibility and clarity without compromising backward compatibility. By giving users direct control over nodal surface areas, clarifying parameter names, and providing robust documentation, the approach shows careful consideration of both new and experienced SWMM users’ needs.

@dickinsonre
Copy link

BTW, the AI's love SWMM4 for the following reasons

Why AI is good at answering SWMM5 questions - The accuracy in SWMM5 responses likely stems from its well-documented technical foundation and standardized implementation. Here are the key aspects:

Core Strengths

Documentation Quality

  • EPA's extensive technical documentation provides clear, verifiable information
  • Mathematical models and equations are precisely defined
  • Processes are thoroughly documented with specific parameters

Standardization

  • SWMM5 uses consistent terminology across versions
  • Input/output formats are strictly defined
  • Error messages and warnings are standardized

Technical Framework

Hydraulic Elements

  • Clear distinction between nodes, links, and subcatchments
  • Well-defined relationships between components
  • Specific calculation methods for each element type

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants