Oluf Jessen

Hi,
As you are getting an error ” Calling Mrotation_GetStartEndsScheme with an array that is not associated
Error : Timer UZ+ET is not on” I would recommend you to send the model to mikebydhi@dhigroup.com as errors should not occur. We would then have to look at the error. I have not seen this error before when using the vegetation database for the irrigation module, but I would suspect that the error has something to do with overlapping vegetation or gaps between the start and end of some of the vegetation types.

With respect to the ponding depth option from the vegetation file, I have used this option before and it should work. One of the issues could be if you have specified demand areas using the ponding depth option, but within the command areas there are crop types without irrigation data in the vegetation file. You should check if the vegetation data that are used all contain irrigation data in the vegetation file. If you are using polygons (from a shape file) to determine the command and demand areas the problem might occur if the shape file does not overlay completely with the grid using in the model and it might include a crop that you did not expect to be part of the demand areas. If you are able to pre process the model you should look at the pre processed vegetation types. Another option could be to try using the uniform option for both demand and command areas, and specify a single crop just to make sure that the option works.

Best regards
Oluf Jessen (DHI)

Dear Janna

Sorry for the late reply. Yes I mean using a flow boundary with Q=0 in both ends.

BR
Oluf (DHI)

Dear Patrick

I would recommend sending this to DHI support (mikebydhi@dhigroup.com) as there are nothing in your message that indicates an error. Are there any other messages in some of the other log files (out of disk space, unable to write result files etc...)?

Best regards
Oluf (DHI)

Hi,
This is a problem that we have seen a few times, in models where the UZ time step gets very small.  The error is caused by a tolerance on the time step numbers (floating numbers), which causes a difference between the storing and actual time step, and this is noticed by the model in the error message, and the model stops.  We are aware of the problem but there is no solution available at the moment. If you are able to reproduce the problem in a very simple model, then feel free to send the model to mikebydhi@dhigroup.com and we will be happy to take a look at it.

If you have a model that is forced into these very small time steps it might be that some of the parameter sets used in the AutoCal are not valid, and it might help if you try to restrict the boundaries for your parameters.  The models that are crashing in your optimisation might not be useful in the evaluation as the parameters or the conceptualisation causes the model to run with these very small time steps.
Please feel free to contact DHI (mikebydhi@dhigroup.com) if you have more information or if you have a simple setup that are able to reproduce the problem.

Best regards
Oluf (DHI)

Hi,

Its correct that MIKE SHE is not able to read Polygon ZM files. I use the same approach as you do (using ArcMap), and I have not been able to find any easier method for transforming the ZM polygon to a regular polygon.

Best regards

Oluf (DHI)

Dear Janna

The solution that you describe could be done in MIKE SHE, buit is a bit tricky.  I would recommend the following approach:
•              Define a MIKE 11 channel coupled with MIKE SHE using the weir option (in this case the bank elevation in the cross sections determines when spill should occur)
• Use no flow boundaries at both ends of the MIKE 11 channel (no water flowing to the branch or leaving the branch)
• The exchange with the MIKE SHE model occurs using GW exchange and flood spilling (and OL flow but this only goes from SHE to M11). If I understand you situation correct you should define the cross sections equal to the topography (use a width of one cell). The overbank spilling will only spill water when the water level is above the bank elevations in the cross sections. The remaining part of the water in the channel could be exchanged with SHE using the M11 – SZ exchange, but requires that the water table in the M11 branch is above the GW elevation. For this part you might want to adjust the leakage coefficient.
• Another solution could be to use the flood code option, as this will ensure that water from the branch is “mapped” onto the terrain, and in this case you will actually have the same water level in the river and on the surface. The flood codes should then be used for the same area as you have your cross sections, as this will map the water onto the terrain, and it should then be allowed to flow from there. This might give you a solution that is closer to what you want.

I would recommend that you try this approach on a small “dummy” model to ensure that it works, and to adjust the parameters, before implementing it into the large model.

Thanks
Oluf (DHI-DK)

Hi,

Please look at the user guide located in the installation folder (eg. C:\Program Files (x86)\DHI\2012\MIKE Zero\Manuals\MIKE_Hydro\MIKEHydro_UserGuide.pdf) and look in section 1.5. Section 1.2 - 1.4 are also usefull for a first overview of MIKE Hydro.

Best regards

Oluf (DHI)

Dear Spencer
The paved area and the drainage module both works in a way where the water is routed to a receiving cell which could be an internal cell, boundary or a river point. The paved area module works on ponded water while the drainage module works on the saturated zone. Note that both the paved area and drainage module uses the same reference system, meaning that the way the water is routed from one cell to the receiving cell is the same for both drainage and paved area.

For paved area the amount of water removed from a cell during one time step is calculated as the runoff coefficient times the depth of ponded water. A value of 1 will remove all the ponded water in each time step. The calculation sequence is that MIKE SHE first calculates ET losses, then updates the ponded water and calculates the paved area runoff. The paved area runoff is calculated BEFORE infiltration, but after ET losses.

The drainage module works on the saturated zone as a time constant times the difference between the drainage level and the groundwater level. The drainage module is only active when the groundwater level is above the drainage level in the specific cell. So drainage works after infiltration to the SZ.

The best way to verify how the two modules work will be to select two cells having different runoff coefficients but the same rainfall and soil type. Then plot the different components, from the two cells, as time series, and it should hopefully be easier to understand how the paved area and drainage module works.

Feel free to post additional comments on this site or contact DHI directly at mikebydhi@dhigroup.com

Thanks
Oluf (DHI)

Hi Vince
If you use the bathymetry option you could view the resulting or modified DEM in the pre-processed data. This will show you the DEM that the model uses during the actual model simulations. You need to evaluate the results, as I’m not sure this option is the best to use.
The problem with cross sections and DEM is not easy, and basically boils down to a scale issue, as the cross sections represent the surface using a fine scale while the DEM normally represents the DEM in a coarser scale. I would normally recommend that you try to get a reasonable match between the bank elevation in the cross sections and the DEM. The approach would be to alter the datum in the cross sections so that they match (within a range of X meters depending on the scale) the DEM. There are many issues to take into account when looking at cross section data and DEM depending on which issues you are looking at. Please feel free to write here again or contact DHI if you want to discuss this further.
Best regards
Oluf