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