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]

Mike Urban's User Defined Tools dialog allows you to add external executables to the menus within Mike Urban. This functionality is similar to some other applications, like Visual Studio. Anyone know any tricks to get the current working directory or current file for the model passed to the other application? In Visual Studio you can use a bunch of variables.

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.

Was curious if anyone has been using some of the alternative databases for storing the model within Mike Urban and had any thoughts on the experience. Our GIS staff suggested we should see a pretty big performance jump moving from a personal geodatabase format to a file geodatabase; I also was curious about ArcSDE. I was particularly curious if there was much of an observable benefit (e.g., speed on clicking edit, speed switching scenarios), or losses of particular functionality (e.g., scenario manager).

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?