mHM issueshttps://git.ufz.de/mhm/mhm/-/issues2024-03-26T11:44:18+01:00https://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/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/170wishlisthttps://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/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/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/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/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/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/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/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/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/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/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/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/242How to silence warnings (e.g. 'tmax smaller than tmin' when using Hargreaves-...2023-08-23T16:28:01+02:00Peter MierschHow to silence warnings (e.g. 'tmax smaller than tmin' when using Hargreaves-Samani equation)When estimating evapotranspiration using the Hargreaves-Samani equation (processCase(5) = 1) using observational data (e.g. E-OBS gridded data), sometimes tmin is larger than tmax (especially for regions and time periods with poor weathe...When estimating evapotranspiration using the Hargreaves-Samani equation (processCase(5) = 1) using observational data (e.g. E-OBS gridded data), sometimes tmin is larger than tmax (especially for regions and time periods with poor weather station coverage, this issue is recognized by data curators). This leads to the warning `WARNING: tmax smaller than tmin at doy xxx in year xxxx at cell xxx!`. While this warning is helpful in most cases, for optimization runs in large catchments (~10000km2) with spotty data, this severely slows down mHM by writing to increasingly large log files (log files after an optimization run around 50 gigabytes in some cases). Leading to my question:
Is it possible to silence specific or all warnings in mHM through a 'verbosity setting' that I'm unable to find?wishlisthttps://git.ufz.de/mhm/mhm/-/issues/8check_files.py not working2023-05-23T22:30:43+02:00Stephan Thobercheck_files.py not workingcheck_files.py does not identify differences in file when there are differences. These differences are correctly found by cdo diffncheck_files.py does not identify differences in file when there are differences. These differences are correctly found by cdo diffnRobert SchweppeRobert Schweppehttps://git.ufz.de/mhm/mhm/-/issues/2mRM standalone write restart not working2023-05-23T22:30:43+02:00Stephan ThobermRM standalone write restart not workingswitching write_restart = .True. in mrm.nml leads to:
Log-file written to test_basin/ConfigFile.log
Writing mRM restart file to test_basin/restart/mRM_restart_001.nc ...
Failed to write data into variable: L1_basin_lat
NetCDF: ...switching write_restart = .True. in mrm.nml leads to:
Log-file written to test_basin/ConfigFile.log
Writing mRM restart file to test_basin/restart/mRM_restart_001.nc ...
Failed to write data into variable: L1_basin_lat
NetCDF: HDF error
STOP 1mHM releaseStephan ThoberStephan Thoberhttps://git.ufz.de/mhm/mhm/-/issues/1Develop branch does not compile with NAG2023-05-23T22:30:43+02:00Robert SchweppeDevelop branch does not compile with NAGHaving set the newest NAG 6.2 compiler on EVE, we can now test mHM again. When doing: `make compiler=nag system=eve release=debug -j 4`
we get the following:
```
Questionable: /gpfs0/home/ottor/lib/mhm/src/mRM/mo_mrm_river_head.f90,
l...Having set the newest NAG 6.2 compiler on EVE, we can now test mHM again. When doing: `make compiler=nag system=eve release=debug -j 4`
we get the following:
```
Questionable: /gpfs0/home/ottor/lib/mhm/src/mRM/mo_mrm_river_head.f90,
line 162: Variable NCOLS0 set but never referenced
Questionable: /gpfs0/home/ottor/lib/mhm/src/mRM/mo_mrm_river_head.f90,
line 162: Variable NROWS0 set but never referenced
Error: /gpfs0/home/ottor/lib/mhm/src/mRM/mo_mrm_river_head.f90, line 31
7: Implicit type for ISNAN in CALC_SLOPE
[NAG Fortran Compiler pass 1 error termination, 1 error, 2 warnings]
```
I assign @schueler as he is creator of the fileLennart SchülerLennart Schülerhttps://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üller