Eng-Tips is the largest engineering community on the Internet

Intelligent Work Forums for Engineering Professionals

  • Congratulations waross on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Simplify ICPR Model

Status
Not open for further replies.

marballe

Civil/Environmental
Apr 9, 2013
2
0
0
US
The approved ICPR model is too large to manage and run. It contains a huge network of stage/area nodes that connected with pipe, channel, or weir links.

My question is: how would one simplify an ICPR model to a more manageable model? How to combine multiple stage/area nodes that share the same downstream basin into a single node? And when you combine nodes, what other parameters do I have to change to maintain the similar node's characteristics?

Please advise. Thanks.
 
Replies continue below

Recommended for you

There are many unknown factors and issues in the problem you present. Sometimes added detail is relevant and other times it is not. One must know the scope and intent of ALL aspects of the model.

In ICPR, there are a few things that may make the model more manageable.

*If it is not the case, one can assign subnetworks to "groups" and confine calculations to specific groups in a given simulation (in Hydrology and Routing control).

*To trim down the model entirely, one might:
1. perform a simulation on each network branch and create a report at the terminal node
2. eliminate the network branch down to the terminal node
3. assign a boundary flow to the terminal node of each branch and enter/import the flows for each appropriate node from the previous reporting.
(This would all have to be done for each storm event one is analyzing)

You mention the model is too large to manage and run. What are the specific problems? Does it really fail to run? Or does it just take a long time to run? There may be other solutions available.
 
It takes a long time to run (my coworker said it took about a week when it was last simulated).

If I recall correctly, it has 3000+ nodes and the area of interest contains ~40 nodes. I am not trying to "trim down" the model; instead, it is more like creating a new model with less nodes/links and mimic the conditions.

Logically speaking (at least, it sounds logical in my mind...), I should be able to reproduce a similar model if I create a new models with: (a) all those nodes, links, basins, and cross sections within the area of interest using the previous parameters; (b) downstream terminal nodes as Time/Stage node and force to match the T/S parameters from previous reporting); and (c) upstream terminal nodes with boundary flows parameters from previous reporting. [I haven't tried this yet...]

However, the ultimate question is: if I want to only use 10 nodes to represent those 40 nodes, what should I do?
 
Can't you hard code the resulting hydrograghs in a new model for all nodes not impacted by your area of interest?
 
marballe said:
Logically speaking (at least, it sounds logical in my mind...), I should be able to reproduce a similar model if I create a new models with: (a) all those nodes, links, basins, and cross sections within the area of interest using the previous parameters; (b) downstream terminal nodes as Time/Stage node and force to match the T/S parameters from previous reporting); and (c) upstream terminal nodes with boundary flows parameters from previous reporting. [I haven't tried this yet...]
Should work and speed things up considerably.

marballe said:
However, the ultimate question is: if I want to only use 10 nodes to represent those 40 nodes, what should I do?

That's almost impossible to answer without having the data, model and knowing ALL of one's goals. Consolidating detail is often a judgment call based on the results of more/less detail and one's tolerance for the variations that do occur.

 
Can't you hard code the resulting hydrograghs in a new model for all nodes not impacted by your area of interest?

That can be difficult in an ICPR model, since the point of ICPR is to model areas where every node impacts every other node. That's what's killing his runtime btw.

I will say this: I would never trust a model that large to produce anything meaningful, because chances are very likely that it's full of errors that nobody's ever caught. A misplaced decimal point on node 100 could zero out fifty nodes worth of results, and chances are very likely that any model of that size was created primarily with entry level labor by a large firm who's QC is their insurance policy / lawyers.

If I were the OP, and I had time in my budget, I would grab a branch of a half dozen nodes, simplify them to one node using your best engineering assumptions, rerun the model, and see if there's any difference. If so, spend some time figuring out why. If not, move on to the next bunch of nodes. Spend two days diligently doing that and see if you don't end up with a model that's more sane and more reliable.

If I did not have the time, and was just concerned with the 40 node blob of interest, I would try to export a rating curve for wherever the 40 node blob interacts with the rest of the thing, and just clip out the areas of interest. Again not easy in ICPR, but there's got to be a way to do it. I'm not extremely familiar with it, but I'd start by reading the help file on tide tables.

Hydrology, Drainage Analysis, Flood Studies, and Complex Stormwater Litigation for Atlanta and the South East -
 
Status
Not open for further replies.
Back
Top