mHM issueshttps://git.ufz.de/mhm/mhm/-/issues2022-06-17T20:58:53+02:00https://git.ufz.de/mhm/mhm/-/issues/149snow melt flux2022-06-17T20:58:53+02:00Stephan Thobersnow melt fluxThis commit integrates snow melt flux:
https://git.ufz.de/ulysses/mhm_src/-/commit/87d04c8ad16fc5627289e149097b2512f5b94e19This commit integrates snow melt flux:
https://git.ufz.de/ulysses/mhm_src/-/commit/87d04c8ad16fc5627289e149097b2512f5b94e19v5.12Sebastian MüllerSebastian Müllerhttps://git.ufz.de/mhm/mhm/-/issues/133Improve error message when soil or geology input data is not masked properly2022-07-07T10:55:23+02:00Marco HannemannImprove error message when soil or geology input data is not masked properlyWhen soil_class.asc or geology_class.asc are not masked properly and contain NoData-Values where other morphological input data sets are defined, following error will be thrown:
```
***ERROR: Class -9999 is missing
in input fi...When soil_class.asc or geology_class.asc are not masked properly and contain NoData-Values where other morphological input data sets are defined, following error will be thrown:
```
***ERROR: Class -9999 is missing
in input file soil_classdefinition.txt ...
```
Since -9999 is a NoData value here and not a valid class ID, the user should get the advice to check his masking routine.v5.12Sebastian MüllerSebastian Müllerhttps://git.ufz.de/mhm/mhm/-/issues/132Improve error message when nSoil_Types higher than actual classes2022-07-07T10:55:11+02:00Marco HannemannImprove error message when nSoil_Types higher than actual classesWhen nSoil_Types in the header of soil_classdefinition.txt is lower than the actual classes defined, an error will be raised
that class n is missing.
If it is higher than the actual classes defined, mHM will return a Segmentation fault...When nSoil_Types in the header of soil_classdefinition.txt is lower than the actual classes defined, an error will be raised
that class n is missing.
If it is higher than the actual classes defined, mHM will return a Segmentation fault (SIGSEGV):
```
Program received signal SIGSEGV: Segmentation fault - invalid memory reference.
Backtrace for this error:
#0 0x2B7084854347
#1 0x2B708485494E
#2 0x2B70863863FF
#3 0x54FFB4 in __mo_soil_database_MOD_generate_soil_database
#4 0x55A82C in __mo_mpr_startup_MOD_mpr_initialize
#5 0x5C87D4 in __mo_startup_MOD_mhm_initialize
#6 0x59119F in MAIN__ at mhm_driver.f90:?
Segmentation fault
```
This makes it hard to identify the root cause of the error for the userv5.12Sebastian MüllerSebastian Müllerhttps://git.ufz.de/mhm/mhm/-/issues/131L0 resolutions with repeating decimals2022-07-07T10:38:33+02:00Pallav Kumar Shresthapallav-kumar.shrestha@ufz.deL0 resolutions with repeating decimals**Background**
* MERIT DEM is at 3 arc seconds i.e. 0 deg 0 min 3 secs OR 0.00083333.....33333…..
* I use ASCII input format. All of input .asc files and header.txt have the L0 resolution in decimal degrees.
**Issue**
* I noticed that...**Background**
* MERIT DEM is at 3 arc seconds i.e. 0 deg 0 min 3 secs OR 0.00083333.....33333…..
* I use ASCII input format. All of input .asc files and header.txt have the L0 resolution in decimal degrees.
**Issue**
* I noticed that in order to avoid truncation errors the user needs to enter a lot of decimal places in the .asc files and header.txt. E.g. 18 decimal places were not enough. So I entered 100 decimal places - worked. (note: the error occurs at lines 546-547 of mo_grid.f90, calculation of xllcorner and yllcorner from L0 and L2 resolutions)
**Solution (?)**
* In mHM we have two coordinate systems - metric and lat lon. The latter has numeral format of decimal degrees. However, data which come as deg-min-sec when converted to decimal degrees could bear “repeating decimals” leading to truncation errors as in case of MERIT DEM resolution.
* Wouldn’t it be better if users had the option to enter the resolution in deg-min-sec or decimal degrees as deemed fit? That would be more elegant/ intuitive than entering a lot of decimal places.
* I don’t have experience in using .nc files for L0 data (except lai.nc). Does that solve this issue already?v5.12Sebastian MüllerSebastian Müllerhttps://git.ufz.de/mhm/mhm/-/issues/126use of ceiling in calculate_grid_properties2022-07-07T10:38:33+02:00Stephan Thoberuse of ceiling in calculate_grid_propertiesHi Robert,
in calculate_grid_properties in mo_grid, the Fortran intrinsic ceiling is used to calculate Ncols, Nrows. If the cell factor is close to 1, but not exactly one, this can lead to additional rows and cols. I changed to nint in ...Hi Robert,
in calculate_grid_properties in mo_grid, the Fortran intrinsic ceiling is used to calculate Ncols, Nrows. If the cell factor is close to 1, but not exactly one, this can lead to additional rows and cols. I changed to nint in Ulysses. Do you have any objection to changing it in mhm develop too?
Thanks
Stephan
p.s.: This is my last message during my holidays ;)v5.12Robert SchweppeRobert Schweppehttps://git.ufz.de/mhm/mhm/-/issues/121PGI-Fortran support2022-04-28T15:23:40+02:00Sebastian MüllerPGI-Fortran supportWe now have the PGI Fortran compiler on EVE (https://git.ufz.de/it/eve/software/-/issues/176).
ATM there are some problems/bugs that need to be resolved in order to make it work:
* [x] we need a load-script for the PGI compiler on EVE
*...We now have the PGI Fortran compiler on EVE (https://git.ufz.de/it/eve/software/-/issues/176).
ATM there are some problems/bugs that need to be resolved in order to make it work:
* [x] we need a load-script for the PGI compiler on EVE
* [ ] in `mhm_driver.f90`:
* the pointer `eval` should be of type `eval_interface` from `mo_optimization_utils`
https://git.ufz.de/mhm/mhm/-/blob/develop/src/mHM/mhm_driver.f90#L172
* the pointer `obj_func` should be of type `objective_interface` from `mo_optimization_utils`
https://git.ufz.de/mhm/mhm/-/blob/develop/src/mHM/mhm_driver.f90#L173
* [ ] in https://git.ufz.de/mhm/mhm/-/blob/develop/src/common/mo_read_latlon.f90#L106, an error occures:
```
0: SHAPE: arg not associated with array
```
(very descriptive) ... my educated guess is, that PGI has a problem with the generic procedures in `mo_netcdf` (https://git.ufz.de/mhm/mhm/-/blob/develop/src/common/mo_read_latlon.f90#L106)
* [ ] there are a lot of pre-processor directives across the code-base to handle PGI-Fortran compilation. We would need to test, which of these are still necessary and if we would need more of them to handle problems like the one described above (what a mess)
* [ ] is it worth the hassle?
List TBC...v5.12Sebastian MüllerSebastian Müllerhttps://git.ufz.de/mhm/mhm/-/issues/107hourly meteo forcing nc2023-01-12T11:13:47+01:00Stephan Thoberhourly meteo forcing ncThis is an email send by Olda:
Hi Stephan,
Just a follow-up on Husain's comment during mhm develop meeting.
During today’s mHM meeting I have checked further the reading of hourly data is not working in mHM.
I remember checking this...This is an email send by Olda:
Hi Stephan,
Just a follow-up on Husain's comment during mhm develop meeting.
During today’s mHM meeting I have checked further the reading of hourly data is not working in mHM.
I remember checking this already long time ago…
FYI, I have attached 3-meteo files with modified time step for the test basin at hourly time,
This can be used in the test example with modified time window:
```fortran
warming_Days(1) = 0
!> first year of wanted simulation period
eval_Per(1)%yStart = 1989
!> first month of wanted simulation period
eval_Per(1)%mStart = 01
!> first day of wanted simulation period
eval_Per(1)%dStart = 02
!> last year of wanted simulation period
eval_Per(1)%yEnd = 1989
!> last month of wanted simulation period
eval_Per(1)%mEnd = 02
!> last day of wanted simulation period
eval_Per(1)%dEnd = 02
```
The first thing is that `./src/common/mo_read_forcing_nc.f90` fails to recognize, these data are at hourly time step.
If `inctimestep` is hardcoded in there to `-4`, then seq fault occurs later in the code.
I did not go deeper, but just want to confirm, there is an issue to be checked.
Thanks!
Best regards,
Olda
[pet.nc](/uploads/042c56ffde633de2f2efb26a126d6c2a/pet.nc)
[tavg.nc](/uploads/005f8ee487b8fa381e8def6fcf7432b2/tavg.nc)
[header.txt](/uploads/4ae6bdb6d30e8de7a3a1cf0fa499dbf2/header.txt)
[pre.nc](/uploads/71f9ed2044168a54a6a9c1bb5bddf115/pre.nc)v5.12Sebastian MüllerSebastian Müllerhttps://git.ufz.de/mhm/mhm/-/issues/77improve error message in mo_read_time_series.f902022-06-17T20:59:15+02:00Stephan Thoberimprove error message in mo_read_time_series.f90in mo_read_time_series.f90, a end of line error occurres if there are too few lines in the file. The error message could be more detailed, stating how many lines have been read and how many are expected by the code.in mo_read_time_series.f90, a end of line error occurres if there are too few lines in the file. The error message could be more detailed, stating how many lines have been read and how many are expected by the code.v5.12Sebastian MüllerSebastian Müllerhttps://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/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/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/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üllerhttps://git.ufz.de/mhm/mhm/-/issues/156cmake build fails under ubuntu 20.04 with tag 5.10_fixed and tag 5.102020-10-06T15:02:00+02:00sluedtkecmake build fails under ubuntu 20.04 with tag 5.10_fixed and tag 5.10Trying to build mHM fails with the listed setting above.
For tag 5.10_fixed
```
git checkout 5.10_fixed
HEAD is now at b7181fe Update README.md
root@09a3ccc82a3d:/mhm# git status
HEAD detached at 5.10_fixed
nothing to commit, working t...Trying to build mHM fails with the listed setting above.
For tag 5.10_fixed
```
git checkout 5.10_fixed
HEAD is now at b7181fe Update README.md
root@09a3ccc82a3d:/mhm# git status
HEAD detached at 5.10_fixed
nothing to commit, working tree clean
root@09a3ccc82a3d:/mhm# mkdir build && cd build
root@09a3ccc82a3d:/mhm/build# cmake ..
-- The Fortran compiler identification is GNU 9.3.0
-- Check for working Fortran compiler: /usr/bin/f95
-- Check for working Fortran compiler: /usr/bin/f95 -- works
-- Detecting Fortran compiler ABI info
-- Detecting Fortran compiler ABI info - done
-- Checking whether /usr/bin/f95 supports Fortran 90
-- Checking whether /usr/bin/f95 supports Fortran 90 -- yes
-- build INDEPENDENT of module system OFF
-- search in additional directory for netCDF
-- found /usr/bin/nf-config
-- netcdff includes /usr/include
-- netcdff netcdf link flags -I/usr/include
-- netcdff netcdf library link flags -L/usr/lib/x86_64-linux-gnu -lnetcdff -Wl,-Bsymbolic-functions -Wl,-z,relro -Wl,-z,now -lnetcdf -lnetcdf -ldl -lm
-- found /usr/lib/x86_64-linux-gnu/libnetcdff.so
-- found /usr/lib/x86_64-linux-gnu/libnetcdf.so
-- found /usr/lib/x86_64-linux-gnu/libnetcdf.so
-- found /usr/lib/x86_64-linux-gnu/libdl.so
-- found /usr/lib/x86_64-linux-gnu/libm.so
-- found netcdf libraries /usr/lib/x86_64-linux-gnu/libnetcdff.so;/usr/lib/x86_64-linux-gnu/libnetcdf.so;/usr/lib/x86_64-linux-gnu/libnetcdf.so;/usr/lib/x86_64-linux-gnu/libdl.so;/usr/lib/x86_64-linux-gnu/libm.so
-- found netcdf other flags -Wl,-Bsymbolic-functions;-Wl,-z,relro;-Wl,-z,now
-- Performing Test CPP_FLAG
-- Performing Test CPP_FLAG - Success
-- the following debug flags will be used: -g -pedantic-errors -Wall -W -O -g -Wno-maybe-uninitialized
-- Configuring done
-- Generating done
-- Build files have been written to: /mhm/build
root@09a3ccc82a3d:/mhm/build# make
Scanning dependencies of target mhm
[ 1%] Building Fortran object CMakeFiles/mhm.dir/src/lib/mo_kind.f90.o
[ 1%] Building Fortran object CMakeFiles/mhm.dir/src/MPR/mo_mpr_constants.f90.o
[ 2%] Building Fortran object CMakeFiles/mhm.dir/src/common/mo_common_variables.f90.o
[ 3%] Building Fortran object CMakeFiles/mhm.dir/src/lib/mo_constants.f90.o
[ 4%] Building Fortran object CMakeFiles/mhm.dir/src/lib/mo_message.f90.o
[ 5%] Building Fortran object CMakeFiles/mhm.dir/src/MPR/mo_mpr_global_variables.f90.o
[ 6%] Building Fortran object CMakeFiles/mhm.dir/src/common/mo_common_constants.f90.o
[ 7%] Building Fortran object CMakeFiles/mhm.dir/src/lib/mo_append.f90.o
[ 8%] Building Fortran object CMakeFiles/mhm.dir/src/lib/mo_string_utils.f90.o
[ 9%] Building Fortran object CMakeFiles/mhm.dir/src/lib/mo_utils.f90.o
[ 10%] Building Fortran object CMakeFiles/mhm.dir/src/MPR/mo_upscaling_operators.f90.o
[ 11%] Building Fortran object CMakeFiles/mhm.dir/src/MPR/mo_mpr_pet.f90.o
[ 12%] Building Fortran object CMakeFiles/mhm.dir/src/MPR/mo_mpr_runoff.f90.o
[ 13%] Building Fortran object CMakeFiles/mhm.dir/src/MPR/mo_mpr_smhorizons.f90.o
[ 14%] Building Fortran object CMakeFiles/mhm.dir/src/MPR/mo_mpr_soilmoist.f90.o
[ 15%] Building Fortran object CMakeFiles/mhm.dir/src/MPR/mo_multi_param_reg.f90.o
[ 16%] Building Fortran object CMakeFiles/mhm.dir/src/lib/mo_timer.f90.o
[ 17%] Building Fortran object CMakeFiles/mhm.dir/src/MPR/mo_mpr_eval.f90.o
[ 18%] Building Fortran object CMakeFiles/mhm.dir/src/MPR/mo_mpr_file.f90.o
[ 19%] Building Fortran object CMakeFiles/mhm.dir/src/common/mo_common_functions.f90.o
[ 20%] Building Fortran object CMakeFiles/mhm.dir/src/lib/mo_finish.f90.o
[ 21%] Building Fortran object CMakeFiles/mhm.dir/src/lib/mo_nml.f90.o
[ 22%] Building Fortran object CMakeFiles/mhm.dir/src/MPR/mo_mpr_read_config.f90.o
[ 23%] Building Fortran object CMakeFiles/mhm.dir/src/lib/mo_netcdf.f90.o
[ 24%] Building Fortran object CMakeFiles/mhm.dir/src/common/mo_common_restart.f90.o
[ 25%] Building Fortran object CMakeFiles/mhm.dir/src/MPR/mo_mpr_restart.f90.o
[ 26%] Building Fortran object CMakeFiles/mhm.dir/src/common/mo_grid.f90.o
[ 27%] Building Fortran object CMakeFiles/mhm.dir/src/lib/mo_orderpack.f90.o
[ 28%] Building Fortran object CMakeFiles/mhm.dir/src/common/mo_read_latlon.f90.o
[ 29%] Building Fortran object CMakeFiles/mhm.dir/src/MPR/mo_soil_database.f90.o
[ 30%] Building Fortran object CMakeFiles/mhm.dir/src/MPR/mo_mpr_startup.f90.o
[ 31%] Building Fortran object CMakeFiles/mhm.dir/src/lib/mo_ncread.f90.o
[ 32%] Building Fortran object CMakeFiles/mhm.dir/src/lib/mo_julian.f90.o
[ 33%] Building Fortran object CMakeFiles/mhm.dir/src/common/mo_read_forcing_nc.f90.o
[ 34%] Building Fortran object CMakeFiles/mhm.dir/src/MPR/mo_prepare_gridded_lai.f90.o
[ 35%] Building Fortran object CMakeFiles/mhm.dir/src/MPR/mo_read_lut.f90.o
[ 36%] Building Fortran object CMakeFiles/mhm.dir/src/common/mo_common_file.f90.o
[ 37%] Building Fortran object CMakeFiles/mhm.dir/src/common/mo_read_spatial_data.f90.o
[ 38%] Building Fortran object CMakeFiles/mhm.dir/src/common/mo_common_read_data.f90.o
[ 39%] Building Fortran object CMakeFiles/mhm.dir/src/MPR/mo_read_wrapper.f90.o
[ 39%] Building Fortran object CMakeFiles/mhm.dir/src/MPR/mpr_driver.f90.o
[ 40%] Building Fortran object CMakeFiles/mhm.dir/src/common/mo_common_read_config.f90.o
[ 41%] Building Fortran object CMakeFiles/mhm.dir/src/common/mo_read_timeseries.f90.o
[ 42%] Building Fortran object CMakeFiles/mhm.dir/src/common/mo_template.f90.o
[ 43%] Building Fortran object CMakeFiles/mhm.dir/src/common_mHM_mRM/mo_common_mHM_mRM_file.f90.o
[ 44%] Building Fortran object CMakeFiles/mhm.dir/src/common_mHM_mRM/mo_common_mHM_mRM_variables.f90.o
[ 45%] Building Fortran object CMakeFiles/mhm.dir/src/common_mHM_mRM/mo_common_mHM_mRM_read_config.f90.o
[ 45%] Building Fortran object CMakeFiles/mhm.dir/src/lib/mo_optimization_utils.f90.o
[ 46%] Building Fortran object CMakeFiles/mhm.dir/src/lib/mo_xor4096.f90.o
[ 46%] Building Fortran object CMakeFiles/mhm.dir/src/lib/mo_anneal.f90.o
[ 47%] Building Fortran object CMakeFiles/mhm.dir/src/lib/mo_dds.f90.o
[ 48%] Building Fortran object CMakeFiles/mhm.dir/src/lib/mo_moment.f90.o
[ 49%] Building Fortran object CMakeFiles/mhm.dir/src/lib/mo_ncwrite.f90.o
[ 50%] Building Fortran object CMakeFiles/mhm.dir/src/lib/mo_mcmc.f90.o
[ 51%] Building Fortran object CMakeFiles/mhm.dir/src/lib/mo_sce.f90.o
[ 52%] Building Fortran object CMakeFiles/mhm.dir/src/common_mHM_mRM/mo_optimization.f90.o
[ 53%] Building Fortran object CMakeFiles/mhm.dir/src/lib/mo_corr.f90.o
[ 54%] Building Fortran object CMakeFiles/mhm.dir/src/lib/mo_errormeasures.f90.o
[ 55%] Building Fortran object CMakeFiles/mhm.dir/src/lib/mo_linfit.f90.o
[ 56%] Building Fortran object CMakeFiles/mhm.dir/src/lib/mo_percentile.f90.o
[ 57%] Building Fortran object CMakeFiles/mhm.dir/src/lib/mo_mad.f90.o
[ 58%] Building Fortran object CMakeFiles/mhm.dir/src/lib/mo_spatialsimilarity.f90.o
[ 59%] Building Fortran object CMakeFiles/mhm.dir/src/lib/mo_standard_score.f90.o
[ 60%] Building Fortran object CMakeFiles/mhm.dir/src/lib/mo_temporal_aggregation.f90.o
[ 61%] Building Fortran object CMakeFiles/mhm.dir/src/mHM/mo_canopy_interc.f90.o
[ 62%] Building Fortran object CMakeFiles/mhm.dir/src/mHM/mo_file.f90.o
[ 63%] Building Fortran object CMakeFiles/mhm.dir/src/mHM/mo_mhm_constants.f90.o
[ 64%] Building Fortran object CMakeFiles/mhm.dir/src/mHM/mo_global_variables.f90.o
[ 65%] Building Fortran object CMakeFiles/mhm.dir/src/mHM/mo_init_states.f90.o
[ 66%] Building Fortran object CMakeFiles/mhm.dir/src/mHM/mo_spatial_agg_disagg_forcing.f90.o
[ 67%] Building Fortran object CMakeFiles/mhm.dir/src/mHM/mo_meteo_forcings.f90.o
[ 68%] Building Fortran object CMakeFiles/mhm.dir/src/mHM/mo_neutrons.f90.o
c[ 69%] Building Fortran object CMakeFiles/mhm.dir/src/mHM/mo_pet.f90.o
[ 70%] Building Fortran object CMakeFiles/mhm.dir/src/mHM/mo_runoff.f90.o
a[ 71%] Building Fortran object CMakeFiles/mhm.dir/src/mHM/mo_snow_accum_melt.f90.o
[ 72%] Building Fortran object CMakeFiles/mhm.dir/src/mHM/mo_soil_moisture.f90.o
[ 73%] Building Fortran object CMakeFiles/mhm.dir/src/mHM/mo_temporal_disagg_forcing.f90.o
m[ 73%] Building Fortran object CMakeFiles/mhm.dir/src/mHM/mo_mhm.f90.o
[ 73%] Building Fortran object CMakeFiles/mhm.dir/src/mRM/mo_mrm_constants.f90.o
[ 74%] Building Fortran object CMakeFiles/mhm.dir/src/mRM/mo_mrm_global_variables.f90.o
[ 75%] Building Fortran object CMakeFiles/mhm.dir/src/mRM/mo_mrm_file.f90.o
[ 76%] Building Fortran object CMakeFiles/mhm.dir/src/mRM/mo_mrm_net_startup.f90.o
[ 77%] Building Fortran object CMakeFiles/mhm.dir/src/mRM/mo_mrm_mpr.f90.o
[ 78%] Building Fortran object CMakeFiles/mhm.dir/src/mRM/mo_mrm_read_config.f90.o
[ 79%] Building Fortran object CMakeFiles/mhm.dir/src/mRM/mo_mrm_read_data.f90.o
[ 80%] Building Fortran object CMakeFiles/mhm.dir/src/mRM/mo_mrm_restart.f90.o
[ 81%] Building Fortran object CMakeFiles/mhm.dir/src/mRM/mo_mrm_river_head.f90.o
[ 82%] Building Fortran object CMakeFiles/mhm.dir/src/mRM/mo_mrm_init.f90.o
[ 83%] Building Fortran object CMakeFiles/mhm.dir/src/mRM/mo_mrm_routing.f90.o
[ 84%] Building Fortran object CMakeFiles/mhm.dir/src/mRM/mo_mrm_write_fluxes_states.f90.o
[ 85%] Building Fortran object CMakeFiles/mhm.dir/src/mRM/mo_mrm_write.f90.o
[ 86%] Building Fortran object CMakeFiles/mhm.dir/src/mHM/mo_restart.f90.o
[ 87%] Building Fortran object CMakeFiles/mhm.dir/src/mHM/mo_write_fluxes_states.f90.o
[ 88%] Building Fortran object CMakeFiles/mhm.dir/src/mHM/mo_mhm_eval.f90.o
[ 89%] Building Fortran object CMakeFiles/mhm.dir/src/mHM/mo_mhm_read_config.f90.o
[ 90%] Building Fortran object CMakeFiles/mhm.dir/src/mRM/mo_mrm_signatures.f90.o
[ 91%] Building Fortran object CMakeFiles/mhm.dir/src/mRM/mo_mrm_objective_function_runoff.f90.o
[ 92%] Building Fortran object CMakeFiles/mhm.dir/src/mHM/mo_objective_function.f90.o
[ 93%] Building Fortran object CMakeFiles/mhm.dir/src/mHM/mo_read_optional_data.f90.o
[ 94%] Building Fortran object CMakeFiles/mhm.dir/src/mHM/mo_set_netcdf_outputs.f90.o
[ 95%] Building Fortran object CMakeFiles/mhm.dir/src/mHM/mo_startup.f90.o
[ 96%] Building Fortran object CMakeFiles/mhm.dir/src/mHM/mo_write_ascii.f90.o
[ 97%] Building Fortran object CMakeFiles/mhm.dir/src/mRM/mo_mrm_eval.f90.o
[ 98%] Building Fortran object CMakeFiles/mhm.dir/src/mRM/mrm_driver.f90.o
[ 99%] Building Fortran object CMakeFiles/mhm.dir/src/mHM/mhm_driver.f90.o
[100%] Linking Fortran executable mhm
/usr/bin/ld: unrecognized option '-Bsymbolic-functions;-Wl'
/usr/bin/ld: use the --help option for usage information
collect2: error: ld returned 1 exit status
make[2]: *** [CMakeFiles/mhm.dir/build.make:1649: mhm] Error 1
make[1]: *** [CMakeFiles/Makefile2:76: CMakeFiles/mhm.dir/all] Error 2
make: *** [Makefile:84: all] Error 2
```
For tag 5.10
```
root@09a3ccc82a3d:/mhm/build# rm -rf *
root@09a3ccc82a3d:/mhm/build# cd ..
root@09a3ccc82a3d:/mhm# git checkout 5.10
Previous HEAD position was b7181fe Update README.md
HEAD is now at 9ce0ec1 merge release into master
root@09a3ccc82a3d:/mhm# cd build/
root@09a3ccc82a3d:/mhm/build# cmake ..
-- The Fortran compiler identification is GNU 9.3.0
-- Check for working Fortran compiler: /usr/bin/f95
-- Check for working Fortran compiler: /usr/bin/f95 -- works
-- Detecting Fortran compiler ABI info
-- Detecting Fortran compiler ABI info - done
-- Checking whether /usr/bin/f95 supports Fortran 90
-- Checking whether /usr/bin/f95 supports Fortran 90 -- yes
-- build INDEPENDENT of module system OFF
-- search in additional directory for netCDF
-- found /usr/bin/nf-config
-- netcdff includes /usr/include
-- netcdff netcdf link flags -I/usr/include
-- netcdff netcdf library link flags -L/usr/lib/x86_64-linux-gnu -lnetcdff -Wl,-Bsymbolic-functions -Wl,-z,relro -Wl,-z,now -lnetcdf -lnetcdf -ldl -lm
-- found /usr/lib/x86_64-linux-gnu/libnetcdff.so
-- found /usr/lib/x86_64-linux-gnu/libnetcdf.so
-- found /usr/lib/x86_64-linux-gnu/libnetcdf.so
-- found /usr/lib/x86_64-linux-gnu/libdl.so
-- found /usr/lib/x86_64-linux-gnu/libm.so
-- found netcdf libraries /usr/lib/x86_64-linux-gnu/libnetcdff.so;/usr/lib/x86_64-linux-gnu/libnetcdf.so;/usr/lib/x86_64-linux-gnu/libnetcdf.so;/usr/lib/x86_64-linux-gnu/libdl.so;/usr/lib/x86_64-linux-gnu/libm.so
-- found netcdf other flags -Wl,-Bsymbolic-functions;-Wl,-z,relro;-Wl,-z,now
-- Performing Test CPP_FLAG
-- Performing Test CPP_FLAG - Success
-- the following debug flags will be used: -g -pedantic-errors -Wall -W -O -g -Wno-maybe-uninitialized
-- Configuring done
-- Generating done
-- Build files have been written to: /mhm/build
root@09a3ccc82a3d:/mhm/build# make
Scanning dependencies of target mhm
[ 1%] Building Fortran object CMakeFiles/mhm.dir/src/lib/mo_kind.f90.o
[ 2%] Building Fortran object CMakeFiles/mhm.dir/src/MPR/mo_mpr_constants.f90.o
[ 4%] Building Fortran object CMakeFiles/mhm.dir/src/lib/mo_constants.f90.o
[ 5%] Building Fortran object CMakeFiles/mhm.dir/src/lib/mo_message.f90.o
[ 6%] Building Fortran object CMakeFiles/mhm.dir/src/MPR/mo_mpr_global_variables.f90.o
/mhm/src/MPR/mo_mpr_global_variables.f90:17:6:
17 | use mo_common_variables, only : period
| 1
Fatal Error: Cannot open module file 'mo_common_variables.mod' for reading at (1): No such file or directory
compilation terminated.
make[2]: *** [CMakeFiles/mhm.dir/build.make:102: CMakeFiles/mhm.dir/src/MPR/mo_mpr_global_variables.f90.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:76: CMakeFiles/mhm.dir/all] Error 2
make: *** [Makefile:84: all] Error 2
```
The current HEAD of `develop` build successfully.
On my local machine (Manjaro), the tag 5.10_fixed and head of develop build successfully, but not 5.10, that fails with the same error as on Ubuntu.5.11Sebastian MüllerSebastian Müllerhttps://git.ufz.de/mhm/mhm/-/issues/155[RELEASE] 5.11 checklist2021-02-03T11:47:28+01:00Sebastian Müller[RELEASE] 5.11 checklist- **Release notes**
- [x] notes about River temperature module !37
- [x] notes about new SM process !43
- **Clean-ups**
- [x] remove `testingInstructions`
- [x] remove `mRM` standalone specific files (not working as standalone...- **Release notes**
- [x] notes about River temperature module !37
- [x] notes about new SM process !43
- **Clean-ups**
- [x] remove `testingInstructions`
- [x] remove `mRM` standalone specific files (not working as standalone anymore)
- [x] remove Makefile and related folders (new features not implemented there [cpp directives etc.])
- [x] remove `bash` folder
- **Documentation**
- [x] set `tocdepth` to `1` in `header_doxygen.tex`
- [x] proof reading of documentation pages (@thober, @lese)
- [x] cleanup `doc` folder
- [x] move `INSTALL.md` and other additional `*.md` files there
- [x] add intel-2020 workflow to `INSTALL.md`
- **Release Procedure**
- [x] create `release_5.11.0` branch from `develop` at point of feature stop
- [x] provide a `5.11.0-rc1` release candidate from this branch as pre-release to check release process
- [x] when ready update `version.txt` and `version_date.txt`
- [x] merge into `master`
- [x] make release `5.11.0` from `master`
- [x] merge updates made during release back to develop
- [x] set `version.txt` to `5.11.1-dev0`5.11Sebastian MüllerSebastian Müllerhttps://git.ufz.de/mhm/mhm/-/issues/152Add iomkl/2020a workflow to eve load-scripts and CI2020-09-24T15:11:21+02:00Sebastian MüllerAdd iomkl/2020a workflow to eve load-scripts and CIIOMKL 2020a comes with the following settings:
- Intel C Compiler v2020.1
- Intel Fortran Compiler v2020.1
- OpenMPI v4.0.3
- Intel MKL v2020.1IOMKL 2020a comes with the following settings:
- Intel C Compiler v2020.1
- Intel Fortran Compiler v2020.1
- OpenMPI v4.0.3
- Intel MKL v2020.15.11Sebastian MüllerSebastian Müllerhttps://git.ufz.de/mhm/mhm/-/issues/151module loads under easybuild in INSTALL.md2020-10-05T13:48:25+02:00Friedrich Boeingmodule loads under easybuild in INSTALL.mdHello,
The INSTALL.md could be updated by directing to the moduleloadscripts under the different compilers with easybuild.
The solution for loading intel modules `module purge
ml uge/8.5.5-2 Java/1.8.0_202 grid-engine-tools/0.8.3-3-g93...Hello,
The INSTALL.md could be updated by directing to the moduleloadscripts under the different compilers with easybuild.
The solution for loading intel modules `module purge
ml uge/8.5.5-2 Java/1.8.0_202 grid-engine-tools/0.8.3-3-g93f1efa icc/2018.3.222-GCC-7.3.0-2.30 ifort/2018.3.222-GCC-7.3.0-2.30 iccifort/2018.3.222-GCC-7.3.0-2.30
`
currently proposed in INSTALL.md is not up to date as still old modules are used there, which would crash in Nov 2020 when all old modules are deleted (according to Tom Strempel).
Best regards,
Friedrich5.11Sebastian MüllerSebastian Müllerhttps://git.ufz.de/mhm/mhm/-/issues/147fate of MHM2MRM definition2020-10-08T12:03:47+02:00Robert Schweppefate of MHM2MRM definitionCurrently, there is this line in the top-level `CMakeLists.txt`:
```
cpp_definitions("-DMRM2MHM" "CMAKE_MRM2MHM" "ON" "If set to ON the model runs with mRM")
```
so that we be default compile mHM with mRM. If one would turn it off, ther...Currently, there is this line in the top-level `CMakeLists.txt`:
```
cpp_definitions("-DMRM2MHM" "CMAKE_MRM2MHM" "ON" "If set to ON the model runs with mRM")
```
so that we be default compile mHM with mRM. If one would turn it off, there will be errors, e.g:
```
Error: Symbol ‘kge_q’ at (1) has no IMPLICIT type; did you mean ‘kge_et’?
/Users/ottor/nc/Home/local_libs/fortran/mhm_mpr/src/mHM/mo_objective_function.f90:854:63:
854 | call init_indexarray_for_opti_data(domainMeta, 1, nQDomains, opti_domain_indices_Q)
| 1
Error: Symbol ‘nqdomains’ at (1) has no IMPLICIT type; did you mean ‘netdomains’?
```
because `nQDomains` is defined within the `#def MHM2MRM` block but also called outside it.
What is the policy on the MHM2MRM definition (@muellese, @thober)?
- keep it, then we should also test it and fix it (maybe @kaluza?)!
- drop it, then we can get rid of it altogether!5.11Sebastian MüllerSebastian Müller