mHM issueshttps://git.ufz.de/mhm/mhm/-/issues2022-06-17T16:13:44+02:00https://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/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/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/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/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/188MPR merge2022-01-13T17:11:27+01:00Stephan ThoberMPR mergeNext steps:
- speed performance in v5.9 verbessern
- Robert stellt Übersicht zu MPR Geschwindigkeit vor
- Sebastian beginnt Routinen von der alten MPR Implementation durch Routinen der neuen zu ersetzen
Open questions:
- how to create ...Next steps:
- speed performance in v5.9 verbessern
- Robert stellt Übersicht zu MPR Geschwindigkeit vor
- Sebastian beginnt Routinen von der alten MPR Implementation durch Routinen der neuen zu ersetzen
Open questions:
- how to create LuT in netCDF6.xSebastian MüllerSebastian Müllerhttps://git.ufz.de/mhm/mhm/-/issues/187unreachable else branch in feddes_et_reduction2021-07-21T17:21:12+02:00Nicola Nadine Döringunreachable else branch in feddes_et_reductionhttps://git.ufz.de/mhm/mhm/-/blob/175eff0ba82690418410d8c0703694a64b7e8c8c/src/mHM/mo_soil_moisture.f90#L353
should be:
```fortran
! SM >= FC
if (soil_moist >= soil_moist_FC) then
feddes_et_reduction = frac_roots
...https://git.ufz.de/mhm/mhm/-/blob/175eff0ba82690418410d8c0703694a64b7e8c8c/src/mHM/mo_soil_moisture.f90#L353
should be:
```fortran
! SM >= FC
if (soil_moist >= soil_moist_FC) then
feddes_et_reduction = frac_roots
! PW < SM < FC
else if (soil_moist > wilting_point) then
feddes_et_reduction = frac_roots * (soil_moist - wilting_point) / (soil_moist_FC - wilting_point)
! SM <= PW
else
feddes_et_reduction = 0.0_dp
end if
```v5.11.2https://git.ufz.de/mhm/mhm/-/issues/186unnecessary inout variable intent in soil_moisture2021-07-21T17:21:12+02:00Nicola Nadine Döringunnecessary inout variable intent in soil_moisturehttps://git.ufz.de/mhm/mhm/-/blob/175eff0ba82690418410d8c0703694a64b7e8c8c/src/mHM/mo_soil_moisture.f90#L141https://git.ufz.de/mhm/mhm/-/blob/175eff0ba82690418410d8c0703694a64b7e8c8c/src/mHM/mo_soil_moisture.f90#L141v5.11.2https://git.ufz.de/mhm/mhm/-/issues/185Conda package and development workflow2021-10-11T16:33:49+02:00Sebastian MüllerConda package and development workflow# Package
We should think about adding a conda-forge package for `mHM` at least for Linux and Mac.
We could use the netcdf-fortran feedstock as a guiding light for the recipe:
https://github.com/conda-forge/netcdf-fortran-feedstock
# ...# Package
We should think about adding a conda-forge package for `mHM` at least for Linux and Mac.
We could use the netcdf-fortran feedstock as a guiding light for the recipe:
https://github.com/conda-forge/netcdf-fortran-feedstock
# Development Environment
In addition we should provide a developing guide to set up everything needed in a conda environment (based on conda-forge):
- cmake (https://anaconda.org/conda-forge/cmake)
- fortran-compiler (https://anaconda.org/conda-forge/fortran-compiler) should be gfortran on Linux/Mac
- netcdf-fortran (https://anaconda.org/conda-forge/netcdf-fortran)
- fypp (https://anaconda.org/conda-forge/fypp)
Optional:
- openmp (https://anaconda.org/conda-forge/llvm-openmp)
- mpi (https://anaconda.org/conda-forge/mpi)
Testing:
- valgrind (https://anaconda.org/conda-forge/valgrind)
- pfUnit (not yet added: https://github.com/conda-forge/staged-recipes/pull/13282)
- Python: `pexpect`, `numpy`, `xarray`, `pandas` (for `run_mhm_checks.py`)
Documentation:
- doxygen (https://anaconda.org/conda-forge/doxygen)
- texlive-core (no pdflatex at the moment: https://github.com/conda-forge/texlive-core-feedstock/issues/19)6.xSebastian MüllerSebastian Müllerhttps://git.ufz.de/mhm/mhm/-/issues/184Calculation of CellArea in mHM2021-03-20T06:27:35+01:00Pallav Kumar Shresthapallav-kumar.shrestha@ufz.deCalculation of CellArea in mHM**Location**
`L0_grid_setup` in mo_grid.90
**Confusion**
My understanding is that [this line](https://git.ufz.de/mhm/mhm/-/blob/develop/src/common/mo_grid.f90#L331) in `L0_grid_setup` stores the area of all cells at current latitude a...**Location**
`L0_grid_setup` in mo_grid.90
**Confusion**
My understanding is that [this line](https://git.ufz.de/mhm/mhm/-/blob/develop/src/common/mo_grid.f90#L331) in `L0_grid_setup` stores the area of all cells at current latitude as the calculated area. This is because all cells at a latitude have equal area, cells at different latitudes have different areas, as also seen in the conceptual figure below.
![Screenshot_2021-03-14_at_14.25.55](/uploads/f6f704b4f4cdf89fef62e562708e9a55/Screenshot_2021-03-14_at_14.25.55.png)
However, if first index of `areaCell_2D` is row and the second index column, shouldn't it be `areaCell_2D(i, :)`, i.e. all columns at this row/ latitude? I have same comments for [this line](https://git.ufz.de/mhm/mhm/-/blob/develop/src/common/mo_grid.f90#L324) as well as [this line](https://git.ufz.de/mhm/mhm/-/blob/develop/src/common/mo_grid.f90#L325) - shouldn't we be using nrows than ncols to go through the latitudes?https://git.ufz.de/mhm/mhm/-/issues/180replace the ascii input files by netcdf input files2021-06-09T09:40:37+02:00Robert Schweppereplace the ascii input files by netcdf input filesAll 'ASCII' input files need to be replaced by 'netCDF' files. This will ensure future compatibility with the new MPR tool.
This will also lead to a change in orientation as ASCII files have their point of reference in the top left wher...All 'ASCII' input files need to be replaced by 'netCDF' files. This will ensure future compatibility with the new MPR tool.
This will also lead to a change in orientation as ASCII files have their point of reference in the top left whereas netCDF has it in the lower left corner. This leads to a sorting of all the input (including meteorology) and output files along the latitude coordinate.
All test cases will likely need to be redefined as the precision is different with ASCII and netCDF files.
We need also to come up with reasonable names for the x, y, z and land_cover_period coordinates in the netCDF files.
Additionally, we need to introduce a system of handling cell-dependent variable soil depths that mimicks the lookup-table based approach of the `soilclass_definiton.txt` file.
We might reorganize the input folder for that by separating the files based on their usage for mHM/MPR, the routing and the optimization.MPR integrationRobert SchweppeRobert Schweppe2021-05-14https://git.ufz.de/mhm/mhm/-/issues/179replace lib folder by FORCES2021-06-09T09:40:51+02:00Robert Schweppereplace lib folder by FORCESAfter issue #177, we replace the lib folder by FORCES. This should be pointing to a defined, released version of the library.After issue #177, we replace the lib folder by FORCES. This should be pointing to a defined, released version of the library.MPR integrationRobert SchweppeRobert Schweppe2021-04-06https://git.ufz.de/mhm/mhm/-/issues/178make MPR library available to mHM2021-06-09T09:41:01+02:00Robert Schweppemake MPR library available to mHMWe need to make the MPR library available to mHM. This should be done using native CMake commands (e.g. [FetchContent](https://cmake.org/cmake/help/latest/module/FetchContent.html) or [CMake CPM](https://github.com/cpm-cmake/CPM.cmake). ...We need to make the MPR library available to mHM. This should be done using native CMake commands (e.g. [FetchContent](https://cmake.org/cmake/help/latest/module/FetchContent.html) or [CMake CPM](https://github.com/cpm-cmake/CPM.cmake). Ideally we try to find a system where MPR is searched by find_package and if not found, it falls back to cloning and compiling and linking the repository itself.
In a first step, as find_package will not work, we make the cloning and compiling approach work. Later (and optionally), MPR thus needs to be available as a (static) library and there should be an install script (so find_package works).
Ideally, but not necessarily, MPR is in version 1.0.MPR integrationRobert SchweppeRobert Schweppe2021-04-06