MPR issueshttps://git.ufz.de/chs/MPR/-/issues2020-04-20T08:50:17+02:00https://git.ufz.de/chs/MPR/-/issues/49Rename variables and properties set in namelist2020-04-20T08:50:17+02:00Robert SchweppeRename variables and properties set in namelistIt is sometimes not intuitive, what certain variables or properties mean. This is especially true for variables exposed to the user through the namelist. For the upcoming 1.0 version:
Following proposed changes in type names:
- `Dimensi...It is sometimes not intuitive, what certain variables or properties mean. This is especially true for variables exposed to the user through the namelist. For the upcoming 1.0 version:
Following proposed changes in type names:
- `Dimension` -> `Coordinate`
- `DimAlias` -> `CoordinateGroups`
- all Dimension related procedures shall be checked to also contain the name coord
Following proposed changes in namelist variables:
- section `data_arrays` -> `dataarrays` (no underscores in other section names)
- section `mainconfig` -> `main`
- `dim_name_alias` -> `coordinate_group` (unsure about that)
- `names` -> `name` *
- `transfer_funcs` -> `transfer_func` *
- `from_parameters` -> `from_parameter_values` (to be more consistent with variable names in parameters section)
- `dim_names` -> `coord_name` *
- `dim_reference` -> `coord_cell_reference`
- `dim_files` -> `coord_from_file` *
- `dim_vector` -> `coord_from_values`
- `dim_bound` -> `coord_from_values_bound`
- `dim_start` -> `coord_from_range_start`
- `dim_step` -> `coord_from_range_step`
- `dim_count` -> `coord_from_range_count`
- `dim_attribute_names` -> `coord_attribute_names`
- `dim_attribute_values` -> `coord_attribute_values`
- `dim_proj_str` -> `coord_proj_string`
- `dim_sub_dims` -> `coord_sub_dims`
- `dim_units` -> `coord_unit` *
- `upscaler_names` -> `upscaler_name` *
/* singular as only one value need for each itemNext major releaseRobert SchweppeRobert Schweppehttps://git.ufz.de/chs/MPR/-/issues/29named global parameters2018-10-17T13:46:53+02:00Robert Schweppenamed global parametersWhen trying to achieve #28, we sometimes run in the case, that global_parameters occur in more than one transfer function (e.g. frac_sealed_city_area is applied on land_cover_fraction_sealed and land_cover_fraction_pervious. It is error ...When trying to achieve #28, we sometimes run in the case, that global_parameters occur in more than one transfer function (e.g. frac_sealed_city_area is applied on land_cover_fraction_sealed and land_cover_fraction_pervious. It is error prone to have them as different values in the global_parameter namelist. Thus, we must somehow link them.
One concept could be, that we support *named* global parameters. When defining transfer functions in a dynamic way, one could directly type the name of a parameter or constant that is required. When defining transfer functions in a static way (by name), the user must supply the names of the parameters in a similar way as the names of the data arrays. The parameters are first checked with a new namelist "constants", which resides in mpr.nml. If not found, they are checked for in "global_parameters", which resides in mpr_global_parameter.nml. If not found, they are parsed (assuming a real number).
This has the following advantages:
* it is much neater than #23
* it allows for real numbers to be put in dynamically parsed transfer functions (a number cannot be at the beginning of a function name in Fortran though, a workaround would be to enclose it in brackets, e.g. type `(5.0 * bar)` instead of `5.0 * bar` leading to the function name `bs_5_0_x1_be`)
* it keeps the namelist mpr_global_parameters.nml clean, so that it only contains parameters that are *true* parameters (e.g. created by an optimizer)
* it solves our issue... :)
To sum up, I propose an API change on the read_config, transfer_func initialization and the namelists:
In `mpr.nml`
```
&data_arrays
names(1) = "foo"
! the transfer function is dynamically parsed and pointed to
transfer_funcs(1) = "myconstant1 + myparam1 * bar"
from_data_arrays(1,1) = "bar"
names(2) = "foo2"
! the transfer function is static and pointed to
transfer_funcs(2) = "linear_1arg_intercept"
from_data_arrays(1,2) = "bar"
from_parameters(1:2,2) = "myconstant1", "myparam1"
! or also possible
! from_parameters(1:2,2) = "1.0", "-1.0"
/
&constants
! *this is new*
myconstant1 = -273.15
/
```
In `mpr_global_parameter.nml`
```
&global_parameters
! *new structure*
myparam1 = -1.0
/
```Robert SchweppeRobert Schweppehttps://git.ufz.de/chs/MPR/-/issues/3common parent class for both effective parameter and input field2018-07-25T00:59:44+02:00Robert Schweppecommon parent class for both effective parameter and input fieldA common parent class needs to be introduced both for effective parameter and input field (both need attributes ref counter, used_since, used_until, data, mask and mask_shape at least).
This information needs to be shared among both typ...A common parent class needs to be introduced both for effective parameter and input field (both need attributes ref counter, used_since, used_until, data, mask and mask_shape at least).
This information needs to be shared among both types in order to allow an effective_parameter also as input to a transfer_functionRobert SchweppeRobert Schweppe