mHM issueshttps://git.ufz.de/mhm/mhm/-/issues2022-07-07T10:40:24+02:00https://git.ufz.de/mhm/mhm/-/issues/224Container for Namelist2022-07-07T10:40:24+02:00Sebastian MüllerContainer for NamelistIn order to be able to set configurations dynamically, it would be good to have a type representation for namelists.
There could be a abstract type implementation in FORCES to provide a template for namelists and routines to read or set...In order to be able to set configurations dynamically, it would be good to have a type representation for namelists.
There could be a abstract type implementation in FORCES to provide a template for namelists and routines to read or set values.
ATM we have the following namelists defined in mHM:
```
src/common/mo_common_read_config.F90:
108 ! namelist directories
109: namelist /project_description/ project_details, setup_description, simulation_type, &
110 Conventions, contact, mHM_details, history
111: namelist /directories_general/ dirConfigOut, dirCommonFiles, &
112 dir_Morpho, dir_LCover, &
115 ! namelist spatial & temporal resolution, optimization information
116: namelist /mainconfig/ iFlag_cordinate_sys, resolution_Hydrology, nDomains, L0Domain, write_restart, &
117 read_opt_domain_data
118 ! namelist process selection
119: namelist /processSelection/ processCase
120
121 ! namelist for land cover scenes
122: namelist/LCover/nLcoverScene, LCoverYearStart, LCoverYearEnd, LCoverfName
123
src/common_mHM_mRM/mo_common_mHM_mRM_read_config.f90:
86 ! namelist spatial & temporal resolution, otmization information
87: namelist /mainconfig_mhm_mrm/ timestep, resolution_Routing, optimize, &
88 optimize_restart, opti_method, opti_function, &
90 ! namelist for optimization settings
91: namelist /Optimization/ nIterations, seed, dds_r, sa_temp, sce_ngs, &
92 sce_npg, sce_nps, mcmc_opti, mcmc_error_params
93 ! namelist for time settings
94: namelist /time_periods/ warming_Days, eval_Per
95
src/mHM/mo_mhm_read_config.f90:
160 ! namelist directories
161: namelist /directories_mHM/ &
162 inputFormat_meteo_forcings, &
173 ! optional data used for optimization
174: namelist /optional_data/ &
175 dir_soil_moisture, &
184 ! namelist for pan evaporation
185: namelist /panEvapo/evap_coeff
186
187 ! namelist for night-day ratio of precipitation, referenceET and temperature
188: namelist /nightDayRatio/ read_meteo_weights, &
189 fnight_prec, fnight_pet, fnight_temp, fnight_ssrd, fnight_strd
190 ! name list regarding output
191: namelist /NLoutputResults/ &
192 output_deflate_level, &
src/MPR/mo_mpr_read_config.f90:
234 ! namelist directories
235: namelist /directories_MPR/ dir_gridded_LAI
236 ! namelist soil database
237: namelist /soildata/ iFlag_soilDB, tillageDepth, nSoilHorizons_mHM, soil_Depth
238 ! namelist for LAI related data
239: namelist /LAI_data_information/ inputFormat_gridded_LAI, timeStep_LAI_input
240 ! namelist for land cover scenes
241: namelist /LCover_MPR/ fracSealed_cityArea
242
243 ! namelist parameters
244: namelist /interception1/ canopyInterceptionFactor
245: namelist /snow1/snowTreshholdTemperature, degreeDayFactor_forest, degreeDayFactor_impervious, &
246 degreeDayFactor_pervious, increaseDegreeDayFactorByPrecip, maxDegreeDayFactor_forest, &
247 maxDegreeDayFactor_impervious, maxDegreeDayFactor_pervious
248: namelist /soilmoisture1/ orgMatterContent_forest, orgMatterContent_impervious, orgMatterContent_pervious, &
249 PTF_lower66_5_constant, PTF_lower66_5_clay, PTF_lower66_5_Db, PTF_higher66_5_constant, &
253 rootFractionCoefficient_pervious, infiltrationShapeFactor
254: namelist /soilmoisture2/ orgMatterContent_forest, orgMatterContent_impervious, orgMatterContent_pervious, &
255 PTF_lower66_5_constant, PTF_lower66_5_clay, PTF_lower66_5_Db, PTF_higher66_5_constant, &
259 rootFractionCoefficient_pervious, infiltrationShapeFactor, jarvis_sm_threshold_c1
260: namelist /soilmoisture3/ orgMatterContent_forest, orgMatterContent_impervious, orgMatterContent_pervious, &
261 PTF_lower66_5_constant, PTF_lower66_5_clay, PTF_lower66_5_Db, PTF_higher66_5_constant, &
266 rootFractionCoefficient_clay, FCmin_glob, FCdelta_glob, jarvis_sm_threshold_c1
267: namelist /soilmoisture4/ orgMatterContent_forest, orgMatterContent_impervious, orgMatterContent_pervious, &
268 PTF_lower66_5_constant, PTF_lower66_5_clay, PTF_lower66_5_Db, PTF_higher66_5_constant, &
273 rootFractionCoefficient_clay, FCmin_glob, FCdelta_glob
274: namelist /directRunoff1/ imperviousStorageCapacity
275 ! PET is input, LAI driven correction
276: namelist /PETminus1/ PET_a_forest, PET_a_impervious, PET_a_pervious, PET_b, PET_c
277 ! PET is input, aspect driven correction
278: namelist /PET0/ minCorrectionFactorPET, maxCorrectionFactorPET, aspectTresholdPET
279 ! Hargreaves-Samani
280: namelist /PET1/ minCorrectionFactorPET, maxCorrectionFactorPET, aspectTresholdPET, HargreavesSamaniCoeff
281 ! Priestely-Taylor
282: namelist /PET2/ PriestleyTaylorCoeff, PriestleyTaylorLAIcorr
283 ! Penman-Monteith
284: namelist /PET3/ canopyheigth_forest, canopyheigth_impervious, canopyheigth_pervious, displacementheight_coeff, &
285 roughnesslength_momentum_coeff, roughnesslength_heat_coeff, stomatal_resistance
286: namelist /interflow1/ interflowStorageCapacityFactor, interflowRecession_slope, fastInterflowRecession_forest, &
287 slowInterflowRecession_Ks, exponentSlowInterflow
288: namelist /percolation1/ rechargeCoefficient, rechargeFactor_karstic, gain_loss_GWreservoir_karstic
289: namelist /neutrons1/ Desilets_N0, COSMIC_N0, COSMIC_N1, COSMIC_N2, COSMIC_alpha0, COSMIC_alpha1, COSMIC_L30, COSMIC_L31
290 !
291: namelist /geoparameter/ GeoParam
292
src/mRM/mo_mrm_read_config.f90:
111 ! namelist spatial & temporal resolution, optmization information
112: namelist /mainconfig_mrm/ ALMA_convention, &
113 filenameTotalRunoff, varnameTotalRunoff, gw_coupling
114 ! namelist directories
115: namelist /directories_mRM/ dir_Gauges, dir_Total_Runoff, dir_Bankfull_Runoff
116: namelist /evaluation_gauges/ nGaugesTotal, NoGauges_domain, Gauge_id, gauge_filename
117 ! namelist for inflow gauges
118: namelist /inflow_gauges/ nInflowGaugesTotal, NoInflowGauges_domain, InflowGauge_id, &
119 InflowGauge_filename, InflowGauge_Headwater
120 ! name list regarding output
121: namelist /NLoutputResults/ &
122 output_deflate_level_mrm, &
458
459: namelist /routing1/ muskingumTravelTime_constant, muskingumTravelTime_riverLength, &
460 muskingumTravelTime_riverSlope, muskingumTravelTime_impervious, muskingumAttenuation_riverSlope
461: namelist /routing2/ streamflow_celerity
462: namelist /routing3/ slope_factor
463 !
src/mRM/mo_mrm_riv_temp_class.f90:
155 ! namelist for river temperature configuration
156: namelist /config_riv_temp/ &
157 albedo_water, &
```wishlist futureSebastian MüllerSebastian Müllerhttps://git.ufz.de/mhm/mhm/-/issues/215MPR: State and TODOs2022-01-13T17:14:07+01:00Sebastian MüllerMPR: State and TODOs# State:
- See diff of !90
- compiling and running
- check case not all working ATM
- case....
# TODOs
- one MPR instance per domain (https://git.ufz.de/chs/MPR/-/merge_requests/84)
- speed optimization (affected by above and https:/...# State:
- See diff of !90
- compiling and running
- check case not all working ATM
- case....
# TODOs
- one MPR instance per domain (https://git.ufz.de/chs/MPR/-/merge_requests/84)
- speed optimization (affected by above and https://git.ufz.de/chs/MPR/-/merge_requests/79)
- documentation of refactoring and changes
- update pfunit tests6.xSebastian MüllerSebastian Müllerhttps://git.ufz.de/mhm/mhm/-/issues/144consistent handling of units in mHM2022-04-28T16:07:04+02:00Robert Schweppeconsistent handling of units in mHMWe should have a clear documentation of which physical units are used internally. For example in the current develop in
`mo_snow_accum_melt.f90` in lines 96 there is
```
! Snow pack [m]
REAL(dp), INTENT(INOUT) :: snow_pack
```
a...We should have a clear documentation of which physical units are used internally. For example in the current develop in
`mo_snow_accum_melt.f90` in lines 96 there is
```
! Snow pack [m]
REAL(dp), INTENT(INOUT) :: snow_pack
```
and this variable is passed onto the writing in the netcdf files where in `mo_write_fluxes_states.f90` it says in lines 287
```
tmpvars(ii) = OutputVariable(&
nc, "snowpack", dtype, dims1, nCells, mask1, .true.)
call writeVariableAttributes(tmpvars(ii), "depth of snowpack", "mm")
```
So what is it then - `m` or `mm`?
It should be a starting point for implementing [CF Conventions](https://cfconventions.org/Data/cf-conventions/cf-conventions-1.8/cf-conventions.html) and [Udunits](https://www.unidata.ucar.edu/software/udunits/). Maybe it is also worth checking out an analysis tool that checks for errors in scientific Fortran Code [CamFort](https://github.com/camfort/camfort).wishlist futurehttps://git.ufz.de/mhm/mhm/-/issues/113[Enhancement] read meteo weights separately for each variable2020-08-31T17:08:25+02:00Sebastian Müller[Enhancement] read meteo weights separately for each variableAt the moment, you can only enable reading meteo weights for all meteo forcings jointly.
To deal with different availabilities of data, we should add switches to enable weights reading for each meteo forcing separately.At the moment, you can only enable reading meteo weights for all meteo forcings jointly.
To deal with different availabilities of data, we should add switches to enable weights reading for each meteo forcing separately.6.xSebastian MüllerSebastian Müllerhttps://git.ufz.de/mhm/mhm/-/issues/112[Enhancement] `global_parameters` class2022-04-28T15:59:34+02:00Sebastian Müller[Enhancement] `global_parameters` classAt the moment the global parameters are an array where all needed parameters are just appended.
This is prone to failure, since you always have to keep track of positions for the parameters of your desired process.
Proposal:
Create a `g...At the moment the global parameters are an array where all needed parameters are just appended.
This is prone to failure, since you always have to keep track of positions for the parameters of your desired process.
Proposal:
Create a `global_parameters` class, where every process can register the parameters, init-values and ranges used in optimization.
These registrations could than be accessed by registration IDs (for example).
The current behavior, to be represented as an array could be provided by a class-method.6.xSebastian MüllerSebastian Müllerhttps://git.ufz.de/mhm/mhm/-/issues/108consistent file handling in mhm.nml2020-08-31T17:08:29+02:00Stephan Thoberconsistent file handling in mhm.nmlWith merge request !34 , restart file names are handled more flexibly for the user. The same procedure should be applied to all other file names in mhm.nml.With merge request !34 , restart file names are handled more flexibly for the user. The same procedure should be applied to all other file names in mhm.nml.6.xSebastian MüllerSebastian Müllerhttps://git.ufz.de/mhm/mhm/-/issues/106driver refactoring and OOP2022-04-28T15:59:41+02:00Stephan Thoberdriver refactoring and OOPreorganize global data and methods according to classes for individual processes; adapt driver to new classes.
riv_temp serves as a template.reorganize global data and methods according to classes for individual processes; adapt driver to new classes.
riv_temp serves as a template.6.xSebastian MüllerSebastian Müllerhttps://git.ufz.de/mhm/mhm/-/issues/105move directories_mHM to directories_general as a meteo dir2020-12-01T09:20:42+01:00Sebastian Müllermove directories_mHM to directories_general as a meteo dirAll specified folders under `directories_mHM` in `mhm.nml` can be combined essentially in `directories_general` under a `dir_Meteo`.
https://git.ufz.de/mhm/mhm/-/blob/develop/mhm.nml#L272
Does somebody demand to be able to specify diff...All specified folders under `directories_mHM` in `mhm.nml` can be combined essentially in `directories_general` under a `dir_Meteo`.
https://git.ufz.de/mhm/mhm/-/blob/develop/mhm.nml#L272
Does somebody demand to be able to specify different folders for each entry in `directories_mHM`?
Otherwise we could get rid of that.6.xSebastian MüllerSebastian Müllerhttps://git.ufz.de/mhm/mhm/-/issues/104[Enhancement] Container for global variables (mHM, mRM)2022-04-28T15:27:45+02:00Sebastian Müller[Enhancement] Container for global variables (mHM, mRM)In order to be future-prove, we should think about organizing global variables in containers to pass them around.In order to be future-prove, we should think about organizing global variables in containers to pass them around.6.xhttps://git.ufz.de/mhm/mhm/-/issues/99move temporal_disagg_forcing2023-03-08T20:26:29+01:00Stephan Thobermove temporal_disagg_forcingtemporal_disagg_forcing is called in mo_mhm, but should be moved to mo_mhm_evaltemporal_disagg_forcing is called in mo_mhm, but should be moved to mo_mhm_evalwishlist futureSebastian MüllerSebastian Müllerhttps://git.ufz.de/mhm/mhm/-/issues/96mRM: mo_mrm_net_startup revision2020-12-01T09:24:36+01:00Stephan ThobermRM: mo_mrm_net_startup revisionmo_mrm_net_startup.f90 is outdated and needs substantial revision with regard to memory and run timemo_mrm_net_startup.f90 is outdated and needs substantial revision with regard to memory and run time6.xStephan ThoberStephan Thoberhttps://git.ufz.de/mhm/mhm/-/issues/72Rename parameter name for organic forest content2020-10-05T17:04:32+02:00Stephan ThoberRename parameter name for organic forest content6.xStephan ThoberStephan Thoberhttps://git.ufz.de/mhm/mhm/-/issues/48file unit handler2024-02-26T09:59:59+01:00Maren Kaluzafile unit handlerIf a program opens several files in different locations of the code choosing an unused file unit becomes complicated. The problem becomes even worse if there is MPI process specific output. In that case the rank needed to determine the f...If a program opens several files in different locations of the code choosing an unused file unit becomes complicated. The problem becomes even worse if there is MPI process specific output. In that case the rank needed to determine the file unit which can lead to conflicts in case of too many MPI processes.
An easy solution would be a file unit handler, a function that returns an unused file unit which is then written to a variable. Since fortran 08 there already is one that comes with fortran. Otherwise it would be a short subroutine.
If we decide to use such a subroutine it had to be used for every appearing new file unit since it only checks for file units which are already in use.wishlist futureSebastian MüllerSebastian Müller