mHM issueshttps://git.ufz.de/mhm/mhm/-/issues2022-04-28T16:07:04+02:00https://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/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/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/136miss fractions of landusetype forest and perm at L1 in mHM_restart.nc2022-06-17T16:53:28+02:00Friedrich Boeingmiss fractions of landusetype forest and perm at L1 in mHM_restart.ncHello, I miss the fractions of the landusetypes forest and permeable for the gridcells at L1 in the mHM output. In prior versions this was written out as L1_fPerm and L1_fForest. It would be interesting for the interpretations of model/f...Hello, I miss the fractions of the landusetypes forest and permeable for the gridcells at L1 in the mHM output. In prior versions this was written out as L1_fPerm and L1_fForest. It would be interesting for the interpretations of model/field comparisons for single gridcells. I would be also interested if the average mineral bulk density and soil texture fractions for each grid cell at L1 could be written out.wishlistSebastian 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/148[IDEA] continuous rivers along lon bound2020-09-23T18:51:01+02:00Stephan Thober[IDEA] continuous rivers along lon boundThis commit in Ulysses allows rivers crossing the x bounds in the domain:
https://git.ufz.de/ulysses/mrm/-/commit/618ff9eeb24e801b6e47bca4fd2ab1e69dead984
it should be discussed whether this should be included in the main repo.This commit in Ulysses allows rivers crossing the x bounds in the domain:
https://git.ufz.de/ulysses/mrm/-/commit/618ff9eeb24e801b6e47bca4fd2ab1e69dead984
it should be discussed whether this should be included in the main repo.Integrate UlyssesSebastian 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/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/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/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/169Spatial orientation of layers in mRM restart file2024-02-26T09:46:31+01:00sluedtkeSpatial orientation of layers in mRM restart fileExtracting the 2d var "L11_fAcc" from "./restart/mRM_restart_001.nc" and plotting it shows the layer mirrored on both axis. See the picture below, one done with R using the raster package, the other from ncview (not nice, but you get an ...Extracting the 2d var "L11_fAcc" from "./restart/mRM_restart_001.nc" and plotting it shows the layer mirrored on both axis. See the picture below, one done with R using the raster package, the other from ncview (not nice, but you get an idea).
This is not the case for "output/mHM_Fluxes_States.nc". I think it would be great if that is consistent over all files
![2021-01-08-104643_grim](/uploads/58c93fe3fb4a4d00eca8eaa34a0e2adc/2021-01-08-104643_grim.png)
![2021-01-08-104633_grim](/uploads/0f23c94189e603cb42c3d0603e54161d/2021-01-08-104633_grim.png).wishlistStephan ThoberStephan Thoberhttps://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/172Specifiaciton of input file names via mhm.nml2021-02-16T09:26:30+01:00sluedtkeSpecifiaciton of input file names via mhm.nmlI think this is a feature request :-).
we are in the happy situation to have our entire mhm setup in a git repo. For our application, we have to have two different files for flow accumulation that are used as input, depending on the cu...I think this is a feature request :-).
we are in the happy situation to have our entire mhm setup in a git repo. For our application, we have to have two different files for flow accumulation that are used as input, depending on the current question we want to address.
I am currently thinking that the best way would be to have always both files present in the morph folder (eg. facc_a.asc, facc_b.asc) and tell mhm via the "mhm.nml" file which one to use. Doing so, the only thing we have to commit are the changes in the mhm.nml file but that would require that were are able to specify the flow accumulation file of interest in the name list.
The second approach would be to checkout the file of interest depending on the current task, but that would mean that we are changing a rather big file over and over again, what is not very nice.
Any help on that is appreciated.6.xSebastian 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/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/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/207Landcover dependent model parameters2021-11-17T14:49:45+01:00Rohini KumarLandcover dependent model parametersAt the moment with v.5.11.2 we have landcover dependent parameters assigned for all landcover scenes at the start (unlike the older versions where parameters were updated once LC scene was changed). In my opinion this will have implicati...At the moment with v.5.11.2 we have landcover dependent parameters assigned for all landcover scenes at the start (unlike the older versions where parameters were updated once LC scene was changed). In my opinion this will have implications if we have multiple LC scenes and corresponding parameters are allocated at the start especially running over a big spatial domain - from memory point of view... Any thoughts on this? I will make some runs to see the computational demand of with this and older options.. When/why does this change happen; and what are the implications? Thoughts are welcome.6.xhttps://git.ufz.de/mhm/mhm/-/issues/208Improve error message for DDS2021-11-12T13:14:38+01:00Pallav Kumar Shresthapallav-kumar.shrestha@ufz.deImprove error message for DDS**Issue**
We need to improve error message for DDS when the observations are missing for optimization. ATM we get a `developer level message` which is completely out of context for mhm users who don't know much about the source code. In...**Issue**
We need to improve error message for DDS when the observations are missing for optimization. ATM we get a `developer level message` which is completely out of context for mhm users who don't know much about the source code. In general, the mhm error messages should transition from `developer level` to `user level`.
**Location**
[Occurrence 1](https://git.ufz.de/mhm/mhm/-/blob/ff81bd9f6624429c019f416136447ca28b3b676e/src/lib/mo_dds.f90#L224)
[Occurrence 2](https://git.ufz.de/mhm/mhm/-/blob/ff81bd9f6624429c019f416136447ca28b3b676e/src/lib/mo_dds.f90#L532)
**Complexity**
However, this example is a bit different to others in the sense that the message is embedded in `mo_dds` which is part of [FORCES](https://git.ufz.de/chs/forces/-/blob/develop/src/mo_dds.F90) library.
**Challenge**
To find a way to communicate with mhm user based on errors occurring at modules of shared/ external libraries like FORCES.
![Screenshot_2021-10-27_at_13.34.08](/uploads/415e67ca964f986cbd6da433a5745327/Screenshot_2021-10-27_at_13.34.08.png)wishlist futureSebastian MüllerSebastian Müllerhttps://git.ufz.de/mhm/mhm/-/issues/210improve check case 04 impact2022-01-13T17:02:42+01:00Robert Schweppeimprove check case 04 impactI do not really know, what test case 4 is supposed to check, but the case could cover more than it does so far:
- share common L0 data (only works in current settings for version 5.x) -> reordering of domains
- multiple different land co...I do not really know, what test case 4 is supposed to check, but the case could cover more than it does so far:
- share common L0 data (only works in current settings for version 5.x) -> reordering of domains
- multiple different land cover periods -> change simulation periods
- all routing/hydrology resolution combinations
I would propose this for version 6.x, what do you think @muellese?6.xSebastian MüllerSebastian Müllerhttps://git.ufz.de/mhm/mhm/-/issues/212check case 02 cell area2021-11-19T09:58:45+01:00Robert Schweppecheck case 02 cell areaI currently work on the mpr_finalize branch. There, check case 02 is failing. This check case is with `process_08==0`, a.k.a. routing turned off. The thing is now, that mHM does not have a clue about `level0` anymore and `level1` grid in...I currently work on the mpr_finalize branch. There, check case 02 is failing. This check case is with `process_08==0`, a.k.a. routing turned off. The thing is now, that mHM does not have a clue about `level0` anymore and `level1` grid information is inferred from the grid that the MPR generated parameters are on. It gets `lat`, `lon`, `mask` and that's it.
So there is no information on the cell area (relative area for each level1 cell that is covered by level0 cells). That is only done in mrm_init (mRM-MPR is still in mRM, it reads level0 land cover and dem) and calculated based on the level0 dem. So, as routing is turned off, cellArea is calculated based on the lat-lon grid spacing (meaning each level1 cell is 100% covered by level0). The check case fails here now. What to do (@muellese, @thober)?
Options:
- accept new behaviour, ignore failing check case and update reference files for version 6
- always calculate a pseudo-parameter "cellArea" in MPR, pass that to mHM and hard-code overwrite cellArea for level1 there6.x