Brian Brenhaug Enterprise Water Systems Team Manager

Hello Tom,

I find the pump controls pretty unintuitive in Mike Urban. I assume you're using the MOUSE engine? Assuming MOUSE, my typical practice is to setup two actions, each of Action type (msm_RTCFunction.FunctionNo) "Setting of Start/Stop Levels" and Input type (msm_RTCFunction.InputNo) "Constant".

MUID: _EnablePump
StartLevel: 0
StopLevel: 0

MUID: _DisablePump
StartLevel: 9999
StopLevel: 9999

I then use whatever conditions with these as the activate/deactive pump actions. I try not to think about it too much, because it feels so unintuitive, but if you want the details, the _EnablePump action forces the pump on whenever the water level in the upstream node exceeds the StartLevel. Because the predicted water level in the upstream node will always be above the starting level you've specified as 0', the pump will always turn on. Similarly the _DisablePump action will turn the pump off if the water level in the upstream node is below the minimum StopLevel. Since the water level is always below 9999, the pump will always stop. (Of course, this assumes you aren't modeling anything below 0' or above 9999'). Often, when I find this isn't working, it has to do with the specifics on the pump curve.

Thanks,
Brian

I've never really worked with catchments, but within the Tools > General SQL Command..., you could probably do something like:
[code]UPDATE msm_HParA INNER JOIN msm_HModA ON msm_HParA.MUID = msm_HModA.ParAID SET msm_HModA.ConcTime = msm_HParA.ConcTime;[/code]

Actually, I ended up tracing it to a boundary issue as well. I'd erroneously left a head boundary as an external timeseries (DFS0) instead of a gradual fill (on a cold start). I guess the significant jump in head was too extreme. (I was overriding the max pressure in dhiapp.ini, so that probably would trigger an error at least in normal model runs)

I'm seeing the MOUSE engine (MOUSE Simulation Launcher) lockup during it's startup phase without an error message. It occurs when the status bar text is "Initiating Simulation Launcher". One time I saw this error before on Mike Urban 2012, I eventually traced it to weir and a valve element with the same MUID and changing one MUID fixed it.

Anyone else seen other causes? That's not the issue this time, so I'm trying to debug why I'm getting the error.

You may want to try posting a sceenshot of what you typed into the rule dialog...maybe help make it more clear what the issue is.

The Project Check Tool should also update those FROM TO fields.

You can also use ADP

Are you trying to load the dfs2 file via Model Results > Load Results > Overland Results?

Hello,

It may be helpful to know what you are trying to optimize. For example, the sizing of the stormwater network for a given flow condition, or something more like the routing of flow while the model is running?

Thanks,
Brian

Not sure which are really applicable to your system, but some other potential causes I've seen for this include:
[list]
[li]External Water Levels set on outlets without the gradual startup enabled[/li]
[li]Network Loads starting up suddenly[/li]
[li]ADP used for filling[/li]
[li]any control elements moving suddenly at startup (e.g., a valve opening fast)[/li]
[/list]
Basically, anything that fills the model suddenly. If it's happening a few seconds into the model run, sometimes I'll set a very small reporting timestep to observe the instability in a little more detail to try to identify the source.

If it's not related to filling, some other potential causes are that the ground level is set too low or if the node is intended to be pressurized, the cover type may need to be sealed.