mHM issueshttps://git.ufz.de/mhm/mhm/-/issues2020-12-01T09:17:55+01:00https://git.ufz.de/mhm/mhm/-/issues/91inconsistent treatment of sinks in river network setup2020-12-01T09:17:55+01:00Stephan Thoberinconsistent treatment of sinks in river network setupIf L11 != L0, then fdir < 0 marks sinks, but that does not work if L11 = L0. In the latter case fdir has to be 0. This was reported by @extostem.If L11 != L0, then fdir < 0 marks sinks, but that does not work if L11 = L0. In the latter case fdir has to be 0. This was reported by @extostem.5.11https://git.ufz.de/mhm/mhm/-/issues/86Adopt CI/CD to EasyBuild based module system on EVE2020-12-01T09:29:01+01:00Sebastian MüllerAdopt CI/CD to EasyBuild based module system on EVEPipelines are failing at the moment because of missing modules.Pipelines are failing at the moment because of missing modules.5.11Sebastian MüllerSebastian Müllerhttps://git.ufz.de/mhm/mhm/-/issues/81The runtime display of selected mHM fluxes for output is erroneous2020-08-31T16:24:12+02:00Pallav Kumar Shresthapallav-kumar.shrestha@ufz.deThe runtime display of selected mHM fluxes for output is erroneousThe runtime display of the user selected mHM fluxes for output has a bug.
* It seems there is a count error for mHM fluxes displayed at runtime
* However, the variables saved in the output file corresponds to the user selected options.The runtime display of the user selected mHM fluxes for output has a bug.
* It seems there is a count error for mHM fluxes displayed at runtime
* However, the variables saved in the output file corresponds to the user selected options.5.11Sebastian MüllerSebastian Müllerhttps://git.ufz.de/mhm/mhm/-/issues/79Numerical Recipes License required for objective_sse_boxcox function2020-12-01T09:07:56+01:00Robert SchweppeNumerical Recipes License required for objective_sse_boxcox functionHi @thober and @muellese. When working on MPR I wanted to update its dependency lightweight_fortran_lib. It is also used in mHM and there was another file added in August: `mo_boxcox.f90`. It uses some numerical recipes which do not come...Hi @thober and @muellese. When working on MPR I wanted to update its dependency lightweight_fortran_lib. It is also used in mHM and there was another file added in August: `mo_boxcox.f90`. It uses some numerical recipes which do not come under LGPL as the rest of the code (see also issue #26). The functions used are
`brent`, `mnbrak`, `swap`, `shft`. How do we proceed there?5.11Sebastian MüllerSebastian Müllerhttps://git.ufz.de/mhm/mhm/-/issues/78Add intel compiler to CI/CD2020-12-01T09:06:47+01:00Sebastian MüllerAdd intel compiler to CI/CDThe intel compiler should work with the makefile within the gitlab runner.The intel compiler should work with the makefile within the gitlab runner.5.11Sebastian MüllerSebastian Müllerhttps://git.ufz.de/mhm/mhm/-/issues/71mRM output file of discharge.nc does not have missing_value nor Fill_Value de...2020-10-08T20:17:36+02:00Oldrich RakovecmRM output file of discharge.nc does not have missing_value nor Fill_Value defined as -9999.5.11Stephan ThoberStephan Thoberhttps://git.ufz.de/mhm/mhm/-/issues/50netCDF read_forcing_nc needs to be renamed2020-10-08T20:17:36+02:00Stephan ThobernetCDF read_forcing_nc needs to be renamedThe module read_forcing_nc needs to be renamed. It is used whenever a netCDF file is read, irrespective whether it is a forcing variable or not.The module read_forcing_nc needs to be renamed. It is used whenever a netCDF file is read, irrespective whether it is a forcing variable or not.5.11Sebastian MüllerSebastian Müllerhttps://git.ufz.de/mhm/mhm/-/issues/49FinalParam.nml routing section2020-12-01T09:10:03+01:00Mehmet Cüneyd DemirelFinalParam.nml routing sectionHello,
When I use default test_basin set-up (nbasin=1) in optimize=1 mode, the resultant "FinalParam.nml" file should have "&routing3" in between lines 69 and 70 as in other processes:
! percolation
&percolation1
rechargeCoefficien...Hello,
When I use default test_basin set-up (nbasin=1) in optimize=1 mode, the resultant "FinalParam.nml" file should have "&routing3" in between lines 69 and 70 as in other processes:
! percolation
&percolation1
rechargeCoefficient = 0.0000000000000000 , 50.000000000000000 , 32.113965205509707 , 1 , 1
rechargeFactor_karstic = -5.0000000000000000 , 5.0000000000000000 , -1.0000000000000000 , 1 , 1
gain_loss_GWreservoir_karstic = 1.0000000000000000 , 1.0000000000000000 , 1.0000000000000000 , 0 , 1
/
! routing
slope_factor = 0.10000000000000001 , 100.00000000000000 , 30.000000000000000 , 0 , 1
/
[Sample file](https://www.dropbox.com/s/yeh1hlzeeu91hse/FinalParam.nml?dl=0)
p.s. minor issue: test_basin2 gauge/meteo should also have 1990-1993 data for a smooth example in mhm.nml
If one starts dummy calibration s/he gets this error below.
"Simulation period is not covered by observations! test_basin_2/input/gauge/45.txt"5.11Stephan ThoberStephan Thober2019-11-08https://git.ufz.de/mhm/mhm/-/issues/46missing soilmoisture parameters for Jarvis equation (option 3) after optimisa...2020-12-01T09:07:19+01:00Johannes Brennermissing soilmoisture parameters for Jarvis equation (option 3) after optimisationI spot missing @soilmoisture3 in mhm_parameter.nml after optimisation.
Feddes (option 1) and Jarvis (option 2) are fine.
[mhm_parameter.nml](/uploads/5488bd5827a464879f279c7043f080ea/mhm_parameter.nml)I spot missing @soilmoisture3 in mhm_parameter.nml after optimisation.
Feddes (option 1) and Jarvis (option 2) are fine.
[mhm_parameter.nml](/uploads/5488bd5827a464879f279c7043f080ea/mhm_parameter.nml)5.11https://git.ufz.de/mhm/mhm/-/issues/45missing meta information on dimensions in restart files2020-12-01T09:05:22+01:00Robert Schweppemissing meta information on dimensions in restart filesThere is a problem with reading from restart files. Since mHM 5.9, MPR is always executed before the call to mhm_eval. When reading restart files, all parameters for all land cover scenes, domains and soil horizons must be contained in t...There is a problem with reading from restart files. Since mHM 5.9, MPR is always executed before the call to mhm_eval. When reading restart files, all parameters for all land cover scenes, domains and soil horizons must be contained in the restart file.
Currently, there is no meta information contained on land cover scenes or soil horizons. Also, there is no check in mHM if the land cover scenes or soil horizons in the restart file are consistent with the eval_period or soil layering as specified in the namelist.
There is some preliminary work on this in the branch #22 that needs to be merged. It introduces dimension bounds in the restart files and an extensive checking of these bounds and the selection of correct scenes and layers.
@ottor will work on that and present the presumed changes of the implementation at the next mHM devel meeting.5.11Robert SchweppeRobert Schweppehttps://git.ufz.de/mhm/mhm/-/issues/42Potential issue with building mhm via cmake2020-12-01T09:26:56+01:00Marius OsterPotential issue with building mhm via cmakeBoth me and @extluedt have issues with building mhm with the makefile generated by cmake in the current develop-branch.
![cmake](/uploads/4aa344e9935645ed7e3c25585e4b8a79/cmake.PNG)
Getting the makefile with cmake seems to work fine a...Both me and @extluedt have issues with building mhm with the makefile generated by cmake in the current develop-branch.
![cmake](/uploads/4aa344e9935645ed7e3c25585e4b8a79/cmake.PNG)
Getting the makefile with cmake seems to work fine as far as I can tell, but running 'make' on it fails
![make](/uploads/6fcbf2207826885f6826ef8acc5b70af/make.PNG)
For both me and Stefan building the model via the Makefile (manual edits) from the master branch works just fine.
*EDIT*
It seems when cloning from gitlab not all submodules have been properly included, causing missing files.
This error is thus resolved.
However, the model still cannot be built (see screencap).
![make_new_error](/uploads/ec1aa6fd30b563dd0dc5b178c5bdd204/make_new_error.PNG)
This is using the the recommended the libraries as recommended in install.md
For completion's sake it should be noted that cmake works just fine using cygwin, generating the mhm executable.5.11https://git.ufz.de/mhm/mhm/-/issues/40Finalparam.nml format with Intel2021-08-05T22:21:01+02:00Pallav Kumar Shresthapallav-kumar.shrestha@ufz.deFinalparam.nml format with IntelThe Finalparam.nml from Intel compiled executable is not compatible as input with GNU compiled executables. Intel for some reason includes unwanted line breaks which GNU doesn't accept (Intel works with it though).
Finalparam.nml from ...The Finalparam.nml from Intel compiled executable is not compatible as input with GNU compiled executables. Intel for some reason includes unwanted line breaks which GNU doesn't accept (Intel works with it though).
Finalparam.nml from INTEL:
![Screenshot_2019-05-27_at_12.00.51](/uploads/d3b2f25b8c473fad4ff43b44f26ccd5f/Screenshot_2019-05-27_at_12.00.51.png)
Finalparam.nml from GNU:
![Screenshot_2019-05-27_at_12.14.20](/uploads/bc31e7488c21e86334d17527803dff6d/Screenshot_2019-05-27_at_12.14.20.png)5.11https://git.ufz.de/mhm/mhm/-/issues/34Renaming basins to domain2020-12-01T09:04:49+01:00Oldrich RakovecRenaming basins to domain- change this in the namelists
- change also the variable names- change this in the namelists
- change also the variable names5.11https://git.ufz.de/mhm/mhm/-/issues/29I/O L1_jarvis_thresh_c1 to restart file for process id 2 AND 32020-12-01T09:07:44+01:00Robert SchweppeI/O L1_jarvis_thresh_c1 to restart file for process id 2 AND 3Currently, it is only read and written to and from restart files if the processmatrix(3,1) == 2, we have to include 3 also.Currently, it is only read and written to and from restart files if the processmatrix(3,1) == 2, we have to include 3 also.5.11Robert SchweppeRobert Schweppehttps://git.ufz.de/mhm/mhm/-/issues/27Adaptive routing does not allow to run without at least 1 gauge specification.2020-10-07T18:25:45+02:00Oldrich RakovecAdaptive routing does not allow to run without at least 1 gauge specification.Dear all,
There appears a segmentation fault for adaptive routing (processCase(8) = 2), if nGaugesTotal = 0 && NoGauges_basin(1) = 0 && dir_Gauges(1) = "./", i.e., Qobs is not provided.
One selects this option when is interes...Dear all,
There appears a segmentation fault for adaptive routing (processCase(8) = 2), if nGaugesTotal = 0 && NoGauges_basin(1) = 0 && dir_Gauges(1) = "./", i.e., Qobs is not provided.
One selects this option when is interested in the gridded runoff only.
Note that processCase(8) = 1 handles this option.
Could @thober check, where could be the problem in mRM?
A possible workaround is to create idgauges.asc with at least one gauge, but we thought with @lese better to fix in the code as well ...
Thanks!
Olda5.11Stephan ThoberStephan Thoberhttps://git.ufz.de/mhm/mhm/-/issues/26get rid of numerical recipes2020-12-01T09:14:09+01:00Robert Schweppeget rid of numerical recipesCurrently in our lib folder, we do have `mo_corr.f90` with modules calculating mainly autocorrelation metrics. Two procedures from therein are used in `mo_mrm_signatures.f90`, which itself is not currently used in the code.
As there wil...Currently in our lib folder, we do have `mo_corr.f90` with modules calculating mainly autocorrelation metrics. Two procedures from therein are used in `mo_mrm_signatures.f90`, which itself is not currently used in the code.
As there will be some restructuring again in order to get #22 done, the lib module will be a seperate repo and should not contain anything not licensed under GPL. So `mo_corr.f90`, which is based on the Numerical Recipes and not free-to-use, needs to go. @lese called for a rewrite of the relevant function so we can keep `mo_mrm_signatures.f90` in the code. For now, I deleted that file in the new repository https://git.ufz.de/chs/lightweight_fortran_lib. Please add a new version of `mo_corr.f90` there and reinsert `mo_mrm_signatures.f90` in the branch for #22.5.11Sebastian MüllerSebastian Müllerhttps://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/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/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-06