Brett Laplante Project Engineer

Hello Manned,

I have come across those issues frequently in large models, and I find the FLOODLIMIT issues are generally a result of Pump Station flows under "Start-up" conditions of the model.  If it's possible, try running the model using several hours simulation time under low flows with a very small time step (1second if possible).  Use that result file as a HOTSTART file.

If that doesn't resolve your issues, you may be able to change the pump station parameters away from a pump curve to a defined flow to create the HOTSTART file, and then swap it out for your actual simulation.  I don't remember if changing the operational parameters of a simulation is considered too significant of a change for a HOTSTART file to be used, but I think you'll be fine.

As Ricardo has said, having a FLOOD greater then 10m is not likely accurate.  If you increase the FLOODLIMIT to say, 100m, it'll still fail.  You have some instability in your model that hotstarts generally resolve.

This is more a quality of life thing than functionality, but does anyone know how to get Mike Urban 2014 to save the result files (.CRF, .NOF, .PRF, etc.) into a sub-folder, rather than the working directory?  It would definitely help with the organization of projects with many different scenarios and whatnot.

Well that's interesting.  That explains somethings actually as I have been having some difficulties on the side with ArcGIS 10.1 crashing.  Been working with ESRI to come up with a fix, and one of the error reports I sent in indicated an error that they haven't seen / has been fixed since 9.3.

I'm trying to do some trouble checking on my machine, and am wondering if anyone has had any issues with Mike Urban related to the MOUSE module and the network connectivity?  I initially thought my issues were related to a .mdb that was just corrupted over time, but now I'm not so sure....

Process:
Creating new mbd file, no coordinate system (although I have done this with a coordinate system)
Collection system -> MOUSE only (not SWMM or Asset)
Unit System -> US mgd

I am unable to create any features as Mike Urban is not recognizing that the MOUSE module is active.  I can correct this by initializing the SWMM module (File -> Mode) and then turning it off again, but I shouldn't have to.  From there, the feature creation has no issues.

Another issue I am finding is related to the importing of ESRI shapefiles.  When I import node and link files, Mike Urban is not recognizing the connectivity of the links to the nodes.  Even after I run the Rebuild Network tool, the connection data is not existing.  When I try to manually connect the links to the node, Mike Urban crashes.  If I import just the nodes and run the Project Check tool, I get the following error:
"Error during initialisation with the following error message: The geometric network was not found.  Hint: You must Close all editors/tables and exit edit mode before running the tool, this error could also be caused by access restrictions or similar"

I am running Mike Urban 2014 Service Pack 1.  I have just run the Windows Repair Tool and the issue is still present.  Anyone else experience similar issues or have any suggestions regarding resolving this?

Wondering if anyone can help me with this, knowing that its not a simple task.  I'm also still using MU 2011.

As stated within the subject, this forum topic is about the location of the dhiapp.ini file.  I am aware that it is normally located here:
C:\Program Files (x86)\DHI\2011\bin

My request is - Is there a way to create a rerouting code such that MU looks for the ini file within the specific model directory? 

I am currently developing models for several different projects that use significantly different wastewater sewer sizes and flows.  With the inclusion of forcemains, siphons, valves, etc. I have had to make project specific edits to the ini file to increase model stability at the expense of accuracy.  The primary attribute that is adjusted is the minimum sewer length.

Generally, this would not be such an issue as I have multiple ini files saved (in backup directories) and swap them out when I pop over to a different project.  However, this process can be frustrating when I transfer between models as frequently as several times an hour based upon phone calls.  If I could develop a program to tell MU to find the ini file within the same directory that the model is saved, it would save me a lot of headaches.

Any thoughts would be highly appreciated.

Cheers,

Brett

To my knowledge, Mike Urban has been programmed such that when a simulation is running, utilize 100% of a thread.  For multi-core processors, this means that each simulation will use 50% of the cpu (for dual core 2 threads), 25% (for quad core 4 threads), etc.  I have not discovered a way to get it to use more than that, but would really be interested in finding out if it can be done.

I have been building a model that is intended to predict future sanitary flows based upon historical flow monitoring data.  As such, I have developed a number of scenarios and alternatives within my model.  Quite recently, I noticed that the alternatives have green, yellow, or red dots beside them.  I have scanned the Mike Urban Documentation Index but can not find what they mean.  My guess is that yellow indicates warnings present within the alternatives, and red means errors present, but when I run the project check tool and simulations, no errors are being produced.  I am still running MU 2011.  Anyone know whats going on?

Hi All, I was wondering if anyone else had encountered this similar issue and know if there's a way to fix/prevent it from happening:

I'm working with a Mike Urban model developed by someone else, originally developed with Mike Urban 2008.  We are using MU 2011, so consequently had to update the geodatabase to the newer format.  We have done this with other models without issue.  However, for the two models developed by this other person, whenever I use the Open Editor tool on catchments, it cause Mike Urban to crash immediately, without fail.  This occurs regardless of how long MU has been open, which programs are operating in the background, anything.

My guess is that this has to due with a bug translating from the particular geodatabase version 2008.2.2 to 2011.3.2.  Otherwise, there is some corruption causing this to occur.  Does anyone know of a way to re-build the geodatabase to eliminate the corruption (besides Compact Database, because that doesn't seem to solve this problem)?

This is a particularly annoying problem as I use the OPEN EDITOR tool quite a bit.  I do know how to work around the issue, but I'd rather solve it.

Cheers,

Brett

This is true for all tables imbedded within tables.  If you are looking for a quick fix, although not the best one, I would suggest copying from the msm_crsd table by opening up the .mdb file with Microsoft Access.

Though I am not familiar with this tool, one option would be to run the models to completion and use the Results Comparison tool.  Though it will not tell you differences such as which rain event used and such, it should give you some indication of at least where to start looking.  Otherwise, it might just be easier to pull all of your dbf information into Microsoft Excel, or any other spreadsheet program you may have, and use arrays or pivot tables to analyze the differences.  However, as you said, it would be a table by table comparison.  Fortunately, there would only be able 10 - 15 tables you would need to look at depending on what the expected differences would be.