# iMOD User Manual version 4.4 (html)

#### A.2What are the models SIMGRO and MetaSWAP intended for?

Most regional model codes cover only part of the processes within a region. For coming to grips with many issues of integrated water management it is necessary to have a model that covers the whole (regional) system, including plant-atmosphere interactions, soil water, groundwater and surface water. SIMGRO (a dated acronym of SIMulation of GROundwater) was developed for that purpose.

The name ‘SIMGRO’ was formerly used for referring to an integrated model code, including submodels for the compartments and processes as shown in Fig. 1. Now it is used in the meaning of a modelling framework. This framework has been connected to a number of ‘inhouse’ components, but also has possibilities for coupling to other codes. The in-house components are:

• 1. an SVAT-model that is commonly referred to as ‘MetaSWAP’, covering the plantatmosphere interactions and soil water;

• 2. a simplified surface water metamodel;

• 3. a drainage package, for simulating groundwater drainage with fast feedback from surface water.

The current possibilities for coupling to other codes are:

• 1. MODFLOW for groundwater (operational);

• 2. SOBEK-CF for surface water (under development).

The used schematisation assumes that the separate SVAT columns only interact with each other via their connections to groundwater and surface water.

##### A.2.1What is the scope of the model application?

The SIMGRO framework is intended for regions with an undulating topography and unconsolidated sediments in the (shallow) subsoil. Both shallow and deep groundwater levels can be modelled by MetaSWAP. This model is based on a simplification of ‘straight Richards’, meaning that no special processes like hysteresis, preferential flow and bypass flow are modelled. Snow is not modelled, and neither the influence of frost on the soil water conductivity. A perched watertable can be present in the SVAT column model, but interflow is not modelled. There are plans for including the mentioned special processes in MetaSWAP Inundation water can be modelled as belonging to both groundwater and surface water at the same time. Processes that are typical for steep slopes are not included.

The code contains several parameterized water management schemes, including irrigation and water level management.

##### A.2.2What are the used spatial and temporal scales of the model?

The spatial scale of the model is typically for a unit of 1 km${}^{2}$ and less. Model applications have involved up to 500  000 units (National Hydrological Instrument for the Netherlands). A prototype model of a small basin involved 800  000 cells of 5x5 m. A resolution finer than 5x5 m is considered to be beyond the scope of the model, because then the one-dimensional flow schematization is not adequate.

It is possible to couple several MetaSWAP columns to a single ground water cell. In that way it is possible to use ‘tiles’ for representing fractions of the soil surface, for e.g. the vegetated part and the built-up part.

The model uses two nested time scales:

• 1. a fast cycle for the plant-atmosphere interactions and the interactions with surface water;

• 2. a slow cycle for the unsaturated zone and the coupling to the groundwater model.

Typically an interval of 1 hour is used for the fast processes, and 0.5 or 1 day for the slow processes. The time step of the slow processes and that of the groundwater model should be equal.

##### A.2.3What are the necessary input data?

The required input data are described in Alterra Report 913.2. The main categories of input data are:

• 1. temporal scales;

• 2. schematization and coupling to other models;

• 3. soil elevation and soil physical data;

4. land and water use parameters, including irrigation demand;

5. irrigation water supply capacities;

• 6. meteorological data, including the option of grid files;

• 7. output control parameters

##### A.2.4What output data can the model produce

The main categories of output data are:

• 1. databases involving up to 129 (optional) data simulated items per SVAT unit, at the time scale the groundwater model, and also for user-defined output periods;

• 2. files in csv-format that are accessible while the model is still running (‘monitoring files’)

##### A.2.5How does the model communicate with the user, in what language?

The model is run from a DOS-prompt and communicates with the user via files, both binary and ASCII ones. By using the facility of the csv-files, the user can follow a simulation as it progresses.

##### A.2.6On what platform does the model operate?

The model available for Windows platforms. The used language (Intel Fortran) makes it possible to migrate to a Linux platform, however, this is not supported by Alterra. The model has been coded with ‘dynamic’ memory allocation, meaning that the amount of used RAM memory is exactly tuned to the needs of the application. Large models will require a 64-bit environment due to RAM memory requirements.

##### A.2.7What does the model cost?

The model is freely available, including the source code.

##### A.2.8How are the model and its documentation made available?

The model and documentation is available at the SIMGRO ftp-site
ftp://ftp.wur.nl/simgro/ and contains the following folders:

The doc folder contains (among others) the following documents:

##### A.2.9Grid2MetaSWAP manual

###### A.2.9.1Introduction

The Grid2MetaSWAP program is incorporated in the iMODFLOW and iMOD framework to be able to couple iMODFLOW with MetaSWAP on a grid level. In essence, the program combines table information, grid data and predefined conditions into information readable for MetaSWAP. The following paragraphs describe the structure of Grid2MetaSWAP, scaling methods used within, and translation of all available data to MetaSWAP input files.

###### A.2.9.2Structure of the Grid2MetaSWAP program

Table A.1 gives an overview of the compulsory iMODFLOW-MetaSWAP parameters, the used abbreviations in the iMOD manual and examples of file names or default values to be used in the iMODFLOW RUNFILE. The purpose of a value that is given for a certain parameter may differ. A value of "999.0" in case of the artificial recharge capacity means that this variable is turned off during the computation. Similar for ponding depth, a value of 999.0 [m] means that the overland flow will only take place when groundwater level exceeds this; which in The Netherlands will never happen and the ponding depth is technically turned off. A default value for other parameters is set to -9999.0. The soil moisture factor and conductivity factor are set to 1.0 on default. For more information about the specific parameters and what type of values or files to be used, the iMOD manual can be consulted.

As briefly mentioned before, seen from the Grid2MetaSWAp code a distinction is made between urban and rural areas. Grid2MetaSWAP processes the parameters based on this division. However, only one of each MetaSWAP table input file (with extension *.inp) is created, containing both data for the urban and for the rural area as shown by Figure Figure A.3. Within the input file set 3 input files are written with specific coupling information; 2 related to the meteorological forcing (precipitation and evapotranspiration grids) and 1 to couple the iMODFLOW cells to the MetaSWAP units.

###### A.2.9.3Creation of MetaSWAP input files and content

As already shown in Figure Figure A.3, 11 MetaSWAP input files are created by the Grid2MetaSWAP program. From Table Table A.2 it can be read which MetaSWAP parameters are included in which input file. In case of the meteorological coupling files ("svat2precgrid.inp" and "svat2etrefgrid.inp") information from the wetted area and urban area parameters are used to fill these coupling files. In the meteorological coupling files, each svat number is coupled to the row and column numbers of the grids in case there is urban or rural area present in the cell. In the iMODFLOW coupling file ("mod2svat.inp") the iMODFLOW cell number is coupled to the svat number and combined with the artificial recharge layer of the specific cell.

In case of the artificial recharge (only an option for cells with rural area) that is stored in the "scap_svat.inp" a couple of choices are made in to code before storage. The flow diagram in Figure Figure A.4 shows the possibility of using a grid file (IDF-file) as input or a point file (IPF-file) containing the necessary information. The IPF-file only can contain information about artificial recharge from a groundwater resource.

###### A.2.9.4Scaling

Each grid file given in the iMODFLOW RUNFILE is scaled towards the right extent using a standardized routine. Different scaling methods are used depending on the type of parameter as can be seen in Table Table A.3. There are 4 upscaling methods used and 2 downscaling methods.

Upscaling methods (blue coloured in Table Table A.3):

• • Boundary

• • Arithmetic mean

• • Sum conductance

• Most frequent occurrence

Downscaling methods (orange coloured in Table Table A.3):

• • Block value

• • Spatial interpolation

Within the Grid2MetaSWAP program code a number of adjustments are made to be able to create MetaSWAP input files that are readable within the iMODFLOW-MetaSWAP framework. In all cases the following conditions are processed:

• • Inactivate constant head boundaries and inactive nodes

• • Skip the corners in relation to the anisotropy package

• Change urban areas and detailed land use types into grassland (landuse type = 1)

• Land use type 8 (greenhouse horticulture)

• Land use type 18 (paved area)

Land use type 19 (dark coniferous forest)

Land use type 20 (heathland vegetation)

Land use type 21 (fruit yards)

Land use type 22 (sport fields)

land use type 23 (unfertilized grassland)

land use type 24 (maize with green)

land use type 25 (potatoes early)

land use type 26 (urban grassland)

• Soil physical unit is equal to 22 or 23 (= sand), it is changed to 9 (=peat)

When looking at cells that are completely our partly covered by urban area, the following specific conditions are taken into account:

• • In case there is no ponding depth (VXMU) defined in a specific cell; the total urban area of this cell is set to 0 $m^2$.

• • In case there is no runoff resistance defined in a specific cell; the total urban area of this cell is set to 0 $m^2$.

• • In case there is no runon resistance defined in a specific cell; the total urban area of this cell is set to 0 $m^2$.

• In case there is no infiltration capacity defined in a specific cell; the total urban area of this cell is set to $m^2$.

• Minimal urban area is 0 $m^2$

A similar set of conditions is in place for the cells containing rural area:

• • The surface area dedicated to rural area is calculated by subtracting the total wetted area and the total urban area from the available total cell area:

• • In case there is no ponding depth (VXMU) defined in a specific cell; the total area of the cell is set to surface water.

• • In case there is no runoff resistance defined in a specific cell; the total area of the cell is set to surface water

• • In case there is no runon resistance defined in a specific cell; the total area of the cell is set to surface water

• • In case there is no infiltration capacity defined in a specific cell; the total area of the cell is set to surface water

• • Minimal root zone depth is 10 cm

• • Minimal rural area is 0 $m^2$

• • Turn off artificial recharge whenever artificial recharge layer equals 0

As given in Figure Figure A.2, the "para_sim.inp" and the "mete_grid.inp" are rewritten. Changes in the "para_sim.inp" include:

• • Placing quotes around the "unsa_svat_path" path

• • "simgro_opt" settings are not copied in case this option exists

• • "idf_per" is always set to "1"; IDF-file output files are always written

• Grid coordinates are newly written

• Number of rows and columns in the grid files are newly written

• • The "idf_nodata" value is set to "-9999.00"

Nothing is changed in the "mete_grid.inp". Related to the settings in de "para_sim.inp" and "mete_grid.inp", you need to keep in mind that the following settings are not touched:

• • Start year and start day in the "para_sim.inp" are fixed values

• • The path to the soil physical unit data base in the "para_sim.inp" is a fixed path and is not touched by Grid2MetaSWAP.

• • The paths to the meteorological forcing grids (evapotranspiration and precipitation ascii-files) in "mete_grid.inp" are fixed paths and are not changed by Grid2MetaSWAP.

Finally, some tips for running you model with the iMODFLOW-MetaSWAP framework:

• • Do not change the extent of the meteo-grids in between; all the files need to have the same extent as the files given in the first line of the "mete_grid.inp".