mHM issueshttps://git.ufz.de/mhm/mhm/-/issues2023-05-12T15:07:38+02:00https://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/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/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/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/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/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/246mRM: l1_l11_remap never used2023-04-26T14:21:34+02:00Sebastian MüllermRM: l1_l11_remap never usedl1_l11_remap is created in `mo_mrm_init::mrm_init` by:
```fortran
call init_lowres_level(level1(iDomain), resolutionRouting(iDomain), &
level11(iDomain), l1_l11_remap(iDomain))
```
But it is never used. This would...l1_l11_remap is created in `mo_mrm_init::mrm_init` by:
```fortran
call init_lowres_level(level1(iDomain), resolutionRouting(iDomain), &
level11(iDomain), l1_l11_remap(iDomain))
```
But it is never used. This would also not work if level11 is finer than level1 (which is totally fine for mHM).
So this should be removed.
Spatial (dis-)aggregation is done by `L11_L1_mapping` which creates `L1Id_on_L11` or `L11Id_on_L1` to map L1 to L11.Sebastian 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/244pybind: kind map for f2py2023-04-05T00:07:07+02:00Sebastian Müllerpybind: kind map for f2pyAt the moment we don't specify kinds to generate the python wrapper for mHM.
F2PY is able to deal with this by mapping kind specifiers to their python/C equivalent:
https://numpy.org/doc/stable/f2py/advanced.html#dealing-with-kind-speci...At the moment we don't specify kinds to generate the python wrapper for mHM.
F2PY is able to deal with this by mapping kind specifiers to their python/C equivalent:
https://numpy.org/doc/stable/f2py/advanced.html#dealing-with-kind-specifiers
Since we have `mo_kind` with the iso_c_bindings, we should add a map for our used kinds in a file `.f2py_f2cmap`:
```python
dict(
integer=dict(i1='signed_char', i2='short', i4='int', i8='long_long'),
real=dict(sp='float', dp='double', qp='long_double'),
complex=dict(spc='complex_float', dpc='complex_double', qpc='complex_long_double'),
)
```https://git.ufz.de/mhm/mhm/-/issues/245BUG: single precision output currently broken2023-04-04T19:32:47+02:00Sebastian MüllerBUG: single precision output currently brokenThe following settings in the output namelists cause mHM to crach:
- `mrm_outputs.nml`:
```fortran
output_double_precision_mrm = .false.
```
- `mhm_outputs.nml`:
```fortran
output_double_precision = .false.
```
This bug was i...The following settings in the output namelists cause mHM to crach:
- `mrm_outputs.nml`:
```fortran
output_double_precision_mrm = .false.
```
- `mhm_outputs.nml`:
```fortran
output_double_precision = .false.
```
This bug was introduced and/or intensified with !139Sebastian MüllerSebastian Müllerhttps://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/241Index "i" in L11_routing used for more than one assignment within a loop2023-02-10T13:03:25+01:00Pallav Kumar Shresthapallav-kumar.shrestha@ufz.deIndex "i" in L11_routing used for more than one assignment within a loopIndex `i` in `L11_routing` used for more than one assignment within a loop [Line 437](https://git.ufz.de/mhm/mhm/-/blob/develop/src/mRM/mo_mrm_routing.f90#L437) and [Line 451](https://git.ufz.de/mhm/mhm/-/blob/develop/src/mRM/mo_mrm_rout...Index `i` in `L11_routing` used for more than one assignment within a loop [Line 437](https://git.ufz.de/mhm/mhm/-/blob/develop/src/mRM/mo_mrm_routing.f90#L437) and [Line 451](https://git.ufz.de/mhm/mhm/-/blob/develop/src/mRM/mo_mrm_routing.f90#L451).
Currently there is not harm done. However, if there are inflow gauges and the first intended assignment of index i is used after the inflow gauge check block, `it leads to disaster` as I learned the hard way in my lake module fork.
I recommend to use a different index in the the inflow gauge check (e.g. `gg_inflow`).
Tagging the main authors here: @lese @rkumarv5.13.0Sebastian MüllerSebastian Müllerhttps://git.ufz.de/mhm/mhm/-/issues/238ExitCode still 0 after unsuccessful run2023-01-30T18:14:18+01:00Peter MierschExitCode still 0 after unsuccessful runAfter an unsuccessful run of mHM with errors like
```
Reading LAI ...
***ERROR: read_nc: mHM generated x and y are not matching NetCDF dimensions
```
or
```
read precipitation ...
***ERROR: length of time dimension nee...After an unsuccessful run of mHM with errors like
```
Reading LAI ...
***ERROR: read_nc: mHM generated x and y are not matching NetCDF dimensions
```
or
```
read precipitation ...
***ERROR: length of time dimension needs to be at least 2 in file
```
it still exits with exitcode 0, suggesting that the run was successful. This makes monitoring and accounting of mHM runs more difficult, as the queuing system reports a successful run. This is especially a problem when running multiple instances of mHM parallelly. In contrast, when an input files is missing, mHM exits with exitcode 1, indicating that the run failed.
From my point of view, the ideal behavior would be that mHM exits with exitcode 1 if any error makes the run unsuccessful.v5.13.0Sebastian MüllerSebastian Müllerhttps://git.ufz.de/mhm/mhm/-/issues/83date mHM output2023-01-30T17:32:12+01:00Friedrich Boeingdate mHM outputIn mHM 5.10 the mHM_Fluxes_States Output starts one day later than meteo input data.
meteo input:
-->starts at 1st Jan.
`
time:units = "days since 1951-01-01-00:00:00" ;
time = 0, 1, 2, 3, 4, 5, 6, 7,...`
mHM-Output:
-->output starts ...In mHM 5.10 the mHM_Fluxes_States Output starts one day later than meteo input data.
meteo input:
-->starts at 1st Jan.
`
time:units = "days since 1951-01-01-00:00:00" ;
time = 0, 1, 2, 3, 4, 5, 6, 7,...`
mHM-Output:
-->output starts at 2nd Jan.
`time:units = hours since 1951-01-01 00:00:00
time = 47, 71, 95, 119, 143, 167,...`
in older mHM version (5.5) from current drought monitor **same meteo input** generates output starting at same day as input data.
mHM-Output:
-->output starts at 2nd Jan.
`time:units = hours since 1951-01-01 00:00:00
time = 23, 47, 71, 95, 119, 143, 167,...`
```fortran
warming_Days(1) = 0
eval_Per(1)%yStart = 1951
eval_Per(1)%mStart = 01
eval_Per(1)%dStart = 01
eval_Per(1)%yEnd = 1951
eval_Per(1)%mEnd = 12
eval_Per(1)%dEnd = 31
```
I need help to clarify this issue.v5.13.0Sebastian MüllerSebastian Müllerhttps://git.ufz.de/mhm/mhm/-/issues/239Simple namelist files for each test domain2023-01-30T17:24:17+01:00Sebastian MüllerSimple namelist files for each test domainWe should add simple namelist files in each test domain folder to be able to run these with:
```bash
mhm ./test_domain
mhm ./test_domain_2
```We should add simple namelist files in each test domain folder to be able to run these with:
```bash
mhm ./test_domain
mhm ./test_domain_2
```v5.13.0Sebastian MüllerSebastian Müllerhttps://git.ufz.de/mhm/mhm/-/issues/200check_dir behaves differently with Intel (18) and GNU (83)2023-01-30T16:06:04+01:00Pallav Kumar Shresthapallav-kumar.shrestha@ufz.decheck_dir behaves differently with Intel (18) and GNU (83)The `check_dir` subroutine behaves differently with intel and gnu for long directory paths. Gnu works fine with long directories while executable compiled with Intel, for some reason, introduces a line break during the check. As a result...The `check_dir` subroutine behaves differently with intel and gnu for long directory paths. Gnu works fine with long directories while executable compiled with Intel, for some reason, introduces a line break during the check. As a result, Intel compiled executable always has False value for check_dir for long directory paths. Screenshots below -
**with GCC83**
![Screenshot_2021-08-05_at_22.09.54](/uploads/9ed3f187dfbd2d622c747beed52e0993/Screenshot_2021-08-05_at_22.09.54.png)
**with Intel18**
![Screenshot_2021-08-05_at_22.12.57](/uploads/c8c7cbb20acc60075aedcee486ff0947/Screenshot_2021-08-05_at_22.12.57.png)
Similar issue with line breaks was encountered in #40 which could already provide some clues to debug this.v5.13.0Sebastian MüllerSebastian Müllerhttps://git.ufz.de/mhm/mhm/-/issues/107hourly meteo forcing nc2023-01-12T11:13:47+01:00Stephan Thoberhourly meteo forcing ncThis is an email send by Olda:
Hi Stephan,
Just a follow-up on Husain's comment during mhm develop meeting.
During today’s mHM meeting I have checked further the reading of hourly data is not working in mHM.
I remember checking this...This is an email send by Olda:
Hi Stephan,
Just a follow-up on Husain's comment during mhm develop meeting.
During today’s mHM meeting I have checked further the reading of hourly data is not working in mHM.
I remember checking this already long time ago…
FYI, I have attached 3-meteo files with modified time step for the test basin at hourly time,
This can be used in the test example with modified time window:
```fortran
warming_Days(1) = 0
!> first year of wanted simulation period
eval_Per(1)%yStart = 1989
!> first month of wanted simulation period
eval_Per(1)%mStart = 01
!> first day of wanted simulation period
eval_Per(1)%dStart = 02
!> last year of wanted simulation period
eval_Per(1)%yEnd = 1989
!> last month of wanted simulation period
eval_Per(1)%mEnd = 02
!> last day of wanted simulation period
eval_Per(1)%dEnd = 02
```
The first thing is that `./src/common/mo_read_forcing_nc.f90` fails to recognize, these data are at hourly time step.
If `inctimestep` is hardcoded in there to `-4`, then seq fault occurs later in the code.
I did not go deeper, but just want to confirm, there is an issue to be checked.
Thanks!
Best regards,
Olda
[pet.nc](/uploads/042c56ffde633de2f2efb26a126d6c2a/pet.nc)
[tavg.nc](/uploads/005f8ee487b8fa381e8def6fcf7432b2/tavg.nc)
[header.txt](/uploads/4ae6bdb6d30e8de7a3a1cf0fa499dbf2/header.txt)
[pre.nc](/uploads/71f9ed2044168a54a6a9c1bb5bddf115/pre.nc)v5.12Sebastian MüllerSebastian Müllerhttps://git.ufz.de/mhm/mhm/-/issues/227"Precipitation" not mentioned for the weights option in mhm.nml2022-10-03T19:10:33+02:00Pallav Kumar Shresthapallav-kumar.shrestha@ufz.de"Precipitation" not mentioned for the weights option in mhm.nmlThe hourly disaggregation in mhm can be carried out based on weights for `pre`, `tavg` and `pet` as seen the the list of arguments of mhm call [here](https://git.ufz.de/mhm/mhm/-/blob/develop/src/mHM/mo_mhm_interface_run.f90#L447). But `...The hourly disaggregation in mhm can be carried out based on weights for `pre`, `tavg` and `pet` as seen the the list of arguments of mhm call [here](https://git.ufz.de/mhm/mhm/-/blob/develop/src/mHM/mo_mhm_interface_run.f90#L447). But `pre` is not mentioned in the comments section of mhm.nml [here](https://git.ufz.de/mhm/mhm/-/blob/develop/mhm.nml#L789)v5.12Sebastian MüllerSebastian Müllerhttps://git.ufz.de/mhm/mhm/-/issues/220mHM discharge.nc writing sometimes broken2022-09-07T13:45:57+02:00Stephan ThobermHM discharge.nc writing sometimes brokenUsers have reported that discharge.nc is not written correctly, see
https://github.com/mhm-ufz/mhm/discussions/49
discharge.nc uses var2nc subroutine and not latest netcdf library. This should be changed as other nc files are written co...Users have reported that discharge.nc is not written correctly, see
https://github.com/mhm-ufz/mhm/discussions/49
discharge.nc uses var2nc subroutine and not latest netcdf library. This should be changed as other nc files are written correctly in the occuring cases.v5.12Pallav Kumar Shresthapallav-kumar.shrestha@ufz.dePallav Kumar Shresthapallav-kumar.shrestha@ufz.de