mHM issueshttps://git.ufz.de/mhm/mhm/-/issues2021-09-19T03:07:51+02:00https://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-06https://git.ufz.de/mhm/mhm/-/issues/177make FORCES library available to mHM2021-06-09T09:41:11+02:00Robert Schweppemake FORCES library available to mHMWe need to make the FORCES 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 FORCES 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 FORCES 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), FORCES thus needs to be available as a (static) library and there should be an install script (so find_package works).
Ideally, but not necessarily, FORCES is in version 1.0.MPR integrationRobert SchweppeRobert Schweppe2021-04-06https://git.ufz.de/mhm/mhm/-/issues/174Cygwin - Segmentation fault (core dumped) when using "cmake -DCMAKE_WITH_Open...2021-03-03T11:14:48+01:00Mehmet Cüneyd DemirelCygwin - Segmentation fault (core dumped) when using "cmake -DCMAKE_WITH_OpenMP:STRING=ON .."Dear @kaluza,
I could compile mhm-v5.11.0-rc1 with cmake -DCMAKE_WITH_OpenMP:STRING=ON ..
However, I am getting segmentation error as shown below.
Openmp was working when using "make" with older versions of mhm e.g. v5.10_fixed.
If you ...Dear @kaluza,
I could compile mhm-v5.11.0-rc1 with cmake -DCMAKE_WITH_OpenMP:STRING=ON ..
However, I am getting segmentation error as shown below.
Openmp was working when using "make" with older versions of mhm e.g. v5.10_fixed.
If you can comment on this, it would be great. I can try the develop version if some updates were done.
My cygwin info:
![openmp](/uploads/7d11366a8630c774fdc0a5381ec748ae/openmp.png)
Error:
![segment](/uploads/4607d77ec11381c2d6c38d2c413854dd/segment.png)v5.11.1Sebastian MüllerSebastian Müllerhttps://git.ufz.de/mhm/mhm/-/issues/173snow melt output in mhm_flux_states2022-06-17T20:58:54+02:00sluedtkesnow melt output in mhm_flux_statesIs it possible the add the snow-melt variable of the model to the output written in "mhm_flux_states".Is it possible the add the snow-melt variable of the model to the output written in "mhm_flux_states".v5.12Sebastian MüllerSebastian Müllerhttps://git.ufz.de/mhm/mhm/-/issues/165NAG check failing due to expired license2021-01-02T16:27:45+01:00Sebastian MüllerNAG check failing due to expired licenseCI for NAG is failing due to expired license: https://git.ufz.de/mhm/mhm/-/jobs/38869
WKDV is informed:
https://git.ufz.de/it/eve/software/-/issues/211CI for NAG is failing due to expired license: https://git.ufz.de/mhm/mhm/-/jobs/38869
WKDV is informed:
https://git.ufz.de/it/eve/software/-/issues/211Sebastian MüllerSebastian Müllerhttps://git.ufz.de/mhm/mhm/-/issues/160cmake error in compiling mhm-develop2020-11-30T14:16:48+01:00Mehmet Cüneyd Demirelcmake error in compiling mhm-developDear @muellese and @thober
I get the following cmake errors. I tried bringing cmake related files from v5.10_fixed but didnt help.
![image](/uploads/4154d36f744e1631ad510adf8080d7b2/image.png)
Also I don't see MakeFile in https://g...Dear @muellese and @thober
I get the following cmake errors. I tried bringing cmake related files from v5.10_fixed but didnt help.
![image](/uploads/4154d36f744e1631ad510adf8080d7b2/image.png)
Also I don't see MakeFile in https://git.ufz.de/mhm/mhm.5.11Sebastian MüllerSebastian Müller