mHM
The mesoscale Hydrological Model
|
For compile and installation instructions see: https://mhm-ufz.org/guides/.
The mHM distribution usually comes with two example test domains located in
The directory provides input data for the test basin and output examples. Detailled information about this test basin can be found in the chapter The details about the test basin. All parameters and paths are already set by default to the test case, so you can just start the simulation with the command
This will run mHM on two basins simultanously and create output files for discharge and interception in test/output_b*
. The chapter Visualizing Model Output provides further information on visualising mHM results.
Pretty much the first step mHM takes during runtime is reading the three configuration files:
mhm.nml
mhm_output.nml
mhm_parameters.nml
When editing these files, we recommend to use syntax highlighting for Fortran, which is featured in emacs, for example. This will also guarantee that the file ends with a new line character that is required by the fortran language standard. If you are writing these files with external programs, make sure that the written files comply with Fortran language standard, in particular make sure that the file ends with a new line.
The file mhm.nml
contains the main configuration for running mHM in your catchments. Since the comments should explain each single setting, this section will only roughly describe the structure of the file. By the way, paths can be relative, absolute and even symbolic links.
The file mhm_output.nml
regulates how often (e.g. timeStep_model_outputs = 24
) and which variables (fluxes and states) should be written to the final netcdf file [OUTPUT_DIRECTORY]/mHM_Fluxes_States.nc
. We recommend to only switch on variables that are of actual interest, because the file size will greatly increase with the number of containing variables. During calibration (see Calibration and Optimization) no output file will be written.
The file mhm_parameters.nml
contains all global parameters and their initial values. They have been determined by calibration in German basins and seem to be transferabel to other catchments. If you come up with a very different catchment or routing resolution, these parameters should be recalibrated (see section Calibration and Optimization).
By default, mHM runs without caring about observed discharge data. It will use default values of the global regionalised parameters \(\gamma\), defined in mhm_parameters.nml
. In order to fit discharge to observed data, mHM has to be recalibrated. This will optimise the \(\gamma\) parameters such that mHM arrives at a best fit for discharge. The optimization procedure runs mHM many many times, sampling parameters in their given ranges for each iteration, until the objective function converges to a confident best fit.
mHM comes with four available optimization methods:
mcmc_tmp_parasets.nc
. dds_results.out
. anneal_results.out
. sce_results.out
.Objective functions currently implemented in mHM are:
The following settings in mhm.nml
are required for calibrating mHM:
optimize = .true.
opti_method = 1
opti_function = 1
nIterations = 40000
seed = -9
More specific settings are offered at the very end of the file mhm.nml
.
In mhm_parameters.nml
you find the initial values and ranges from which the optimiser will sample parameters. Most ranges are very sensitive and have been determined by detailed sensitivity analysis, so we do not recommend to change them. With the FLAG column you may choose which parameters are allowed to be optimised. The parameter gain_loss_GWreservoir_karstic
is not meant to be optimised.
Please mind that optimization runs will take long and may demand a huge amount of hardware ressources. We recommend to submit those jobs to a cluster computing system.
During calibration, mHM does not write out fluxes, states and discharge, so you need to perform a final run with the calibrated parameters. When the simulations are finished, the optimal parameter set is written to
You can run mHM directly with the generated namelist (by renaming it) or incorporate the results in FinalParams.out
as new initial values into mhm_parameters.nml
. There are two scripts that help you with that:
pre-proc/create_multiple_mhm_parameter_nml.sh
FinalParams.out
) post-proc/opt2nml-params.pl
pathto/FinalParams.out
and pathto/mhm_parameters.nml
, it will (1) create a new mhm_parameters.nml.opt
filled with the new values and (2) directly show the new parameters within their ranges and warn if some have been close to their end of range by 1%.As soon as the new parameters are set, deactivate the optimize
switch in mhm.nml
and rerun mHM once in order to obtain the final optimised output.
You should also have a look at the parameter evolution (e.g. sce_results.out
) or final results. If any of the parameters stick to the very end of their allowed range, the result is not optimal and you will be in serious trouble. Possible reasons might be bad parameter ranges (even though they have been optimised mathematically, but in a basin or resoluion not comparable to yours) or bad input data.