mHM issueshttps://git.ufz.de/mhm/mhm/-/issues2022-04-28T15:25:02+02:00https://git.ufz.de/mhm/mhm/-/issues/216Backporting to v52022-04-28T15:25:02+02:00Sebastian MüllerBackporting to v5Backport features from `v6_develop`:
- command line interface
- cmake structure
- interfaces
- driver refactor
- run interfaces
- mhm_eval refactorBackport features from `v6_develop`:
- command line interface
- cmake structure
- interfaces
- driver refactor
- run interfaces
- mhm_eval refactorv5.12Sebastian MüllerSebastian Müllerhttps://git.ufz.de/mhm/mhm/-/issues/221Refactor: update mo_optimization_utils and mo_optimization_types in FORCES to...2022-04-28T15:20:26+02:00Sebastian MüllerRefactor: update mo_optimization_utils and mo_optimization_types in FORCES to be able to output BFIThese two modules (mo_optimization_utils and mo_optimization_types) are specific for mHM and need to be updated in FORCES.These two modules (mo_optimization_utils and mo_optimization_types) are specific for mHM and need to be updated in FORCES.v5.12Sebastian 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/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/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/140Hacky output dirs in test cases2020-11-30T08:58:34+01:00Sebastian MüllerHacky output dirs in test casesMost output directories for the test-cases are given with sth like `output_b1/b1_`.
But this is just a hack to prepend a prefix `b1_` to the output files.
When there will be checks for folders with automatically creation in the future, t...Most output directories for the test-cases are given with sth like `output_b1/b1_`.
But this is just a hack to prepend a prefix `b1_` to the output files.
When there will be checks for folders with automatically creation in the future, this would create two folders `output_b1/b1_/` with the output files in `b1_/`.
This is related to !415.11Sebastian MüllerSebastian Müller