mHM issueshttps://git.ufz.de/mhm/mhm/-/issues2024-02-26T09:46:09+01:00https://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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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 Thober