iMOD User Manual version 4.4 (html)

11.6Tutorial 6: Model Simulation

This tutorial gives a short introduction in starting a groundwater flow model simulation. See for more detailed references Model Scenarios and Model Simulation.


This is what you will do:

Required Data

For this tutorial you need the following iMOD Data Folders:

All these files are located in/below the folder:{installfolder} \tutorials \TUT_Model_Simulation.

Note: {installfolder} refers to the full path of the directory you installed iMOD in (e.g. D:\iMOD). Note: If you are a left-handed person and you converted your mouse button settings, ’left mouse button’ should be ’right mouse button’ and vice versa in these tutorials.

Beside this data you will need the iMODFLOW executable to make the model computations.

Getting Started

Model Parameters

Let us first observe some model parameters and understand what this model might be up to. We use the Project Manager for that, so lets’s start that one.

iMOD simulates a groundwater flow model by means of a runfile. A runfile gives a full description of the use of all files needed for the simulation. The Project Manager is able to read the entire runfile and present the content in a treeview field.

iMOD presents the content of the runfile in a treeview. Each branch represents a model parameter, and whenever a branch contains more information we can expand the branch to analyse its contents. Let us visualize the starting conditions for this particular model.

As a result iMOD will open all the files of the selected branch and adds them to the iMOD Manager. In this manner it is easy to explore the available model parameters for the model. In this model the starting condition of a model simulation is equal to a result of a previous simulation. Since IDF-files are geo-referenced, they can be easily (re)used for different modules and/or packages in a model configuration.


Figure 11.89: Difference between starting heads of model layers 1 and 2.

In this particular model a river is discretized for two different model layers , i.e. model layer 1 and model layer 2. The number of river elements is unlimited, however, a single IDF can store one river for each cell, so you should define more IDF files in those cases you want to specify more river elements at the same location. In this particular case we specified river elements for model layer 2 that penetrate the first aquitard and connect to the first aquifer (i.e. the second model layer).


Figure 11.90: Stages of the rivers of the first system.

Model Simulation

Let’s start the model simulation.

The first 15 lines of the runfile can be manipulated in the Start Model Simulation window. The rest refers to existing model input data, let’s check whether all these data is available.

iMOD will popup a summary file ({USER} \TMP \RUNFILE.LOG) of all files that cannot be found. Use step Item 6. to open a runfile to change pathnames if needed. If no files are listed, all files can be found and we can proceed.

iMOD will copy the selected runfile [TUT_MODEL.RUN] to the {IMOD_USER} \MODELS \
MODEL25 folder and renames it into IMODFLOW.RUN. Thereafter it will copy the simulation executable (e.g. iMODFLOW_V4_3_METASWAP_SVN1233_X64R.exe) to the same folder for archiving purposes, and it will start the simulation by the statement
{installfolder}\iMODFLOW_V4_3_METASWAP_SVN1233_X64R.exe IMODFLOW.RUN
in this example in the {installfolder}\IMOD_USER\MODEL25 folder. A DOS-command tool will open in which the simulation runs. You can proceed with iMOD or wait until the simulation finishes; it will take a very short time since the starting conditions are similar to the results.

The model simulation is always logged in the file IMODFLOW.list located in the subfolder mf2005_tmp, so in this example located in the folder {IMOD_USER} \MODELS \MODEL25 \mf2005_tmp. You should check this file IMODFLOW.list first whenever there is a problem with the simulation; as mentioned above it contains info on:

Let us simulate this model at a different resolution.

When using the Cross-Section Tool with the Block Line option (see Section 11.3 step Item 28.), you may expect the width of 4 blocks of the MODEL25 line equal to the width of 1 block of the MODEL100 line. But this is probably not what you observe in step Item 24. and Item 27. of this tutorial, because iMOD standard reduces the number of sampling points to speed up the calculations. To get the widths as expect, you have to increase the value of Maximum number of sampling points in the Cross-Section Properties window (see Section 11.3 step Item 27. or Section 7.1 to open this window), e.g. set Maximum number of sampling points to [1000].


Figure 11.91: Cross-section of heads of the 25x25 meter model (dark blue) and the corresponding 100x100 meter model (red).

Let us simulate just a part of the model.


Figure 11.92: Example of interactively specifying a part of the total model domain (smallest rectangle with hatching-pattern) for a model simulation. Also the size of the surrounding buffer zone can be specified here.

Water Balances

An important aspect of groundwater flow modeling is the ability to compute water balances. In iMOD you can compute these too by analysing the output variables in the different output files. It is important that you specify the appropriate output variables prior to your simulation, see tab Output Variables in the Start Model Simulation window you might have still open. In this case the defaults for the output variables were used.

Here you can specify for what layers, and periods (in case of a transient model) need to be included in the water balance. For now we select all layers (which are selected by default), so we leave it like it is.


Figure 11.93: Example of a water balance TXT-file.

In the above given example a water balance is presented for the entire model and for all model layers sequentially. In this case the water balance is given for a steady-state simulation and summed for the entire model area. There is only one zone used and the following terms are organized row wise:

Especially the (Q_in and Q_out) percentages are interesting and can be used to observe the relationship between the different water balance terms. In the above example \(>\)45% of the groundwater is discharged to the surface water.

There is another, more interactive manner, to examine water balances. Let’s try that.

Now you can see that iMOD reads 8 records, 11 budget terms, 1 period, 8 layers and 1 zone. The Waterbalance Analyser can be used to aggregate budget terms and display them graphically.

The following image might appear.


Figure 11.94: Example of a water balance displayed from a CSV-file.

From here you can zoom in or zoom out in the image, as well as select a different combination of model layer and zone number. If you have multiply zones \(nz\) and multiply layers \(nl\), the list in the drop down menu is as long as \(nz \times nl\). Let us display another graphical presentation of the water balance.

The water balance is presented as follows:


Figure 11.95: Example of a water balance displayed from a CSV-file.

There will be a sequence of 8 figures passing by, since we have selected 8 model layers, so repeat the following step 8 times to close all the repeating windows.

Let’s try a more complicated CSV file in this tool.

The following image appears (colours of the FluxTerms may differ).


Figure 11.96: Example of a water balance aggregated on a monthly base from a CSV-file.

There is a lot to try in this tool, all kind of different settings can be combined, see section Section 7.18.2 for more detailed information. Feel free to experiment a bit more with all the possibilities. If you’re done, we would like to compute a water balance for a specific region.

In the iMOD Manager you will notice the \(\langle \)water balance name\(\rangle \).IDF. This file reflects the position of the given polygon. You can reuse this file (e.g. after editing) in another water balance computation, therefore choose the option (Apply for non-NoData values within IDF).

Scenario Simulation

Let’s build a scenario in which we will increase a river stage from the current model configuration. We can do that in two manners. One manner is to adjust the appropriate IDF-files that discretize the river system, e.g. RIV \RIV_STAGE_L1.IDF and RIV \RIV_STAGE_L2.IDF by means of IDF Edit (see Section 6.7.4).

Make a copy of RIV_STAGE_L1.IDF and RIV_STAGE_L2.IDF in the folder ..IMOD_USER \DBASE by using the Map Operation option and the following instructions:

Now a copy of the selected file is made.

We’ve created a shape (polygon) to specify the area in which we will change the river stage. Let’s assign the measure to be attached to the polygon.

So, we’ve created a scenario definition that raises by 0.50m the stage of all river systems that penetrate model layer 1 and 2 inside the current polygon (SHAPE1), by making use of the iMOD Edit option.

Okay, let’s use this scenario definition in a model simulation.

As you might observe, the area of interest (within the shape) is smaller than the total extent of our model. Let’s decrease the size of our model (in order to speed up our simulation).

A buffer zone prevents that model results are affected by boundary conditions on the lateral model boundary. It depends on the scenario configuration, model configuration itself and the geohydrological subsoil what this buffersize should be. It is hard to determine beforehand, so it is wise to analyse the effects near the model boundaries to decide whether your simulation is affected by the lateral boundary conditions too.


Figure 11.98: Contour levels of the computed effect of a raised water level.

In the example above it is clear that the boundaries of our submodel have been chosen appropriately since the change in head is not affected by the model boundary. You can also make a cross-section of the computed effect to judge whether the boundary has been chosen right.


Figure 11.99: Cross-section of the computed effect of raised water level.

Model simulation with the Parallel Krylov Solver (PKS) package

So far we only used the single core PCG solver, now let’s switch to the multi core Parallel Krylov Solver. This requires that you have correctly installed the MPI software, see the iMOD Installation Instructions (Section 2.3).

The PKS package solver settings can be configured in two ways:

Note: The PKS package is not yet available in the Project Manager.


Figure 11.100: The ’Solver Settings’ tab of the ’Model Simulation’ window. In this example the user has assigned more than one CPU; as a result the PKS solver is activated.

When using the PKS package, the model domain is divided in sub-domains automatically; the number of sub-domains is always equal to the number of computational cores the user assigns in the ’Solver Settings’ window.

The overall computational model performance depends among others on how long it takes to solve each individual sub-domain; an iteration for the whole model domain can only be completed when all individual sub-domains have been solved. This means that load balancing is very important for the overall parallel performance. Ideally the actual work/load should be distributed as equally as possible over the multiple computational cores. PKS now supports two methods sub-domain partitioning methods:

Figure Figure 12.18 in Section 12.32.2 shows an example of both methods for the Netherlands Hydrological Model ((DeLange14)) and 128 sub-domains.

When assigning two CPU’s and selecting the uniform partitioning method, the model domain will be divided into two equal sub-domains.

When using the RCB method, the user has to specify per model cell a weight representing an estimate of how much each cell contributes to the computational effort to be made to solve the set of equations. There is no partitioning in the z-direction, so ideally the specified weights should also take variations of the total number of active cells per x,y-location (a particular vertical column) into account. One should be aware of the fact that even with the RCB and irregular boundaries, finding an optimal weight distribution can be difficult and subject to trial-and-error. The spatial weight distribution depends on for example differences in the complexity of boundary conditions (stresses) and coupling concepts.

In this tutorial we will exercise the use of the RCB method: you will run the groundwater flow model using two CPU’s applying a load balancing grid. This can be done by the following steps.

The following figure shows the specified loads of the LOAD.IDF grid: in the left part of the grid all cells have the value \(1\) and in the right part all cells have a value \(2\). So in this example we assign twice as much weight to approximately 20% of the model cells (note that this grid is just illustrative since for this model a uniform load of \(1\) for each computational cell would be most optimal).


Figure 11.101: The values of the LOAD.IDF grid used to specify the weights to be used in the Recursive Coordinate Bisection partitioning method; in this example approximately 20% of the model cells were assigned weight values that are two times larger than the rest  80% of the model cells.

Similar to a serial computations you can view the head results with Quick Open from the main menu option Map. We turned on the checkbox Merge IDF output files of subdomain: after the model-run the sub-domain-IDF’s will be merged to IDF’s covering the total model domain and the sub-domain-IDF’s are deleted. Of course we are also curious about how the total model domain was partitioned in two sub-domains automatically using our weight distribution grid. To see the partitioning-result of RCB method we will re-run the model in parallel mode, however, now without turning on the Merge IDF output files of subdomain-option:

These steps result in figure Figure 11.102, where the left sub-domain is clearly larger than the right sub-domain due to the specified weights. As you may have noticed the partitioning is not equal to the weight distribution of the LOAD.IDF grid, in other words, by specifying this pointer grid, you are not enforcing a particular partitioning of the model domain. This is caused by the RCB method which results in two sub-domains that each have an equal computational load (based on your estimated weight distribution); as mentioned above, the load of each sub-domain is calculated as the sum of the user-assigned weights of all cells lying within the boundaries of that sub-domain. Suppose we would have taken the LOAD.IDF grid as a basis for partitioning, this would have resulted in a relative load for the left part of ’80’ and for the right part ’2 x 20 = 40’. The RCB automatically shifts the boundary between the sub-domains such that the two resulting sub-domains each have a fifty-fifty (50-50) computational burden; that’s why the right sub-domain also contains part of the model domain having cells with weight values equal to \(1\).


Figure 11.102: The non-merged head-IDF’s of the two sub-domains using the RCB partitioning method. The partitioning is visible when choosing ’View’, ’Show IDF features’, ’IDF Extent’.

For your own model, experiment with different weight distributions for finding optimal load balancing. Provided your machine has more than two CPU’s available experiment with using (almost) all of them and compare overall performance.

Additional background questions The following questions are meant for extra training and get more insight in the concept of groundwater modeling.