mHM issueshttps://git.ufz.de/mhm/mhm/-/issues2023-08-23T16:28:01+02:00https://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/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/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/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.dehttps://git.ufz.de/mhm/mhm/-/issues/230MPI related bugs (failing check cases)2022-08-30T14:43:30+02:00Sebastian MüllerMPI related bugs (failing check cases)There seem to be some issues with MPI. We already disabled some check cases for MPI in `run_mhm_checks.py`:
```python
# case 5 and 7 don't work with MPI. case 4 has a bug working with ifort+debug
SKIP_CASES_MPI = ["case_04", "case_05", "...There seem to be some issues with MPI. We already disabled some check cases for MPI in `run_mhm_checks.py`:
```python
# case 5 and 7 don't work with MPI. case 4 has a bug working with ifort+debug
SKIP_CASES_MPI = ["case_04", "case_05", "case_07"]
```
And it seems we also need to add `"case_11"` there, since it fails occasionally for different reasons:
- https://git.ufz.de/muellese/mhm/-/jobs/355821
```bash
##################################################
# SUMMARY: case_11
##################################################
2 of 103 records differ
0 of 103 records differ more than 0.0001
Missing: b6_discharge.nc, b6_daily_discharge.out
```
- https://git.ufz.de/muellese/mhm/-/jobs/355446
```bash
b6_daily_discharge.out
6 of 6 records differ
6 of 6 records differ more than 0.0001
Differing: No, Day, Mon, Year, Qobs_0000000398, Qsim_0000000398
Shape missmatch: No (in: (59,), ref: (1461,)), Day (in: (59,), ref: (1461,)), Mon (in: (59,), ref: (1461,)), Year (in: (59,), ref: (1461,)), Qobs_0000000398 (in: (59,), ref: (1461,)), Qsim_0000000398 (in: (59,), ref: (1461,))
```
Maybe this is related to #220
For now I will disable case 11, but we need to keep track of it.v5.12Sebastian MüllerSebastian Müllerhttps://git.ufz.de/mhm/mhm/-/issues/232DOC: tables have variing widths2022-08-30T14:22:17+02:00Sebastian MüllerDOC: tables have variing widthsIn the latest docs, all tables have different widths and are not centered. This was better before.![Bildschirmfoto_von_2022-07-07_12-23-03](/uploads/dc7ca7175d978cfe92baa9192da951b0/Bildschirmfoto_von_2022-07-07_12-23-03.png)In the latest docs, all tables have different widths and are not centered. This was better before.![Bildschirmfoto_von_2022-07-07_12-23-03](/uploads/dc7ca7175d978cfe92baa9192da951b0/Bildschirmfoto_von_2022-07-07_12-23-03.png)https://git.ufz.de/mhm/mhm/-/issues/133Improve error message when soil or geology input data is not masked properly2022-07-07T10:55:23+02:00Marco HannemannImprove error message when soil or geology input data is not masked properlyWhen soil_class.asc or geology_class.asc are not masked properly and contain NoData-Values where other morphological input data sets are defined, following error will be thrown:
```
***ERROR: Class -9999 is missing
in input fi...When soil_class.asc or geology_class.asc are not masked properly and contain NoData-Values where other morphological input data sets are defined, following error will be thrown:
```
***ERROR: Class -9999 is missing
in input file soil_classdefinition.txt ...
```
Since -9999 is a NoData value here and not a valid class ID, the user should get the advice to check his masking routine.v5.12Sebastian MüllerSebastian Müllerhttps://git.ufz.de/mhm/mhm/-/issues/132Improve error message when nSoil_Types higher than actual classes2022-07-07T10:55:11+02:00Marco HannemannImprove error message when nSoil_Types higher than actual classesWhen nSoil_Types in the header of soil_classdefinition.txt is lower than the actual classes defined, an error will be raised
that class n is missing.
If it is higher than the actual classes defined, mHM will return a Segmentation fault...When nSoil_Types in the header of soil_classdefinition.txt is lower than the actual classes defined, an error will be raised
that class n is missing.
If it is higher than the actual classes defined, mHM will return a Segmentation fault (SIGSEGV):
```
Program received signal SIGSEGV: Segmentation fault - invalid memory reference.
Backtrace for this error:
#0 0x2B7084854347
#1 0x2B708485494E
#2 0x2B70863863FF
#3 0x54FFB4 in __mo_soil_database_MOD_generate_soil_database
#4 0x55A82C in __mo_mpr_startup_MOD_mpr_initialize
#5 0x5C87D4 in __mo_startup_MOD_mhm_initialize
#6 0x59119F in MAIN__ at mhm_driver.f90:?
Segmentation fault
```
This makes it hard to identify the root cause of the error for the userv5.12Sebastian MüllerSebastian Müllerhttps://git.ufz.de/mhm/mhm/-/issues/159[netcdf] use of `_FillValue`2022-07-07T10:38:58+02:00Sebastian Müller[netcdf] use of `_FillValue`To be in line with the [CF conventions](https://cfconventions.org/Data/cf-conventions/cf-conventions-1.8/cf-conventions.html), we should talk about the usage of the `_FillValue` attribute beside `missing_value` in the netcdf output.
@ot...To be in line with the [CF conventions](https://cfconventions.org/Data/cf-conventions/cf-conventions-1.8/cf-conventions.html), we should talk about the usage of the `_FillValue` attribute beside `missing_value` in the netcdf output.
@ottor, @rakovec, @thober opinions?v5.12Sebastian MüllerSebastian Müller