mHM issueshttps://git.ufz.de/mhm/mhm/-/issues2024-02-27T14:13:36+01:00https://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/195Potential bug in mo_common_datetime_type with yID2021-07-09T11:59:10+02:00Robert SchweppePotential bug in mo_common_datetime_type with yIDIn https://git.ufz.de/mhm/mhm/-/blob/develop/src/common/mo_common_datetime_type.f90 there is the property `yID` storing the ID of the land cover period associated for each year. This is set only at `init` but then not touched anymore. Wh...In https://git.ufz.de/mhm/mhm/-/blob/develop/src/common/mo_common_datetime_type.f90 there is the property `yID` storing the ID of the land cover period associated for each year. This is set only at `init` but then not touched anymore. Why is not changed in `increment`, when the year is advanced? `increment` is called in `mhm_eval` and `%yId` is used to select the correct parameter slice. Obviously, checks do not fail, but I stumbled upon it and it does not make sense to me.wishlist futureSebastian MüllerSebastian Müllerhttps://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/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üllerhttps://git.ufz.de/mhm/mhm/-/issues/168L2 L1 resolution compatibility issues in mo_spatial_agg_disaggregation while ...2021-02-03T16:00:27+01:00Pallav Kumar Shresthapallav-kumar.shrestha@ufz.deL2 L1 resolution compatibility issues in mo_spatial_agg_disaggregation while producing L1 meteorology**Issue**
When L2 > L1, mHM downscales the L2 meteorology to generate L1 meteorology. When L2 < L1, mHM upscales the L2 meteorology to generate L1 meteorology. This calculation takes place in mo_spatial_agg_disaggregation.
Refer to fig...**Issue**
When L2 > L1, mHM downscales the L2 meteorology to generate L1 meteorology. When L2 < L1, mHM upscales the L2 meteorology to generate L1 meteorology. This calculation takes place in mo_spatial_agg_disaggregation.
Refer to figure below. The extent of model input (blue border) varies based on the catchment (grey shadow). In the current form, the mo_spatial_agg_disaggregation upscaling and downscaling routines is based on ceiling function and has following effect -
- (left) Extent of L1 exactly covers L2 extent/ data extent **+** L2 is a multiple of L1 : correct L1 meteorology
- (centre) Extent of L1 exactly covers L2 extent/ data extent **but** L2 is NOT a multiple of L1 : errors induced in L1 meteorology as L1 cell gets value of one L2 cell, but still works
- (right) Extent of L1 is not equal to L2 extent/ data extent **and** L2 is NOT a multiple of L1 : mHM fails in debug mode at mo_spatial_agg_disaggregation
![Screenshot_2021-01-05_at_12.13.15](/uploads/3d5530aa6029f2ca88d74ea1d9879006/Screenshot_2021-01-05_at_12.13.15.png)
**Proposal**
The `ceiling based` downscaling in mo_spatial_agg_disaggregation is incompatible to the latter two scenarios mentioned above. A better alternative would be `area based calculation` where L0 area (grey shadow) and L2 area/s are used to downscale L2 to L1. This would, in principle, improve scalability compromises previously induced in mHM from L1 meteorology. This corresponds to the `approach of SCC` in mLM as well.
We should bear in mind that, if accepted, this approach would change the reference for mHM test cases.
**Issues in mLM development**
Below is a screenshot showing a test case of mLM exhibiting the above issue of incorrect L1 meteorology. The extent was as in the third case, and nodata count is > 0 whenever L2 is not a multiple of L1, during downscaling. However, this is not the case with upscaling although the domain average tmax and tmin calculated from L1 values deviate a bit from what it should be (L1 = 0.05, 0.25). For mLM, a dirty patch has been applied with [this commit](https://git.ufz.de/shresthp/mhm/-/commit/47fa930d6c4010bbfc3feea9b18610e60e259cac) in mLM fork and resolved issue mhm/mhm#167. However, mLM awaits a better solution from develop at mo_spatial_agg_disaggregation.
![Screenshot_2021-01-05_at_11.45.03](/uploads/cbd079c192f5daf5474999559724a4b9/Screenshot_2021-01-05_at_11.45.03.png)6.xSebastian 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/135BUGFIX: river network not accepting multiple outlets if L0 == L112020-10-05T17:05:13+02:00Stephan ThoberBUGFIX: river network not accepting multiple outlets if L0 == L11
https://git.ufz.de/ulysses/mrm/-/commit/009799e9be526142aef349c211d06df526720e96
https://git.ufz.de/ulysses/mrm/-/commit/009799e9be526142aef349c211d06df526720e96Integrate UlyssesStephan ThoberStephan Thoberhttps://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/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/25Consistency check for soil LUT (iFlag_soilDB = 1) fails for large soil datase...2021-07-29T14:22:26+02:00Oldrich RakovecConsistency check for soil LUT (iFlag_soilDB = 1) fails for large soil datasets with IntelDear all,
While running Southern America sub-continent (L0 has ncols=30720, nrows=24064) with `iFlag_soilDB = 1` using `nSoilHorizons_mHM = 6`, mHM breaks in `/src/MPR/mo_read_wrapper.f90` on following line:
`call check_consistency_lu...Dear all,
While running Southern America sub-continent (L0 has ncols=30720, nrows=24064) with `iFlag_soilDB = 1` using `nSoilHorizons_mHM = 6`, mHM breaks in `/src/MPR/mo_read_wrapper.f90` on following line:
`call check_consistency_lut_map(reshape(L0_soilId, (/ size(L0_soilId, 1) * size(L0_soilId, 2) /)), soilDB%id(:), fName)`
mHM is able to execute this command only up to `nSoilHorizons_mHM = 3`, when increasing to `nSoilHorizons_mHM = 4` and more, code returns following error:
`forrtl: severe (408): fort: (2): Subscript #1 of the array IRNGT has value 2109892711 which is greater than the upper bound of 2109892710`
Note that I encountered this weak point already half year ago for the Australian domain, but I could have solved this in the Makefile by `INTEL_EXCLUDE := mo_multi_param_reg.f90 mo_mpr_soilmoist.f90 mo_read_wrapper.f90`, which has no effect now. I also tried reducing the optimization level from `O3` to `O1` in `./make.config/eve.intel18`, did not help either, as follows:
`F90FLAGS += -O1 -qoverride-limits -gxx-name=/usr/local/gcc/6.2.0-1/bin/g++
FCFLAGS += -O1 -qoverride-limits -gxx-name=/usr/local/gcc/6.2.0-1/bin/g++
CFLAGS += -O1`
Actually, I have tried with both Intel compilers on EVE (13 and 18). Both have the same behaviour.
@kaluza, @thober @rkumar @lese @schaefed @ottor, Any ideas? Thanks!6.xMaren KaluzaMaren Kaluza