mHM issueshttps://git.ufz.de/mhm/mhm/-/issues2022-06-17T16:53:28+02:00https://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/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/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/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/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/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/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 Thoberhttps://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 Kaluza