mHM issueshttps://git.ufz.de/mhm/mhm/-/issues2020-08-31T16:24:12+02:00https://git.ufz.de/mhm/mhm/-/issues/81The runtime display of selected mHM fluxes for output is erroneous2020-08-31T16:24:12+02:00Pallav Kumar Shresthapallav-kumar.shrestha@ufz.deThe runtime display of selected mHM fluxes for output is erroneousThe runtime display of the user selected mHM fluxes for output has a bug.
* It seems there is a count error for mHM fluxes displayed at runtime
* However, the variables saved in the output file corresponds to the user selected options.The runtime display of the user selected mHM fluxes for output has a bug.
* It seems there is a count error for mHM fluxes displayed at runtime
* However, the variables saved in the output file corresponds to the user selected options.5.11Sebastian MüllerSebastian Müllerhttps://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/14NAG compiler, version 6.2, build 6214 does not work on EVE2020-12-01T09:13:32+01:00Robert SchweppeNAG compiler, version 6.2, build 6214 does not work on EVEWith the current develop branch, we get a Segmentation Fault when running on Eve (frontend1):
`make compiler=nag system=eve release=debug && ./mhm`
The code occurs at each time a call to write is encountered, namely in `src/mo_nml.f90`...With the current develop branch, we get a Segmentation Fault when running on Eve (frontend1):
`make compiler=nag system=eve release=debug && ./mhm`
The code occurs at each time a call to write is encountered, namely in `src/mo_nml.f90`, line 308 (this is where the error is thrown):
` write(test, '(A,A)') '&', tolower(name)`
but if we make a workaround to that call, the program raises another SegmentationFault at `src/mo_netcdf.f90`, line 1613:
` write(msg, *) id`
I successfully run and compile the code at my local system with NAG 6.2 (6214). It also applies to other Fortran projects, e.g. MPR. Locally I have gcc version 8.1, netcdf-fortran 4.4.4 compiled with NAG 6.2.
I think it has, something to do with the way the compiler is set up on Eve. Any ideas @rakovec, @krausec, @lberg?5.11Sebastian MüllerSebastian Müllerhttps://git.ufz.de/mhm/mhm/-/issues/12dicussion needed on calculation of aerodynamic resistance2020-02-14T08:35:15+01:00Robert Schweppedicussion needed on calculation of aerodynamic resistanceIf PET is calculated using Penman-Monteith, aerodynamic resistance needs to be calculated. This is happening in subroutine `aerodynamic_resistance` in `mo_multi_param_reg.f90`. It was implemented by Matthias Zink and cites a FAO publicat...If PET is calculated using Penman-Monteith, aerodynamic resistance needs to be calculated. This is happening in subroutine `aerodynamic_resistance` in `mo_multi_param_reg.f90`. It was implemented by Matthias Zink and cites a FAO publication as a source. Now here is the problem:
The FAO paper uses a calculation based on a paper of Jacobs(2002) that seems to be valid for the grass reference surface. What I found in a brief search in the internet is that it is most commonly used for canopy_heights for crops of up to 2m. However, we also use that function for forest canopies. The canopy height for forests in mHM is controlled by a parameter (`param(1)`) and can range from 15 (default) to 40m. The measurement height of wind measurement (`zm`) is a parameter and set to 10m.
To make that function work, the `canopy_height0` is added to `zm` , if the `canopy_height0` is higher than `zm`. I do not know, if that is really the way the function is supposed to be used.
Here is the relevant code:
```
! regionalization of canopy height
! substitute with canopy height
canopy_height0 = merge(param(1), canopy_height0, LCover0 == 1) ! forest
canopy_height0 = merge(param(2), canopy_height0, LCover0 == 2) ! impervious
! old implementation used values from LUT statically for all cells (Jan-Dec, 12 values):
! 7 Intensive-orchards: 2.0, 2.0, 2.0, 2.0, 3.0, 3.5, 4.0, 4.0, 4.0, 2.5, 2.0, 2.0
maxLAI = MAXVAL(LAI0, dim=2)
do tt = 1, size(LAI0, 2)
! pervious canopy height is scaled with LAI
canopy_height0 = merge((param(3) * LAI0(:, tt) / maxLAI), canopy_height0, LCover0 == 3) ! pervious
! estimation of the aerodynamic resistance on the lower level
! see FAO Irrigation and Drainage Paper No. 56 (p. 19 ff) for more information
zm = WindMeasHeight
! correction: if wind measurement height is below canopy height loagarithm becomes negative
->!! zm = merge(canopy_height0 + zm, zm, ((abs(zm - nodata_dp) .GT. eps_dp) .AND. (zm .LT. canopy_height0)))
! zh = zm
displace = param(4) * canopy_height0
zm_zero = param(5) * canopy_height0
zh_zero = param(6) * zm_zero
!
! calculate aerodynamic resistance (changes monthly)
aerodyn_resistance0(:, tt) = log((zm - displace) / zm_zero) * log((zm - displace) / zh_zero) / (karman**2.0_dp)
aerodyn_resistance1(:, tt) = upscale_arithmetic_mean(n_subcells1, upper_bound1, lower_bound1, &
left_bound1, right_bound1, Id0, mask0, nodata_dp, aerodyn_resistance0(:, tt))
end do
```
So my questions are (before I adapt this to the new MPR) @lese, @rakovec, @rkumar, @thober:
* are we okay with using this function for calculation of aerodynamic resistance for forests?
* if yes, is the correction, like Matthias did it, okay, or do we come up with a smoother solution, because now: canopy_height: 9.99 m -> zm = 10.0 m, canopy_height: 10.0 m -> zm = 20.0 m
* if no, what other transfer function do we want?https://git.ufz.de/mhm/mhm/-/issues/11Potential bug in mo_multi_param_reg.f902020-02-14T08:35:15+01:00Robert SchweppePotential bug in mo_multi_param_reg.f90When the fractions of the different land cover types are calculated in `mo_multi_param_reg.f90`:
```
fSealed1(:, 1, iiLC) = fracSealed_CityArea * fSealed1(:, 1, iiLC)
fPerm1(:) = fPerm1(:) + (1.0_dp - fracSealed_CityArea) * ...When the fractions of the different land cover types are calculated in `mo_multi_param_reg.f90`:
```
fSealed1(:, 1, iiLC) = fracSealed_CityArea * fSealed1(:, 1, iiLC)
fPerm1(:) = fPerm1(:) + (1.0_dp - fracSealed_CityArea) * fSealed1(:, 1, iiLC)
! to make sure everything happens smoothly
fForest1(:) = fForest1(:) / (fForest1(:) + fSealed1(:, 1, iiLC) + fPerm1(:))
fSealed1(:, 1, iiLC) = fSealed1(:, 1, iiLC) / (fForest1(:) + fSealed1(:, 1, iiLC) + fPerm1(:))
fPerm1(:) = fPerm1(:) / (fForest1(:) + fSealed1(:, 1, iiLC) + fPerm1(:))
```
the 2nd line contains IMHO a bug. fPerm1 must be based on the original fSealed, not the corrected one. One possible alternative could be, for example:
```
fSealed1(:, 1, iiLC) = fracSealed_CityArea * fSealed1(:, 1, iiLC)
fPerm1(:) = 1.0_dp - fSealed1(:, 1, iiLC) - fForest1(:)
```
There are multiple ways to implement that, but this one is the neatest, I think and makes the last checks obsolete. fForest1(:) + fSealed1(:, 1, iiLC) + fPerm1(:) should always sum to 1, as they come directly from the L0 land cover fields. @rakovec Please give some feedback and decide, what is to be done. It influences all the snow parameters and fSealed is also used in many parts of the program. The code has also been there in version 5.8.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/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/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/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/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/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/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/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/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/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/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/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/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/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üller