mHM issueshttps://git.ufz.de/mhm/mhm/-/issues2020-09-23T18:51:01+02:00https://git.ufz.de/mhm/mhm/-/issues/148[IDEA] continuous rivers along lon bound2020-09-23T18:51:01+02:00Stephan Thober[IDEA] continuous rivers along lon boundThis commit in Ulysses allows rivers crossing the x bounds in the domain:
https://git.ufz.de/ulysses/mrm/-/commit/618ff9eeb24e801b6e47bca4fd2ab1e69dead984
it should be discussed whether this should be included in the main repo.This commit in Ulysses allows rivers crossing the x bounds in the domain:
https://git.ufz.de/ulysses/mrm/-/commit/618ff9eeb24e801b6e47bca4fd2ab1e69dead984
it should be discussed whether this should be included in the main repo.Integrate UlyssesSebastian MüllerSebastian Müllerhttps://git.ufz.de/mhm/mhm/-/issues/215MPR: State and TODOs2022-01-13T17:14:07+01:00Sebastian MüllerMPR: State and TODOs# State:
- See diff of !90
- compiling and running
- check case not all working ATM
- case....
# TODOs
- one MPR instance per domain (https://git.ufz.de/chs/MPR/-/merge_requests/84)
- speed optimization (affected by above and https:/...# State:
- See diff of !90
- compiling and running
- check case not all working ATM
- case....
# TODOs
- one MPR instance per domain (https://git.ufz.de/chs/MPR/-/merge_requests/84)
- speed optimization (affected by above and https://git.ufz.de/chs/MPR/-/merge_requests/79)
- documentation of refactoring and changes
- update pfunit tests6.xSebastian MüllerSebastian Müllerhttps://git.ufz.de/mhm/mhm/-/issues/25Consistency check for soil LUT (iFlag_soilDB = 1) fails for large soil datase...2021-07-29T14:22:26+02:00Oldrich RakovecConsistency check for soil LUT (iFlag_soilDB = 1) fails for large soil datasets with IntelDear all,
While running Southern America sub-continent (L0 has ncols=30720, nrows=24064) with `iFlag_soilDB = 1` using `nSoilHorizons_mHM = 6`, mHM breaks in `/src/MPR/mo_read_wrapper.f90` on following line:
`call check_consistency_lu...Dear all,
While running Southern America sub-continent (L0 has ncols=30720, nrows=24064) with `iFlag_soilDB = 1` using `nSoilHorizons_mHM = 6`, mHM breaks in `/src/MPR/mo_read_wrapper.f90` on following line:
`call check_consistency_lut_map(reshape(L0_soilId, (/ size(L0_soilId, 1) * size(L0_soilId, 2) /)), soilDB%id(:), fName)`
mHM is able to execute this command only up to `nSoilHorizons_mHM = 3`, when increasing to `nSoilHorizons_mHM = 4` and more, code returns following error:
`forrtl: severe (408): fort: (2): Subscript #1 of the array IRNGT has value 2109892711 which is greater than the upper bound of 2109892710`
Note that I encountered this weak point already half year ago for the Australian domain, but I could have solved this in the Makefile by `INTEL_EXCLUDE := mo_multi_param_reg.f90 mo_mpr_soilmoist.f90 mo_read_wrapper.f90`, which has no effect now. I also tried reducing the optimization level from `O3` to `O1` in `./make.config/eve.intel18`, did not help either, as follows:
`F90FLAGS += -O1 -qoverride-limits -gxx-name=/usr/local/gcc/6.2.0-1/bin/g++
FCFLAGS += -O1 -qoverride-limits -gxx-name=/usr/local/gcc/6.2.0-1/bin/g++
CFLAGS += -O1`
Actually, I have tried with both Intel compilers on EVE (13 and 18). Both have the same behaviour.
@kaluza, @thober @rkumar @lese @schaefed @ottor, Any ideas? Thanks!6.xMaren KaluzaMaren Kaluzahttps://git.ufz.de/mhm/mhm/-/issues/134Leaf Area Index of 0 not possible in gridded LAI input data2020-11-27T13:45:05+01:00Marco HannemannLeaf Area Index of 0 not possible in gridded LAI input dataI faced a problem with my gridded LAI input data. If the value 0 occurs in a cell within the basin, e.g. describing bare ground or urban areas, the following error will be thrown:
```
***ERROR: read_forcing_nc: values in variable "lai" ...I faced a problem with my gridded LAI input data. If the value 0 occurs in a cell within the basin, e.g. describing bare ground or urban areas, the following error will be thrown:
```
***ERROR: read_forcing_nc: values in variable "lai" are lower than 0.00
at timestep : 1
File setup_dir//lai//lai.nc
Minval at timestep: 0.0000
Total minval: 0.0000
```
Is this expected behaviour? However, the error indicates the presence of negative LAI values, maybe this is a problem of floating point uncertainty?
A possible workaround is to set the value of the cells to e-10.wishlist futureSebastian MüllerSebastian Müllerhttps://git.ufz.de/mhm/mhm/-/issues/48file unit handler2024-02-26T09:59:59+01:00Maren Kaluzafile unit handlerIf a program opens several files in different locations of the code choosing an unused file unit becomes complicated. The problem becomes even worse if there is MPI process specific output. In that case the rank needed to determine the f...If a program opens several files in different locations of the code choosing an unused file unit becomes complicated. The problem becomes even worse if there is MPI process specific output. In that case the rank needed to determine the file unit which can lead to conflicts in case of too many MPI processes.
An easy solution would be a file unit handler, a function that returns an unused file unit which is then written to a variable. Since fortran 08 there already is one that comes with fortran. Otherwise it would be a short subroutine.
If we decide to use such a subroutine it had to be used for every appearing new file unit since it only checks for file units which are already in use.wishlist futureSebastian MüllerSebastian Müllerhttps://git.ufz.de/mhm/mhm/-/issues/106driver refactoring and OOP2022-04-28T15:59:41+02:00Stephan Thoberdriver refactoring and OOPreorganize global data and methods according to classes for individual processes; adapt driver to new classes.
riv_temp serves as a template.reorganize global data and methods according to classes for individual processes; adapt driver to new classes.
riv_temp serves as a template.6.xSebastian MüllerSebastian Müllerhttps://git.ufz.de/mhm/mhm/-/issues/104[Enhancement] Container for global variables (mHM, mRM)2022-04-28T15:27:45+02:00Sebastian Müller[Enhancement] Container for global variables (mHM, mRM)In order to be future-prove, we should think about organizing global variables in containers to pass them around.In order to be future-prove, we should think about organizing global variables in containers to pass them around.6.xhttps://git.ufz.de/mhm/mhm/-/issues/112[Enhancement] `global_parameters` class2022-04-28T15:59:34+02:00Sebastian Müller[Enhancement] `global_parameters` classAt the moment the global parameters are an array where all needed parameters are just appended.
This is prone to failure, since you always have to keep track of positions for the parameters of your desired process.
Proposal:
Create a `g...At the moment the global parameters are an array where all needed parameters are just appended.
This is prone to failure, since you always have to keep track of positions for the parameters of your desired process.
Proposal:
Create a `global_parameters` class, where every process can register the parameters, init-values and ranges used in optimization.
These registrations could than be accessed by registration IDs (for example).
The current behavior, to be represented as an array could be provided by a class-method.6.xSebastian MüllerSebastian Müllerhttps://git.ufz.de/mhm/mhm/-/issues/113[Enhancement] read meteo weights separately for each variable2020-08-31T17:08:25+02:00Sebastian Müller[Enhancement] read meteo weights separately for each variableAt the moment, you can only enable reading meteo weights for all meteo forcings jointly.
To deal with different availabilities of data, we should add switches to enable weights reading for each meteo forcing separately.At the moment, you can only enable reading meteo weights for all meteo forcings jointly.
To deal with different availabilities of data, we should add switches to enable weights reading for each meteo forcing separately.6.xSebastian MüllerSebastian Müllerhttps://git.ufz.de/mhm/mhm/-/issues/51mRM stand-alone in mHM2023-04-26T13:02:11+02:00Stephan ThobermRM stand-alone in mHMmRM stand-alone repo will not be maintained from May 2019. For this reason, mRM needs to be run in mHM executable without running vertical land-surface processes.mRM stand-alone repo will not be maintained from May 2019. For this reason, mRM needs to be run in mHM executable without running vertical land-surface processes.6.xStephan ThoberStephan Thoberhttps://git.ufz.de/mhm/mhm/-/issues/129unit-conversion2022-04-28T16:07:04+02:00Sebastian Müllerunit-conversionWe need a module that provides unit-conversion, so that the code states what unit is in use currently and how it is converted.
I stumbled over some strange inline conversions like `mm * km^2` to `m^3` where the `km^2` where converted fro...We need a module that provides unit-conversion, so that the code states what unit is in use currently and how it is converted.
I stumbled over some strange inline conversions like `mm * km^2` to `m^3` where the `km^2` where converted from `m^2` in the function call by hand.
Providing routines, we could make it clearer what is going on.
Examples:
- `km_to_m`
- `degC_to_K`
- `liter_to_m3`
- ...6.xSebastian MüllerSebastian Müllerhttps://git.ufz.de/mhm/mhm/-/issues/105move directories_mHM to directories_general as a meteo dir2020-12-01T09:20:42+01:00Sebastian Müllermove directories_mHM to directories_general as a meteo dirAll specified folders under `directories_mHM` in `mhm.nml` can be combined essentially in `directories_general` under a `dir_Meteo`.
https://git.ufz.de/mhm/mhm/-/blob/develop/mhm.nml#L272
Does somebody demand to be able to specify diff...All specified folders under `directories_mHM` in `mhm.nml` can be combined essentially in `directories_general` under a `dir_Meteo`.
https://git.ufz.de/mhm/mhm/-/blob/develop/mhm.nml#L272
Does somebody demand to be able to specify different folders for each entry in `directories_mHM`?
Otherwise we could get rid of that.6.xSebastian MüllerSebastian Müllerhttps://git.ufz.de/mhm/mhm/-/issues/108consistent file handling in mhm.nml2020-08-31T17:08:29+02:00Stephan Thoberconsistent file handling in mhm.nmlWith merge request !34 , restart file names are handled more flexibly for the user. The same procedure should be applied to all other file names in mhm.nml.With merge request !34 , restart file names are handled more flexibly for the user. The same procedure should be applied to all other file names in mhm.nml.6.xSebastian MüllerSebastian Müllerhttps://git.ufz.de/mhm/mhm/-/issues/136miss fractions of landusetype forest and perm at L1 in mHM_restart.nc2022-06-17T16:53:28+02:00Friedrich Boeingmiss fractions of landusetype forest and perm at L1 in mHM_restart.ncHello, I miss the fractions of the landusetypes forest and permeable for the gridcells at L1 in the mHM output. In prior versions this was written out as L1_fPerm and L1_fForest. It would be interesting for the interpretations of model/f...Hello, I miss the fractions of the landusetypes forest and permeable for the gridcells at L1 in the mHM output. In prior versions this was written out as L1_fPerm and L1_fForest. It would be interesting for the interpretations of model/field comparisons for single gridcells. I would be also interested if the average mineral bulk density and soil texture fractions for each grid cell at L1 could be written out.wishlistSebastian MüllerSebastian Müllerhttps://git.ufz.de/mhm/mhm/-/issues/93check case 04 deactivated for intel debug with MPI2024-02-26T09:59:05+01:00Stephan Thobercheck case 04 deactivated for intel debug with MPIThe check case 04 is deactivated because intel debug mode is failing with MPI.
See comment:
https://git.ufz.de/mhm/mhm/merge_requests/28#note_46699
@kaluza : If you have time, please have a look. From my side, this is not urgent.The check case 04 is deactivated because intel debug mode is failing with MPI.
See comment:
https://git.ufz.de/mhm/mhm/merge_requests/28#note_46699
@kaluza : If you have time, please have a look. From my side, this is not urgent.wishlist futurehttps://git.ufz.de/mhm/mhm/-/issues/99move temporal_disagg_forcing2023-03-08T20:26:29+01:00Stephan Thobermove temporal_disagg_forcingtemporal_disagg_forcing is called in mo_mhm, but should be moved to mo_mhm_evaltemporal_disagg_forcing is called in mo_mhm, but should be moved to mo_mhm_evalwishlist futureSebastian MüllerSebastian Müllerhttps://git.ufz.de/mhm/mhm/-/issues/96mRM: mo_mrm_net_startup revision2020-12-01T09:24:36+01:00Stephan ThobermRM: mo_mrm_net_startup revisionmo_mrm_net_startup.f90 is outdated and needs substantial revision with regard to memory and run timemo_mrm_net_startup.f90 is outdated and needs substantial revision with regard to memory and run time6.xStephan ThoberStephan Thoberhttps://git.ufz.de/mhm/mhm/-/issues/73Creation of a mHM Docker2021-04-19T14:28:11+02:00Sebastian MüllerCreation of a mHM DockerSince we rely on some dependencies, like NetCDF, we could apply the rising idea of deploying mHM as a docker-image.
A docker provides a separate environment, where a plain linux system is provided but that is not running in a virtual mac...Since we rely on some dependencies, like NetCDF, we could apply the rising idea of deploying mHM as a docker-image.
A docker provides a separate environment, where a plain linux system is provided but that is not running in a virtual machine.
This mean:
* encapsulated environment with only the necessary tools/dependencies installed
* easily deploy compiled mHM binaries
* possibility of multiple dockers with different configurations (parallel, ifort, gfortran, nag, ...)
* providing of tested and working environments with fixed version of every dependency
Dockers are running natively on Linux and Windows. On Mac it is running with a Linux kernel running in a virtual machine.
So basically there could be one docker to make everyone happy.
Maybe we could collect some opinions on that here.
References:
* [Docker website](https://www.docker.com/)
* [Getting started with Docker for Developers](https://training.play-with-docker.com/#dev)
* [nctests - Docker image containing NetCDF](https://hub.docker.com/r/unidata/nctests)wishlistSebastian MüllerSebastian Müllerhttps://git.ufz.de/mhm/mhm/-/issues/119check_consistency_lut_map hangs for big L0 domains2024-02-26T09:46:09+01:00Oldrich Rakoveccheck_consistency_lut_map hangs for big L0 domainscheck_consistency_lut_map in MPR/mo_read_wrapper.f90 hangs for ages when L0 matrix is huge (e.g. observed e.g. in the mhm-formind amazonas domain, where ncols = 30720, nrows = 24064).
Possible solution to run mHM is to comment out thos...check_consistency_lut_map in MPR/mo_read_wrapper.f90 hangs for ages when L0 matrix is huge (e.g. observed e.g. in the mhm-formind amazonas domain, where ncols = 30720, nrows = 24064).
Possible solution to run mHM is to comment out those LUT checks for LAI, geology and soil.
We spoke about it with @thober recently - wants to check before the mHM clean-up.wishlist futureSebastian MüllerSebastian Müllerhttps://git.ufz.de/mhm/mhm/-/issues/74Enforce CF conventions on mHM output file2024-02-26T09:46:15+01:00Stephan ThoberEnforce CF conventions on mHM output fileCF conventions expect coordinates at (0,0) to be in lower left corner. For historic reasons, (ESRI conventions), it starts in the upper left. Everything needs to be inverted. Flow directions needs to be adjusted!
Here is the original em...CF conventions expect coordinates at (0,0) to be in lower left corner. For historic reasons, (ESRI conventions), it starts in the upper left. Everything needs to be inverted. Flow directions needs to be adjusted!
Here is the original email from Luis:
> Sorry, I made a mistake in the conventions in my previous email.
> ESRI: currently in mHM. Start top left x_11. It is called "English reading order"
> https://en.m.wikipedia.org/wiki/Esri_grid
> CF convention (I guess) is what Ncview expects. Similar to a coordinate system. x_11 is at (0,0) bottom left.
> Everything is trivial by the inversion of coordinates with the exception of flow direction.
> We need to clean up this issue asap.
> Luis6.xRobert SchweppeRobert Schweppehttps://git.ufz.de/mhm/mhm/-/issues/169Spatial orientation of layers in mRM restart file2024-02-26T09:46:31+01:00sluedtkeSpatial orientation of layers in mRM restart fileExtracting the 2d var "L11_fAcc" from "./restart/mRM_restart_001.nc" and plotting it shows the layer mirrored on both axis. See the picture below, one done with R using the raster package, the other from ncview (not nice, but you get an ...Extracting the 2d var "L11_fAcc" from "./restart/mRM_restart_001.nc" and plotting it shows the layer mirrored on both axis. See the picture below, one done with R using the raster package, the other from ncview (not nice, but you get an idea).
This is not the case for "output/mHM_Fluxes_States.nc". I think it would be great if that is consistent over all files
![2021-01-08-104643_grim](/uploads/58c93fe3fb4a4d00eca8eaa34a0e2adc/2021-01-08-104643_grim.png)
![2021-01-08-104633_grim](/uploads/0f23c94189e603cb42c3d0603e54161d/2021-01-08-104633_grim.png).wishlistStephan ThoberStephan Thoberhttps://git.ufz.de/mhm/mhm/-/issues/235Theoretical documentation of mHM and its modules2024-02-26T09:47:05+01:00Pallav Kumar Shresthapallav-kumar.shrestha@ufz.deTheoretical documentation of mHM and its modulesIf I am not wrong, as of today, the mHM documentation [page](https://mhm.pages.ufz.de/mhm/latest/) has ample content that would comprise say the "user manual" but lacks the "theoretical documentation". The only exception is an awesomely ...If I am not wrong, as of today, the mHM documentation [page](https://mhm.pages.ufz.de/mhm/latest/) has ample content that would comprise say the "user manual" but lacks the "theoretical documentation". The only exception is an awesomely compiled [chapter on mRM](https://mhm.pages.ufz.de/mhm/latest/m_r_m.html).
This lack of easy access of theory behind mHM has been commented by many external users. The current two options modellers have are 1) to dive in the source code to get the information, or 2) read [Samaniego et al. 2010 WRR paper](https://agupubs.onlinelibrary.wiley.com/doi/full/10.1029/2008WR007327) where equations have been layed out but might not be best source to get hold of theory behind mHM on first try.
Questions and comments:
1. Would it make sense to compile chapters for different processes of mHM (snow, evaporation, etc.) like the one for mRM?
2. Who should compile the chapters? Perhaps the authors who are still active with us are the best fitted for this?
3. If this becomes a "multi-person" task, should there be a guideline/ general template that we follow, perhaps the mRM chapter. In my opinion this is important as the structure gives better readability? [This is a reference theoretical documentation](https://swat.tamu.edu/media/99192/swat2009-theory.pdf), which has this nice idea of tabulating the variables and parameters related to a process at end of each chapter.
I am pretty sure this will require some planning and time to complete. Just bringing up the topic so that we communicate on this matter.
Tagging @thober, @rkumar and @lese here.wishlistSebastian MüllerSebastian Müllerhttps://git.ufz.de/mhm/mhm/-/issues/240Hourly discharge simulations require that provided Qobs file starts at hour 0...2024-02-26T09:47:22+01:00Oldrich RakovecHourly discharge simulations require that provided Qobs file starts at hour 00 and end at hour 23To print out hourly discharge simulations, current implementation requires that provided Qobs file starts at hour 00 and end at hour 23,
otherwise, mHM provides only daily Qobs file without the `subdaily_discharge` output file.
We wil...To print out hourly discharge simulations, current implementation requires that provided Qobs file starts at hour 00 and end at hour 23,
otherwise, mHM provides only daily Qobs file without the `subdaily_discharge` output file.
We will provide with @shresthp test datawishlistSebastian MüllerSebastian Müllerhttps://git.ufz.de/mhm/mhm/-/issues/243Multiple inflow gauges in a single grid is not yet allowed in mHM2024-02-26T09:47:30+01:00Pallav Kumar Shresthapallav-kumar.shrestha@ufz.deMultiple inflow gauges in a single grid is not yet allowed in mHM**Background**
Currently mHM only accepts one inflow gauge per L11 grid.
**Issue**
If there are more than one inflow gauge per L11 grid, it only takes one of the inflow gauge. This obviously leads to error.
Seems we need to add this...**Background**
Currently mHM only accepts one inflow gauge per L11 grid.
**Issue**
If there are more than one inflow gauge per L11 grid, it only takes one of the inflow gauge. This obviously leads to error.
Seems we need to add this feature in the [add_inflow subroutine](https://git.ufz.de/mhm/mhm/-/blob/develop/src/mRM/mo_mrm_pre_routing.f90#L179) ??
Tagging subroutine author @thober here :)wishlistSebastian MüllerSebastian Müllerhttps://git.ufz.de/mhm/mhm/-/issues/253Parameter in parameter namelist misslabeled2024-02-26T09:47:43+01:00Carla PeterParameter in parameter namelist misslabeledWithin mhm_parameter.nml parameter rootFractionCoefficient_pervious seems not to have been renamed after changes in the parametrization in 2013 (see mo_mpr_smhorizons.f90 for reference).
Instead of the absolute value, the difference to ...Within mhm_parameter.nml parameter rootFractionCoefficient_pervious seems not to have been renamed after changes in the parametrization in 2013 (see mo_mpr_smhorizons.f90 for reference).
Instead of the absolute value, the difference to rootFractionCoefficient_forest is now fitted, so the parameter should be labelled Delta.https://git.ufz.de/mhm/mhm/-/issues/254Doc: MacOS install instructions missing netcdf-fortran package2024-02-26T09:47:50+01:00Sebastian MüllerDoc: MacOS install instructions missing netcdf-fortran packageThere is a [new homebrew formula](https://github.com/Homebrew/homebrew-core/commit/6e5d43832dd8680fd58b292b0514bc150244be1c) for [netcdf-fortran](https://formulae.brew.sh/formula/netcdf-fortran).
Before, netcdf-fortran was part of the [...There is a [new homebrew formula](https://github.com/Homebrew/homebrew-core/commit/6e5d43832dd8680fd58b292b0514bc150244be1c) for [netcdf-fortran](https://formulae.brew.sh/formula/netcdf-fortran).
Before, netcdf-fortran was part of the [netcdf formula](https://github.com/Homebrew/homebrew-core/pull/112159).Sebastian MüllerSebastian Müllerhttps://git.ufz.de/mhm/mhm/-/issues/249Test domains: check coordinates of meteo files2024-03-26T11:44:18+01:00Sebastian MüllerTest domains: check coordinates of meteo filesWe found a discrepancy in the input files of test domain 2, where the coordinates of latlon.nc differ from the coordinates of pre.nc although they are on the same level.We found a discrepancy in the input files of test domain 2, where the coordinates of latlon.nc differ from the coordinates of pre.nc although they are on the same level.https://git.ufz.de/mhm/mhm/-/issues/125restoring older parameter ranges for &soilmoisture12020-11-27T13:44:08+01:00Oldrich Rakovecrestoring older parameter ranges for &soilmoisture1Attached are the updated parameter ranges for &soilmoisture1 process provided by @lese and @rkumar, based on the initial mHM code.
We are using them currently in the latest GDM calibrations, to ensure realistic ThetaS values. [GAMMA.LOO...Attached are the updated parameter ranges for &soilmoisture1 process provided by @lese and @rkumar, based on the initial mHM code.
We are using them currently in the latest GDM calibrations, to ensure realistic ThetaS values. [GAMMA.LOOKUP.txt](/uploads/d334d345b7a4532043ef67bda9ce7638/GAMMA.LOOKUP.txt)
Probably good to replace the older one in the next release? Thanks!
@thoberwishlist futureSebastian MüllerSebastian Müllerhttps://git.ufz.de/mhm/mhm/-/issues/135BUGFIX: river network not accepting multiple outlets if L0 == L112020-10-05T17:05:13+02:00Stephan ThoberBUGFIX: river network not accepting multiple outlets if L0 == L11
https://git.ufz.de/ulysses/mrm/-/commit/009799e9be526142aef349c211d06df526720e96
https://git.ufz.de/ulysses/mrm/-/commit/009799e9be526142aef349c211d06df526720e96Integrate UlyssesStephan ThoberStephan Thoberhttps://git.ufz.de/mhm/mhm/-/issues/47pan evap coefficient2020-12-01T09:24:46+01:00Stephan Thoberpan evap coefficientI had a very interesting discussion with @westerma yesterday. He looked through the mHM code quite carefully trying to understand how mHM is working. I was able to clarify most of his questions, but not the following:
For ET from sealed...I had a very interesting discussion with @westerma yesterday. He looked through the mHM code quite carefully trying to understand how mHM is working. I was able to clarify most of his questions, but not the following:
For ET from sealed areas, there is a correction factor (evap_coeff in line 195 in mo_soil_moisture.f90).
``
aet_sealed = (pet / evap_coeff - aet_canopy) * (storage_sealed / water_thresh_sealed)
``
The coefficient is specified in the mhm.nml and reduces PET during winter and increases it during spring. My question to @lese and @rkumar: What is the idea behind this correction? Is there a reference for this correction?
I guess we should implement it in a spatially varying fashion similar to the night factors for precip and temperature. I would assume that applying this correction in a global setup makes little sense, although the overall effect is not big as it only affects sealed areas.wishlist futureStephan ThoberStephan Thoberhttps://git.ufz.de/mhm/mhm/-/issues/76Upscale LatLon from Level02020-10-05T16:55:31+02:00Stephan ThoberUpscale LatLon from Level0Currently, latlon file has to be provided at model resolution. Instead, it should follow MPR approach and be upscaled from highest resolution.Currently, latlon file has to be provided at model resolution. Instead, it should follow MPR approach and be upscaled from highest resolution.6.xRobert SchweppeRobert Schweppehttps://git.ufz.de/mhm/mhm/-/issues/80Scripts on quality control checks (e.g. Beta parameters)2020-10-05T16:24:06+02:00Oldrich RakovecScripts on quality control checks (e.g. Beta parameters)As discussed on the last mhm meeting,
it would be nice to have some scripts for quality control checks (e.g. on the internal Beta parameters)As discussed on the last mhm meeting,
it would be nice to have some scripts for quality control checks (e.g. on the internal Beta parameters)wishlistRobert SchweppeRobert Schweppehttps://git.ufz.de/mhm/mhm/-/issues/144consistent handling of units in mHM2022-04-28T16:07:04+02:00Robert Schweppeconsistent handling of units in mHMWe should have a clear documentation of which physical units are used internally. For example in the current develop in
`mo_snow_accum_melt.f90` in lines 96 there is
```
! Snow pack [m]
REAL(dp), INTENT(INOUT) :: snow_pack
```
a...We should have a clear documentation of which physical units are used internally. For example in the current develop in
`mo_snow_accum_melt.f90` in lines 96 there is
```
! Snow pack [m]
REAL(dp), INTENT(INOUT) :: snow_pack
```
and this variable is passed onto the writing in the netcdf files where in `mo_write_fluxes_states.f90` it says in lines 287
```
tmpvars(ii) = OutputVariable(&
nc, "snowpack", dtype, dims1, nCells, mask1, .true.)
call writeVariableAttributes(tmpvars(ii), "depth of snowpack", "mm")
```
So what is it then - `m` or `mm`?
It should be a starting point for implementing [CF Conventions](https://cfconventions.org/Data/cf-conventions/cf-conventions-1.8/cf-conventions.html) and [Udunits](https://www.unidata.ucar.edu/software/udunits/). Maybe it is also worth checking out an analysis tool that checks for errors in scientific Fortran Code [CamFort](https://github.com/camfort/camfort).wishlist futurehttps://git.ufz.de/mhm/mhm/-/issues/72Rename parameter name for organic forest content2020-10-05T17:04:32+02:00Stephan ThoberRename parameter name for organic forest content6.xStephan ThoberStephan Thoberhttps://git.ufz.de/mhm/mhm/-/issues/157[Repo] Decrease size of Git repository2021-11-15T15:20:12+01:00Sebastian Müller[Repo] Decrease size of Git repositoryThe repository is now over 2GB large. We should think about cutting down the size, by rewriting the history:
https://github.com/newren/git-filter-repoThe repository is now over 2GB large. We should think about cutting down the size, by rewriting the history:
https://github.com/newren/git-filter-repo6.xSebastian MüllerSebastian Müllerhttps://git.ufz.de/mhm/mhm/-/issues/158[Cleanup] Remove unsupported pre-processor directives2020-10-14T11:52:27+02:00Sebastian Müller[Cleanup] Remove unsupported pre-processor directivesThere are a lot of unsupported directives for `cpp` and `fpp`:
- `pgiFortran`: as mentionend in #121, we will drop support until the new flang compiler is available
- `pgiFortran154`: same as with `pgiFortran`
- `GFORTRAN41`: since we on...There are a lot of unsupported directives for `cpp` and `fpp`:
- `pgiFortran`: as mentionend in #121, we will drop support until the new flang compiler is available
- `pgiFortran154`: same as with `pgiFortran`
- `GFORTRAN41`: since we only support `gcc >= 7.3` we can drop this one
- `ABSOFT`: we only support `GNU`, `INTEL` and `NAG`
- `MPR_STANDALONE`: MPR will be provided as a dependency starting with `mHM v6.0` (@ottor should we keep it for now?)
I would like to remove these directives, so the code-base gets cleaner.6.xSebastian MüllerSebastian Müllerhttps://git.ufz.de/mhm/mhm/-/issues/164[CI] fails occasionally (mo_objective_function)2023-05-12T15:06:32+02:00Sebastian Müller[CI] fails occasionally (mo_objective_function)@kaluza and me (@muellese) noticed, that the gitlab CI fails occasionally, because it can't compile mhm since it is missing `mo_objective_function.mod`.
This happens for all compilers (gcc83, intel20, nag62 already reported)
This can b...@kaluza and me (@muellese) noticed, that the gitlab CI fails occasionally, because it can't compile mhm since it is missing `mo_objective_function.mod`.
This happens for all compilers (gcc83, intel20, nag62 already reported)
This can be fixed at occurrence with a retry or deleting the build folder on eve (`/public/mhm_runner/....`).
I am at my wit's end. At least for nowwishlist futureSebastian MüllerSebastian Müllerhttps://git.ufz.de/mhm/mhm/-/issues/168L2 L1 resolution compatibility issues in mo_spatial_agg_disaggregation while ...2021-02-03T16:00:27+01:00Pallav Kumar Shresthapallav-kumar.shrestha@ufz.deL2 L1 resolution compatibility issues in mo_spatial_agg_disaggregation while producing L1 meteorology**Issue**
When L2 > L1, mHM downscales the L2 meteorology to generate L1 meteorology. When L2 < L1, mHM upscales the L2 meteorology to generate L1 meteorology. This calculation takes place in mo_spatial_agg_disaggregation.
Refer to fig...**Issue**
When L2 > L1, mHM downscales the L2 meteorology to generate L1 meteorology. When L2 < L1, mHM upscales the L2 meteorology to generate L1 meteorology. This calculation takes place in mo_spatial_agg_disaggregation.
Refer to figure below. The extent of model input (blue border) varies based on the catchment (grey shadow). In the current form, the mo_spatial_agg_disaggregation upscaling and downscaling routines is based on ceiling function and has following effect -
- (left) Extent of L1 exactly covers L2 extent/ data extent **+** L2 is a multiple of L1 : correct L1 meteorology
- (centre) Extent of L1 exactly covers L2 extent/ data extent **but** L2 is NOT a multiple of L1 : errors induced in L1 meteorology as L1 cell gets value of one L2 cell, but still works
- (right) Extent of L1 is not equal to L2 extent/ data extent **and** L2 is NOT a multiple of L1 : mHM fails in debug mode at mo_spatial_agg_disaggregation
![Screenshot_2021-01-05_at_12.13.15](/uploads/3d5530aa6029f2ca88d74ea1d9879006/Screenshot_2021-01-05_at_12.13.15.png)
**Proposal**
The `ceiling based` downscaling in mo_spatial_agg_disaggregation is incompatible to the latter two scenarios mentioned above. A better alternative would be `area based calculation` where L0 area (grey shadow) and L2 area/s are used to downscale L2 to L1. This would, in principle, improve scalability compromises previously induced in mHM from L1 meteorology. This corresponds to the `approach of SCC` in mLM as well.
We should bear in mind that, if accepted, this approach would change the reference for mHM test cases.
**Issues in mLM development**
Below is a screenshot showing a test case of mLM exhibiting the above issue of incorrect L1 meteorology. The extent was as in the third case, and nodata count is > 0 whenever L2 is not a multiple of L1, during downscaling. However, this is not the case with upscaling although the domain average tmax and tmin calculated from L1 values deviate a bit from what it should be (L1 = 0.05, 0.25). For mLM, a dirty patch has been applied with [this commit](https://git.ufz.de/shresthp/mhm/-/commit/47fa930d6c4010bbfc3feea9b18610e60e259cac) in mLM fork and resolved issue mhm/mhm#167. However, mLM awaits a better solution from develop at mo_spatial_agg_disaggregation.
![Screenshot_2021-01-05_at_11.45.03](/uploads/cbd079c192f5daf5474999559724a4b9/Screenshot_2021-01-05_at_11.45.03.png)6.xSebastian MüllerSebastian Müllerhttps://git.ufz.de/mhm/mhm/-/issues/171mHM crash when time_step_model_inputs(1) = -1 (daily)2023-05-12T15:07:54+02:00Husain Najafihusain.najafi@ufz.demHM crash when time_step_model_inputs(1) = -1 (daily)I was trying to run mHM for a long time period (1947-2019). When "_time_step_model_inputs_" in _mhm.nml _was assigned to -1 (daily time step), mHM was crashed by providing the following error
Error:
Run mHM
Could not inquire variabl...I was trying to run mHM for a long time period (1947-2019). When "_time_step_model_inputs_" in _mhm.nml _was assigned to -1 (daily time step), mHM was crashed by providing the following error
Error:
Run mHM
Could not inquire variable: pet
NetCDF: Not a valid ID
Once I investigated input data, the meteorological forcing did not have any issues. Note that there will be no error if "time_step_model_inputs(1)" is set to -2 (monthly).wishlistSebastian MüllerSebastian Müllerhttps://git.ufz.de/mhm/mhm/-/issues/172Specifiaciton of input file names via mhm.nml2021-02-16T09:26:30+01:00sluedtkeSpecifiaciton of input file names via mhm.nmlI think this is a feature request :-).
we are in the happy situation to have our entire mhm setup in a git repo. For our application, we have to have two different files for flow accumulation that are used as input, depending on the cu...I think this is a feature request :-).
we are in the happy situation to have our entire mhm setup in a git repo. For our application, we have to have two different files for flow accumulation that are used as input, depending on the current question we want to address.
I am currently thinking that the best way would be to have always both files present in the morph folder (eg. facc_a.asc, facc_b.asc) and tell mhm via the "mhm.nml" file which one to use. Doing so, the only thing we have to commit are the changes in the mhm.nml file but that would require that were are able to specify the flow accumulation file of interest in the name list.
The second approach would be to checkout the file of interest depending on the current task, but that would mean that we are changing a rather big file over and over again, what is not very nice.
Any help on that is appreciated.6.xSebastian MüllerSebastian Müllerhttps://git.ufz.de/mhm/mhm/-/issues/189mo_sce.restart is not created2023-05-12T15:07:38+02:00Mehmet Cüneyd Demirelmo_sce.restart is not createdHi @muellese
I tried these two options with cygwin and ubuntu LTS but I couldnt find where "mo_sce.restart" is created.
```fortran
optimize = .True.
optimize_restart = .False.
```
I check output_b1 and upper folder. I could only see sc...Hi @muellese
I tried these two options with cygwin and ubuntu LTS but I couldnt find where "mo_sce.restart" is created.
```fortran
optimize = .True.
optimize_restart = .False.
```
I check output_b1 and upper folder. I could only see sce_population and sce_results files.wishlistSebastian MüllerSebastian Müllerhttps://git.ufz.de/mhm/mhm/-/issues/192update check_case 112024-02-26T09:59:05+01:00Robert Schweppeupdate check_case 11The check case uses KGE for TWS which is not good because of small changes around zero have huge impacts on KGE (even within machine precision). See: https://git.ufz.de/mhm/mhm/-/merge_requests/78#note_122705
In branch develop_v6, this ...The check case uses KGE for TWS which is not good because of small changes around zero have huge impacts on KGE (even within machine precision). See: https://git.ufz.de/mhm/mhm/-/merge_requests/78#note_122705
In branch develop_v6, this case is disabled for now. What options are there for a replacement?
`Opti_function` 15 uses KGE Q and RMSE TWS, this would be my first guess. However, `opti_function`s 28, 15 and 17 are already checked. So we skip it? Or update it, is KGE_q_KGE_ET_RMSE_TWS better, what are you currently using in the global runs @rakovec6.xSebastian MüllerSebastian Müllerhttps://git.ufz.de/mhm/mhm/-/issues/195Potential bug in mo_common_datetime_type with yID2021-07-09T11:59:10+02:00Robert SchweppePotential bug in mo_common_datetime_type with yIDIn https://git.ufz.de/mhm/mhm/-/blob/develop/src/common/mo_common_datetime_type.f90 there is the property `yID` storing the ID of the land cover period associated for each year. This is set only at `init` but then not touched anymore. Wh...In https://git.ufz.de/mhm/mhm/-/blob/develop/src/common/mo_common_datetime_type.f90 there is the property `yID` storing the ID of the land cover period associated for each year. This is set only at `init` but then not touched anymore. Why is not changed in `increment`, when the year is advanced? `increment` is called in `mhm_eval` and `%yId` is used to select the correct parameter slice. Obviously, checks do not fail, but I stumbled upon it and it does not make sense to me.wishlist futureSebastian MüllerSebastian Müllerhttps://git.ufz.de/mhm/mhm/-/issues/207Landcover dependent model parameters2021-11-17T14:49:45+01:00Rohini KumarLandcover dependent model parametersAt the moment with v.5.11.2 we have landcover dependent parameters assigned for all landcover scenes at the start (unlike the older versions where parameters were updated once LC scene was changed). In my opinion this will have implicati...At the moment with v.5.11.2 we have landcover dependent parameters assigned for all landcover scenes at the start (unlike the older versions where parameters were updated once LC scene was changed). In my opinion this will have implications if we have multiple LC scenes and corresponding parameters are allocated at the start especially running over a big spatial domain - from memory point of view... Any thoughts on this? I will make some runs to see the computational demand of with this and older options.. When/why does this change happen; and what are the implications? Thoughts are welcome.6.xhttps://git.ufz.de/mhm/mhm/-/issues/208Improve error message for DDS2021-11-12T13:14:38+01:00Pallav Kumar Shresthapallav-kumar.shrestha@ufz.deImprove error message for DDS**Issue**
We need to improve error message for DDS when the observations are missing for optimization. ATM we get a `developer level message` which is completely out of context for mhm users who don't know much about the source code. In...**Issue**
We need to improve error message for DDS when the observations are missing for optimization. ATM we get a `developer level message` which is completely out of context for mhm users who don't know much about the source code. In general, the mhm error messages should transition from `developer level` to `user level`.
**Location**
[Occurrence 1](https://git.ufz.de/mhm/mhm/-/blob/ff81bd9f6624429c019f416136447ca28b3b676e/src/lib/mo_dds.f90#L224)
[Occurrence 2](https://git.ufz.de/mhm/mhm/-/blob/ff81bd9f6624429c019f416136447ca28b3b676e/src/lib/mo_dds.f90#L532)
**Complexity**
However, this example is a bit different to others in the sense that the message is embedded in `mo_dds` which is part of [FORCES](https://git.ufz.de/chs/forces/-/blob/develop/src/mo_dds.F90) library.
**Challenge**
To find a way to communicate with mhm user based on errors occurring at modules of shared/ external libraries like FORCES.
![Screenshot_2021-10-27_at_13.34.08](/uploads/415e67ca964f986cbd6da433a5745327/Screenshot_2021-10-27_at_13.34.08.png)wishlist futureSebastian MüllerSebastian Müllerhttps://git.ufz.de/mhm/mhm/-/issues/210improve check case 04 impact2022-01-13T17:02:42+01:00Robert Schweppeimprove check case 04 impactI do not really know, what test case 4 is supposed to check, but the case could cover more than it does so far:
- share common L0 data (only works in current settings for version 5.x) -> reordering of domains
- multiple different land co...I do not really know, what test case 4 is supposed to check, but the case could cover more than it does so far:
- share common L0 data (only works in current settings for version 5.x) -> reordering of domains
- multiple different land cover periods -> change simulation periods
- all routing/hydrology resolution combinations
I would propose this for version 6.x, what do you think @muellese?6.xSebastian MüllerSebastian Müllerhttps://git.ufz.de/mhm/mhm/-/issues/212check case 02 cell area2021-11-19T09:58:45+01:00Robert Schweppecheck case 02 cell areaI currently work on the mpr_finalize branch. There, check case 02 is failing. This check case is with `process_08==0`, a.k.a. routing turned off. The thing is now, that mHM does not have a clue about `level0` anymore and `level1` grid in...I currently work on the mpr_finalize branch. There, check case 02 is failing. This check case is with `process_08==0`, a.k.a. routing turned off. The thing is now, that mHM does not have a clue about `level0` anymore and `level1` grid information is inferred from the grid that the MPR generated parameters are on. It gets `lat`, `lon`, `mask` and that's it.
So there is no information on the cell area (relative area for each level1 cell that is covered by level0 cells). That is only done in mrm_init (mRM-MPR is still in mRM, it reads level0 land cover and dem) and calculated based on the level0 dem. So, as routing is turned off, cellArea is calculated based on the lat-lon grid spacing (meaning each level1 cell is 100% covered by level0). The check case fails here now. What to do (@muellese, @thober)?
Options:
- accept new behaviour, ignore failing check case and update reference files for version 6
- always calculate a pseudo-parameter "cellArea" in MPR, pass that to mHM and hard-code overwrite cellArea for level1 there6.xhttps://git.ufz.de/mhm/mhm/-/issues/219Priestley Taylor coefficient regionalisation and water bodies2023-05-12T15:06:19+02:00Pallav Kumar Shresthapallav-kumar.shrestha@ufz.dePriestley Taylor coefficient regionalisation and water bodies- The Priestley Taylor coefficient (𝜶) regionalisation in mHM is currently based on a Transfer Function where the 𝜶 is a Linear function of LAI.
- For water bodies (e.g. lakes), LAI = 0 and 𝜶 would be constant everywhere in the world. T...- The Priestley Taylor coefficient (𝜶) regionalisation in mHM is currently based on a Transfer Function where the 𝜶 is a Linear function of LAI.
- For water bodies (e.g. lakes), LAI = 0 and 𝜶 would be constant everywhere in the world. This is the case when regionalised 𝜶 is employed to estimate lake evaporation using Priestley-Taylor (1972) or de Bruin (1978) procedures.
- Moreover, this constant 𝜶 for water bodies would take the value of the parameter `PrestleyTaylorCoef` which can be as low as 0.75 and high as 1.75 which is not realistic.
- A new transfer function for 𝜶 that takes water bodies landcover class into consideration should be incorporated. This allows mLM to be streamlined to mHM.
![image](/uploads/4a0c7388ffcc321b586c50f0be3ffdbb/image.png)
![image](/uploads/99834e2b756c889db292b40b363f874a/image.png)wishlist futurehttps://git.ufz.de/mhm/mhm/-/issues/224Container for Namelist2022-07-07T10:40:24+02:00Sebastian MüllerContainer for NamelistIn order to be able to set configurations dynamically, it would be good to have a type representation for namelists.
There could be a abstract type implementation in FORCES to provide a template for namelists and routines to read or set...In order to be able to set configurations dynamically, it would be good to have a type representation for namelists.
There could be a abstract type implementation in FORCES to provide a template for namelists and routines to read or set values.
ATM we have the following namelists defined in mHM:
```
src/common/mo_common_read_config.F90:
108 ! namelist directories
109: namelist /project_description/ project_details, setup_description, simulation_type, &
110 Conventions, contact, mHM_details, history
111: namelist /directories_general/ dirConfigOut, dirCommonFiles, &
112 dir_Morpho, dir_LCover, &
115 ! namelist spatial & temporal resolution, optimization information
116: namelist /mainconfig/ iFlag_cordinate_sys, resolution_Hydrology, nDomains, L0Domain, write_restart, &
117 read_opt_domain_data
118 ! namelist process selection
119: namelist /processSelection/ processCase
120
121 ! namelist for land cover scenes
122: namelist/LCover/nLcoverScene, LCoverYearStart, LCoverYearEnd, LCoverfName
123
src/common_mHM_mRM/mo_common_mHM_mRM_read_config.f90:
86 ! namelist spatial & temporal resolution, otmization information
87: namelist /mainconfig_mhm_mrm/ timestep, resolution_Routing, optimize, &
88 optimize_restart, opti_method, opti_function, &
90 ! namelist for optimization settings
91: namelist /Optimization/ nIterations, seed, dds_r, sa_temp, sce_ngs, &
92 sce_npg, sce_nps, mcmc_opti, mcmc_error_params
93 ! namelist for time settings
94: namelist /time_periods/ warming_Days, eval_Per
95
src/mHM/mo_mhm_read_config.f90:
160 ! namelist directories
161: namelist /directories_mHM/ &
162 inputFormat_meteo_forcings, &
173 ! optional data used for optimization
174: namelist /optional_data/ &
175 dir_soil_moisture, &
184 ! namelist for pan evaporation
185: namelist /panEvapo/evap_coeff
186
187 ! namelist for night-day ratio of precipitation, referenceET and temperature
188: namelist /nightDayRatio/ read_meteo_weights, &
189 fnight_prec, fnight_pet, fnight_temp, fnight_ssrd, fnight_strd
190 ! name list regarding output
191: namelist /NLoutputResults/ &
192 output_deflate_level, &
src/MPR/mo_mpr_read_config.f90:
234 ! namelist directories
235: namelist /directories_MPR/ dir_gridded_LAI
236 ! namelist soil database
237: namelist /soildata/ iFlag_soilDB, tillageDepth, nSoilHorizons_mHM, soil_Depth
238 ! namelist for LAI related data
239: namelist /LAI_data_information/ inputFormat_gridded_LAI, timeStep_LAI_input
240 ! namelist for land cover scenes
241: namelist /LCover_MPR/ fracSealed_cityArea
242
243 ! namelist parameters
244: namelist /interception1/ canopyInterceptionFactor
245: namelist /snow1/snowTreshholdTemperature, degreeDayFactor_forest, degreeDayFactor_impervious, &
246 degreeDayFactor_pervious, increaseDegreeDayFactorByPrecip, maxDegreeDayFactor_forest, &
247 maxDegreeDayFactor_impervious, maxDegreeDayFactor_pervious
248: namelist /soilmoisture1/ orgMatterContent_forest, orgMatterContent_impervious, orgMatterContent_pervious, &
249 PTF_lower66_5_constant, PTF_lower66_5_clay, PTF_lower66_5_Db, PTF_higher66_5_constant, &
253 rootFractionCoefficient_pervious, infiltrationShapeFactor
254: namelist /soilmoisture2/ orgMatterContent_forest, orgMatterContent_impervious, orgMatterContent_pervious, &
255 PTF_lower66_5_constant, PTF_lower66_5_clay, PTF_lower66_5_Db, PTF_higher66_5_constant, &
259 rootFractionCoefficient_pervious, infiltrationShapeFactor, jarvis_sm_threshold_c1
260: namelist /soilmoisture3/ orgMatterContent_forest, orgMatterContent_impervious, orgMatterContent_pervious, &
261 PTF_lower66_5_constant, PTF_lower66_5_clay, PTF_lower66_5_Db, PTF_higher66_5_constant, &
266 rootFractionCoefficient_clay, FCmin_glob, FCdelta_glob, jarvis_sm_threshold_c1
267: namelist /soilmoisture4/ orgMatterContent_forest, orgMatterContent_impervious, orgMatterContent_pervious, &
268 PTF_lower66_5_constant, PTF_lower66_5_clay, PTF_lower66_5_Db, PTF_higher66_5_constant, &
273 rootFractionCoefficient_clay, FCmin_glob, FCdelta_glob
274: namelist /directRunoff1/ imperviousStorageCapacity
275 ! PET is input, LAI driven correction
276: namelist /PETminus1/ PET_a_forest, PET_a_impervious, PET_a_pervious, PET_b, PET_c
277 ! PET is input, aspect driven correction
278: namelist /PET0/ minCorrectionFactorPET, maxCorrectionFactorPET, aspectTresholdPET
279 ! Hargreaves-Samani
280: namelist /PET1/ minCorrectionFactorPET, maxCorrectionFactorPET, aspectTresholdPET, HargreavesSamaniCoeff
281 ! Priestely-Taylor
282: namelist /PET2/ PriestleyTaylorCoeff, PriestleyTaylorLAIcorr
283 ! Penman-Monteith
284: namelist /PET3/ canopyheigth_forest, canopyheigth_impervious, canopyheigth_pervious, displacementheight_coeff, &
285 roughnesslength_momentum_coeff, roughnesslength_heat_coeff, stomatal_resistance
286: namelist /interflow1/ interflowStorageCapacityFactor, interflowRecession_slope, fastInterflowRecession_forest, &
287 slowInterflowRecession_Ks, exponentSlowInterflow
288: namelist /percolation1/ rechargeCoefficient, rechargeFactor_karstic, gain_loss_GWreservoir_karstic
289: namelist /neutrons1/ Desilets_N0, COSMIC_N0, COSMIC_N1, COSMIC_N2, COSMIC_alpha0, COSMIC_alpha1, COSMIC_L30, COSMIC_L31
290 !
291: namelist /geoparameter/ GeoParam
292
src/mRM/mo_mrm_read_config.f90:
111 ! namelist spatial & temporal resolution, optmization information
112: namelist /mainconfig_mrm/ ALMA_convention, &
113 filenameTotalRunoff, varnameTotalRunoff, gw_coupling
114 ! namelist directories
115: namelist /directories_mRM/ dir_Gauges, dir_Total_Runoff, dir_Bankfull_Runoff
116: namelist /evaluation_gauges/ nGaugesTotal, NoGauges_domain, Gauge_id, gauge_filename
117 ! namelist for inflow gauges
118: namelist /inflow_gauges/ nInflowGaugesTotal, NoInflowGauges_domain, InflowGauge_id, &
119 InflowGauge_filename, InflowGauge_Headwater
120 ! name list regarding output
121: namelist /NLoutputResults/ &
122 output_deflate_level_mrm, &
458
459: namelist /routing1/ muskingumTravelTime_constant, muskingumTravelTime_riverLength, &
460 muskingumTravelTime_riverSlope, muskingumTravelTime_impervious, muskingumAttenuation_riverSlope
461: namelist /routing2/ streamflow_celerity
462: namelist /routing3/ slope_factor
463 !
src/mRM/mo_mrm_riv_temp_class.f90:
155 ! namelist for river temperature configuration
156: namelist /config_riv_temp/ &
157 albedo_water, &
```wishlist futureSebastian MüllerSebastian Müllerhttps://git.ufz.de/mhm/mhm/-/issues/234Flexibility to specify starting and ending hours/minutes in mHM name list for...2022-08-26T10:42:28+02:00Husain Najafihusain.najafi@ufz.deFlexibility to specify starting and ending hours/minutes in mHM name list for simulation time periodWith respect to the new mHM developments (reading hourly meteo forcing in particular), a need has been raised to specify hours and minutes for mHM simulation time period (for the given start and end day in mhm.nml). The issue at the mome...With respect to the new mHM developments (reading hourly meteo forcing in particular), a need has been raised to specify hours and minutes for mHM simulation time period (for the given start and end day in mhm.nml). The issue at the moment is that starting and ending period of the model simulations can only be 00:00 and 23:00, respectively.
It would be great if one can specify %H and %M for simulation period for the starting and ending simulation period, something like
eval_Per(1)%H Start
eval_Per(1)%M Start
eval_Per(1)%H End
eval_Per(1)%M End
With that, one can run mHM for more flexible simulation periods (not necessarily as a dividend of 24-hours), e.g. a 36-hour run starting from any hour of ineterst, say e.g. 03:00 AM. This would be of interest for flood forecasting applications or in cases where meteorological data are recorded from any hours/minutes rather than only 00:00.wishlist futurehttps://git.ufz.de/mhm/mhm/-/issues/236Soil horizon (depth) information is missing in mHM output2023-05-12T15:05:01+02:00Pallav Kumar Shresthapallav-kumar.shrestha@ufz.deSoil horizon (depth) information is missing in mHM output**Issue**
Currently, there is no way to get the information on soil horizon depths of mHM output.
**Solution**
Add the soil horizon information in mHM output. This would be -
1. In `mHM_Fluxes_States.nc` file
2. But adding this infor...**Issue**
Currently, there is no way to get the information on soil horizon depths of mHM output.
**Solution**
Add the soil horizon information in mHM output. This would be -
1. In `mHM_Fluxes_States.nc` file
2. But adding this information to `ConfigFile.log` would also make it "more visible" (??)
Tagging @thober and @rkumar here.wishlist futureSebastian MüllerSebastian Müllerhttps://git.ufz.de/mhm/mhm/-/issues/237Simple ideas to improve current snow module in mHM2023-05-12T15:05:59+02:00Pallav Kumar Shresthapallav-kumar.shrestha@ufz.deSimple ideas to improve current snow module in mHMI checked the parameterisation of snow process in mHM, MPR. I noticed that `elevation` and `aspect` haven't been used as a predictor variable for estimating effective parameters (betas) for snow.
I was wondering whether adding elevatio...I checked the parameterisation of snow process in mHM, MPR. I noticed that `elevation` and `aspect` haven't been used as a predictor variable for estimating effective parameters (betas) for snow.
I was wondering whether adding elevation and aspect as predictor variables could be "one of the steps" towards improving snow melting in mHM (??).
![220907_snow_and_elevation](/uploads/c5b8715000918e54e8328d551cb6ce27/220907_snow_and_elevation.gif)
Tagging @thober @rkumar @lesewishlist futureSebastian MüllerSebastian Müllerhttps://git.ufz.de/mhm/mhm/-/issues/247L2/L1 and L11/L1 cell-factors are never checked to be integer2023-05-12T15:04:36+02:00Sebastian MüllerL2/L1 and L11/L1 cell-factors are never checked to be integerAll levels are created from L0 but they are never checked to have matching cell-sizes.
This creates miscalculations for example when (dis-)aggregating meteo-data from for example a 3km grid (L2) to a 2km grid (L1).
Both grids are totall...All levels are created from L0 but they are never checked to have matching cell-sizes.
This creates miscalculations for example when (dis-)aggregating meteo-data from for example a 3km grid (L2) to a 2km grid (L1).
Both grids are totally fine for a 100m grid on L0 but the averaging of the meteo-data is wrongly calculated.
Same is true for the routing resolutions (L11).wishlisthttps://git.ufz.de/mhm/mhm/-/issues/248mrm_coupling_mode should be removed2023-05-12T15:04:26+02:00Sebastian Müllermrm_coupling_mode should be removedmrm_coupling_mode is hard coded to be 2 since the standalone version of mRM is not further supported (and even broken)
So we should remove this coupling mode and related doubled code (level1 latlon info and level0 info is read twice cur...mrm_coupling_mode is hard coded to be 2 since the standalone version of mRM is not further supported (and even broken)
So we should remove this coupling mode and related doubled code (level1 latlon info and level0 info is read twice currently).wishlist futurehttps://git.ufz.de/mhm/mhm/-/issues/250pybind: missing variables in get methods2024-02-08T10:12:17+01:00Sebastian Müllerpybind: missing variables in get methodsSome L1 variables calculated by MPR are missing in the getter methods:
- `L1_fSealed(:, 1 : 1, 1 : nLCoverScene)` (already present)
- `L1_alpha(:, 1 : 1, 1 : nLCoverScene)`
- `L1_degDayInc(:, 1 : 1, 1 : nLCoverScene)`
- `L1_degDayMax(:, ...Some L1 variables calculated by MPR are missing in the getter methods:
- `L1_fSealed(:, 1 : 1, 1 : nLCoverScene)` (already present)
- `L1_alpha(:, 1 : 1, 1 : nLCoverScene)`
- `L1_degDayInc(:, 1 : 1, 1 : nLCoverScene)`
- `L1_degDayMax(:, 1 : 1, 1 : nLCoverScene)`
- `L1_degDayNoPre(:, 1 : 1, 1 : nLCoverScene)`
- `L1_degDay(:, 1 : 1, 1 : nLCoverScene)`
- `L1_karstLoss(:, 1 : 1, 1 : 1)`
- `L1_fAsp(:, 1 : 1, 1 : 1)`
- `L1_petLAIcorFactor(:, 1 : nLAI, 1 : nLCoverScene)`
- `L1_HarSamCoeff(:, 1 : 1, 1 : 1)`
- `L1_PrieTayAlpha(:, 1 : nLAI, 1 : 1)`
- `L1_aeroResist(:, 1 : nLAI, 1 : nLCoverScene)`
- `L1_surfResist(:, 1 : nLAI, 1 : 1)`
- `L1_fRoots(:, 1 : nSoilHorizons_mHM, 1 : nLCoverScene)`
- `L1_maxInter(:, 1 : nLAI, 1 : 1)`
- `L1_kfastFlow(:, 1 : 1, 1 : nLCoverScene)`
- `L1_kSlowFlow(:, 1 : 1, 1 : nLCoverScene)`
- `L1_kBaseFlow(:, 1 : 1, 1 : nLCoverScene)`
- `L1_kPerco(:, 1 : 1, 1 : nLCoverScene)`
- `L1_soilMoistFC(:, 1 : nSoilHorizons_mHM, 1 : nLCoverScene)`
- `L1_soilMoistSat(:, 1 : nSoilHorizons_mHM, 1 : nLCoverScene)` (already present)
- `L1_jarvis_thresh_c1(:, 1 : 1, 1 : 1)`
- `L1_soilMoistExp(:, 1 : nSoilHorizons_mHM, 1 : nLCoverScene)`
- `L1_tempThresh(:, 1 : 1, 1 : nLCoverScene)`
- `L1_unsatThresh(:, 1 : 1, 1 : 1)`
- `L1_sealedThresh(:, 1 : 1, 1 : 1)`
- `L1_wiltingPoint(:, 1 : nSoilHorizons_mHM, 1 : nLCoverScene)`
- `L1_No_Count(:, 1:1, 1:1) ! N0 count`
- `L1_bulkDens(:, 1:nSoilHorizons_mHM, 1:nLCoverScene) ! bulk density`
- `L1_latticeWater(:, 1:nSoilHorizons_mHM, 1:nLCoverScene) ! lattice water`
- `L1_COSMICL3(:, 1:nSoilHorizons_mHM, 1:nLCoverScene) ! cosmic L3 parameter`
Also some calculated variables present in the ouput netcdf files are also missing:
- `L1_AET ! sum(aETSoil(horizons)) * fNotSealed + aETCanopy + aETSealed * fSealed`
- `L1_QD ! runoffSeal * fSealed`
- `L1_QIF ! fastRunoff * fNotSealed`
- `L1_QIS ! slowRunoff * fNotSealed`
- `L1_QB ! baseflow * fNotSealed`
- `L1_RECHARGE ! percol * fNotSealed`
- `L1_SOIL_INFIL_N ! infilSoil(horizon) * fNotSealed`
- `L1_AET_N ! aETSoil(horizon) * fNotSealed`Sebastian MüllerSebastian Müllerhttps://git.ufz.de/mhm/mhm/-/issues/252date information for dynamic fluxes and states in mHM restart file2024-01-17T11:23:03+01:00Friedrich Boeingdate information for dynamic fluxes and states in mHM restart fileFor operational system like the German Drought Monitor it would help if the mHM restart file contains information on the last date of the written fluxes and states e.g. as a global attribute.For operational system like the German Drought Monitor it would help if the mHM restart file contains information on the last date of the written fluxes and states e.g. as a global attribute.https://git.ufz.de/mhm/mhm/-/issues/255Checks: MPI problems with case 04, 05, 07 and 112024-02-27T14:13:36+01:00Sebastian MüllerChecks: MPI problems with case 04, 05, 07 and 11- case 05 and 07 don't work with MPI in general as the used objective functions are not parallelized
- case 04 and 11 are occasionally failing with the intel compilers (always when coming to the write-out routines)
Related:
- https://gi...- case 05 and 07 don't work with MPI in general as the used objective functions are not parallelized
- case 04 and 11 are occasionally failing with the intel compilers (always when coming to the write-out routines)
Related:
- https://git.ufz.de/mhm/mhm/-/issues/93
- https://git.ufz.de/mhm/mhm/-/issues/192
- https://git.ufz.de/mhm/mhm/-/merge_requests/28
- https://git.ufz.de/mhm/mhm/-/merge_requests/170wishlist