mHM issueshttps://git.ufz.de/mhm/mhm/-/issues2022-01-13T17:14:07+01:00https://git.ufz.de/mhm/mhm/-/issues/215MPR: State and TODOs2022-01-13T17:14:07+01:00Sebastian MüllerMPR: State and TODOs# State:
- See diff of !90
- compiling and running
- check case not all working ATM
- case....
# TODOs
- one MPR instance per domain (https://git.ufz.de/chs/MPR/-/merge_requests/84)
- speed optimization (affected by above and https:/...# State:
- See diff of !90
- compiling and running
- check case not all working ATM
- case....
# TODOs
- one MPR instance per domain (https://git.ufz.de/chs/MPR/-/merge_requests/84)
- speed optimization (affected by above and https://git.ufz.de/chs/MPR/-/merge_requests/79)
- documentation of refactoring and changes
- update pfunit tests6.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.xhttps://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/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/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 Kaluzahttps://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/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/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/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/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/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/113[Enhancement] read meteo weights separately for each variable2020-08-31T17:08:25+02:00Sebastian Müller[Enhancement] read meteo weights separately for each variableAt the moment, you can only enable reading meteo weights for all meteo forcings jointly.
To deal with different availabilities of data, we should add switches to enable weights reading for each meteo forcing separately.At the moment, you can only enable reading meteo weights for all meteo forcings jointly.
To deal with different availabilities of data, we should add switches to enable weights reading for each meteo forcing separately.6.xSebastian MüllerSebastian Müllerhttps://git.ufz.de/mhm/mhm/-/issues/112[Enhancement] `global_parameters` class2022-04-28T15:59:34+02:00Sebastian Müller[Enhancement] `global_parameters` classAt the moment the global parameters are an array where all needed parameters are just appended.
This is prone to failure, since you always have to keep track of positions for the parameters of your desired process.
Proposal:
Create a `g...At the moment the global parameters are an array where all needed parameters are just appended.
This is prone to failure, since you always have to keep track of positions for the parameters of your desired process.
Proposal:
Create a `global_parameters` class, where every process can register the parameters, init-values and ranges used in optimization.
These registrations could than be accessed by registration IDs (for example).
The current behavior, to be represented as an array could be provided by a class-method.6.xSebastian MüllerSebastian Müllerhttps://git.ufz.de/mhm/mhm/-/issues/108consistent file handling in mhm.nml2020-08-31T17:08:29+02:00Stephan Thoberconsistent file handling in mhm.nmlWith merge request !34 , restart file names are handled more flexibly for the user. The same procedure should be applied to all other file names in mhm.nml.With merge request !34 , restart file names are handled more flexibly for the user. The same procedure should be applied to all other file names in mhm.nml.6.xSebastian MüllerSebastian Müllerhttps://git.ufz.de/mhm/mhm/-/issues/106driver refactoring and OOP2022-04-28T15:59:41+02:00Stephan Thoberdriver refactoring and OOPreorganize global data and methods according to classes for individual processes; adapt driver to new classes.
riv_temp serves as a template.reorganize global data and methods according to classes for individual processes; adapt driver to new classes.
riv_temp serves as a template.6.xSebastian MüllerSebastian Müllerhttps://git.ufz.de/mhm/mhm/-/issues/105move directories_mHM to directories_general as a meteo dir2020-12-01T09:20:42+01:00Sebastian Müllermove directories_mHM to directories_general as a meteo dirAll specified folders under `directories_mHM` in `mhm.nml` can be combined essentially in `directories_general` under a `dir_Meteo`.
https://git.ufz.de/mhm/mhm/-/blob/develop/mhm.nml#L272
Does somebody demand to be able to specify diff...All specified folders under `directories_mHM` in `mhm.nml` can be combined essentially in `directories_general` under a `dir_Meteo`.
https://git.ufz.de/mhm/mhm/-/blob/develop/mhm.nml#L272
Does somebody demand to be able to specify different folders for each entry in `directories_mHM`?
Otherwise we could get rid of that.6.xSebastian MüllerSebastian Müllerhttps://git.ufz.de/mhm/mhm/-/issues/104[Enhancement] Container for global variables (mHM, mRM)2022-04-28T15:27:45+02:00Sebastian Müller[Enhancement] Container for global variables (mHM, mRM)In order to be future-prove, we should think about organizing global variables in containers to pass them around.In order to be future-prove, we should think about organizing global variables in containers to pass them around.6.xhttps://git.ufz.de/mhm/mhm/-/issues/96mRM: mo_mrm_net_startup revision2020-12-01T09:24:36+01:00Stephan ThobermRM: mo_mrm_net_startup revisionmo_mrm_net_startup.f90 is outdated and needs substantial revision with regard to memory and run timemo_mrm_net_startup.f90 is outdated and needs substantial revision with regard to memory and run time6.xStephan ThoberStephan Thoberhttps://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/74Enforce CF conventions on mHM output file2024-02-26T09:46:15+01:00Stephan ThoberEnforce CF conventions on mHM output fileCF conventions expect coordinates at (0,0) to be in lower left corner. For historic reasons, (ESRI conventions), it starts in the upper left. Everything needs to be inverted. Flow directions needs to be adjusted!
Here is the original em...CF conventions expect coordinates at (0,0) to be in lower left corner. For historic reasons, (ESRI conventions), it starts in the upper left. Everything needs to be inverted. Flow directions needs to be adjusted!
Here is the original email from Luis:
> Sorry, I made a mistake in the conventions in my previous email.
> ESRI: currently in mHM. Start top left x_11. It is called "English reading order"
> https://en.m.wikipedia.org/wiki/Esri_grid
> CF convention (I guess) is what Ncview expects. Similar to a coordinate system. x_11 is at (0,0) bottom left.
> Everything is trivial by the inversion of coordinates with the exception of flow direction.
> We need to clean up this issue asap.
> Luis6.xRobert SchweppeRobert Schweppe