mHM issueshttps://git.ufz.de/mhm/mhm/-/issues2021-12-07T15:17:57+01:00https://git.ufz.de/mhm/mhm/-/issues/213LAI time coordinate needs proper clipping and selecting in v62021-12-07T15:17:57+01:00Robert SchweppeLAI time coordinate needs proper clipping and selecting in v6In branch mpr_finalize there is currently no check for LAI periods (daily time step, monthly time step, yearly time step, average monthly values). Prior, the stepping method was given in the namelist and then the correct period matching ...In branch mpr_finalize there is currently no check for LAI periods (daily time step, monthly time step, yearly time step, average monthly values). Prior, the stepping method was given in the namelist and then the correct period matching the simulation period was selected.
This feature needs to implemented as well. When reading the restart file or the data arrays from MPR, the LAI coordinate must be checked (against certain naming conventions) and array must then be selected. The check routine in read_nc `get_time_vector_and_select` is already there and the indexing is done already for the land_cover_periods. The LAI stepping method needs to be inferred and correctly set (not done so far).6.xRobert SchweppeRobert Schweppehttps://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/211Docs for v5.x branch and repo cleanup2022-06-17T16:13:44+02:00Sebastian MüllerDocs for v5.x branch and repo cleanupWe need to provide docs for the v5.x branch in the future.
We could checkout the latest tags with something like this ([link1](https://stackoverflow.com/a/22857288/6696397), [link2](https://stackoverflow.com/a/52439270/6696397)):
- for ...We need to provide docs for the v5.x branch in the future.
We could checkout the latest tags with something like this ([link1](https://stackoverflow.com/a/22857288/6696397), [link2](https://stackoverflow.com/a/52439270/6696397)):
- for v5 releases:
```bash
git checkout $(git describe --match "v5*" --abbrev=0 --tags $(git rev-list --tags --max-count=1))
```
- for v6 releases:
```bash
git checkout $(git describe --match "v6*" --abbrev=0 --tags $(git rev-list --tags --max-count=1))
```
At the moment this is done with `checkout master` to provide the latest release. This could make the master branch redundant in the future so we could drop it (getting a smaller repository then).
`develop` could then also be renamed to `main`, with the reasoning provided here:
- https://sfconservancy.org/news/2020/jun/23/gitbranchname/
- https://about.gitlab.com/blog/2021/03/10/new-git-default-branch-name/v5.12Sebastian 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/209Some geology parameters switched off for optimisation2021-11-11T14:39:59+01:00Rohini KumarSome geology parameters switched off for optimisationSome of the geological parameters are switched off from optimisation. Does someone know why this is the case and when this changed happen?Some of the geological parameters are switched off from optimisation. Does someone know why this is the case and when this changed happen?https://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/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/206CI: GitLab-Runner not working in /public anymore2022-02-08T14:25:43+01:00Sebastian MüllerCI: GitLab-Runner not working in /public anymoreSince the EVE reboot we can't use `/public` as the base-folder for CI anymore.
Since we only need temporary space, we should use `/tmp`.Since the EVE reboot we can't use `/public` as the base-folder for CI anymore.
Since we only need temporary space, we should use `/tmp`.Sebastian MüllerSebastian Müllerhttps://git.ufz.de/mhm/mhm/-/issues/205Dumping Stack Error while activating processCase(10) = 2 - COSMIC forward op...2021-10-12T14:32:10+02:00Eshrat Fatimaeshrat.fatima@ufz.deDumping Stack Error while activating processCase(10) = 2 - COSMIC forward operator by Shuttleworth et al. 2013 and deactivating routing processCase(8) = 0!> routing
!> 0 - deactivated
!> 1 - Muskingum approach
!> 2 - adaptive timestep, constant celerity
!> 3 - adaptive timestep, spatially varying celerity
processCase(8) = 0
!> baseflow
!> 1 - recession parameters (not regionalized yet)
pr...!> routing
!> 0 - deactivated
!> 1 - Muskingum approach
!> 2 - adaptive timestep, constant celerity
!> 3 - adaptive timestep, spatially varying celerity
processCase(8) = 0
!> baseflow
!> 1 - recession parameters (not regionalized yet)
processCase(9) = 1
!> ground albedo of cosmic-ray neutrons
!> THIS IS WORK IN PROGRESS, DO NOT USE FOR RESEARCH
!> 0 - deactivated
!> 1 - inverse N0 based on Desilets et al. 2010
!> 2 - COSMIC forward operator by Shuttleworth et al. 2013
p![Error_mhm](/uploads/f89942447ec8b10ccd036e4b0754a707/Error_mhm.PNG)https://git.ufz.de/mhm/mhm/-/issues/204pe-proc folder is missing "ufz" for "river_network" (cut_mhm_input.py line 8...2021-12-06T20:35:07+01:00Mehmet Cüneyd Demirelpe-proc folder is missing "ufz" for "river_network" (cut_mhm_input.py line 88 and 112)Dear @thober
I use your py code "cut_mhm_input.py" for extracting subbasin based on idgauge.
Is it possible to share "ufz" library for the "cut_mhm_input.py" users?
Very crucial function "river_network" requires ufz library.
I tried "...Dear @thober
I use your py code "cut_mhm_input.py" for extracting subbasin based on idgauge.
Is it possible to share "ufz" library for the "cut_mhm_input.py" users?
Very crucial function "river_network" requires ufz library.
I tried "pip install ufz" but not success.
Line 88
from ufz import river_network, fwrite
Kind Regards,
Cüneydmhmpy v0.1Stephan ThoberStephan Thoberhttps://git.ufz.de/mhm/mhm/-/issues/203internal calibration and FinalParam.nml (processCase(3) = 4 and processCase(5...2021-09-19T03:07:51+02:00Mehmet Cüneyd Demirelinternal calibration and FinalParam.nml (processCase(3) = 4 and processCase(5) = -1)Dear @muellese
When the user calibrates the model with these options (processCase(3) = 4 and processCase(5) = -1) using DDS method and KGE (opti 9), the resultant best parameter file (FinalParam.nml) contains &soilmoisture1 and &PET0 i...Dear @muellese
When the user calibrates the model with these options (processCase(3) = 4 and processCase(5) = -1) using DDS method and KGE (opti 9), the resultant best parameter file (FinalParam.nml) contains &soilmoisture1 and &PET0 instead of &soilmoisture4 and &PETminus1.
This seems to be a small bug.
[ConfigFile.log](/uploads/6240754c106a349f9646f8e196d0bdaf/ConfigFile.log)
[dds_results.out](/uploads/61e3bd30c6ee876a0d80cfc97be606d5/dds_results.out)
[FinalParam.nml](/uploads/5dc78c9592af4008a14a42f2e8b299d6/FinalParam.nml)
[FinalParam.out](/uploads/9a83c27d64e5ffef1a77537352f5815f/FinalParam.out)Sebastian 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/197UBUNTU LTS 20.4: Couldn't read `mhm.nml` - EOF error2021-07-14T09:46:27+02:00Mehmet Cüneyd DemirelUBUNTU LTS 20.4: Couldn't read `mhm.nml` - EOF errorHi @muellese and @thober,
I am getting the following error when running calibration with one or two basins using
optimize=true, opti_function = 1, opti_method = 1. I believe that other options hit on the same wall/bug which seems to req...Hi @muellese and @thober,
I am getting the following error when running calibration with one or two basins using
optimize=true, opti_function = 1, opti_method = 1. I believe that other options hit on the same wall/bug which seems to require a simple .f90 editing.
![image](/uploads/ae77991a25637c202f48d65d3cc540dd/image.png)
p.s. I compile the mhm-develop using the codes below.
```bash
sudo apt-get install gfortran netcdf-bin libnetcdf-dev libnetcdff-dev cmake
wget https://git.ufz.de/mhm/mhm/-/archive/develop/mhm-develop.tar.gz
tar -zxvf mhm-develop.tar.gz
cd mhm-develop
mkdir build
cd build
cmake -DCMAKE_WITH_OpenMP:STRING=ON -DCMAKE_BUILD_TYPE=Release ..
make
cp ./mhm ..
cd ..
./mhm
```
Cheers,
CüneydSebastian MüllerSebastian Müllerhttps://git.ufz.de/mhm/mhm/-/issues/196Gitlab-Runner: shallow clone2021-07-09T16:32:57+02:00Sebastian MüllerGitlab-Runner: shallow cloneWe encounter some qouta issues on EVE with the gitlab-runner.
To solve these, we could set the fetch depth to `10` for example:
https://docs.gitlab.com/ee/ci/large_repositories/#shallow-cloning
But we need to take care of the documentat...We encounter some qouta issues on EVE with the gitlab-runner.
To solve these, we could set the fetch depth to `10` for example:
https://docs.gitlab.com/ee/ci/large_repositories/#shallow-cloning
But we need to take care of the documentation that checks out the `master` branch to build the `stable` docs. There we could add `--no-tags` to `GIT_FETCH_EXTRA_FLAGS`:
https://docs.gitlab.com/ee/ci/large_repositories/#git-fetch-extra-flagsv5.11.2Sebastian 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/194With mHM - v5.11.1 (segmentation issue - when routing process switched off i....2021-07-08T18:27:28+02:00Eshrat Fatimaeshrat.fatima@ufz.deWith mHM - v5.11.1 (segmentation issue - when routing process switched off i.e., processCase(8) = 0)At line 217 of file /cygdrive/d/mhm-v5.11.1/src/mHM/mo_mhm_read_config.f90 (unit = 30, file = 'mhm.nml')
Fortran runtime error: ![Error](/uploads/84d7f989310060d9a7db17028d5d57f9/Error.PNG)At line 217 of file /cygdrive/d/mhm-v5.11.1/src/mHM/mo_mhm_read_config.f90 (unit = 30, file = 'mhm.nml')
Fortran runtime error: ![Error](/uploads/84d7f989310060d9a7db17028d5d57f9/Error.PNG)v5.11.2Rohini KumarRohini Kumarhttps://git.ufz.de/mhm/mhm/-/issues/193reorganize folders and routines2021-06-16T10:17:28+02:00Robert Schweppereorganize folders and routinesThe idea is to merge the ottor/FSO_project branch into develop_v6. On the way there, another step is to reorganize the folders and routines. Only mHM, mRM and common will remain (MPR temporarily). The order of routines called might chang...The idea is to merge the ottor/FSO_project branch into develop_v6. On the way there, another step is to reorganize the folders and routines. Only mHM, mRM and common will remain (MPR temporarily). The order of routines called might changed to prepare the call of MPR as a standalone, external script.MPR integrationRobert SchweppeRobert Schweppehttps://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/191objective functions not documented2022-06-17T11:57:05+02:00Robert Schweppeobjective functions not documentedI am debugging check case 11 and it uses `opti_function = 33`. It is not documented in the `mhm.nml` template and also not commented in the code in `src/mHM/mo_objective_function.f90` and also not hinted at in the [documentation](https:/...I am debugging check case 11 and it uses `opti_function = 33`. It is not documented in the `mhm.nml` template and also not commented in the code in `src/mHM/mo_objective_function.f90` and also not hinted at in the [documentation](https://mhm.pages.ufz.de/mhm/latest/getstarted.html).v5.12https://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üller