Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mapping of internal model variables and parameters to standard names #518

Draft
wants to merge 18 commits into
base: master
Choose a base branch
from

Conversation

vers-w
Copy link
Collaborator

@vers-w vers-w commented Dec 10, 2024

Issue addressed

Fixes #481

  • model type sbm: change model parameters, states, and output variables (sub-selection) to standard names.
  • model typesbm_gwf: change model parameters, states, and output variables (sub-selection) to standard names.
  • model type sediment: change model parameters, states, and output variables (sub-selection) to standard names.
  • update/refactor check of state variables.
  • possibly refactor hydrological forcing in model type sediment, see also Mapping of internal model variables and parameters to standard names #518 (comment).
  • check list model variables allowed to exchange (standard_name_map).
  • check units sediment model, not always clear from code/metadata/docs as the unit is also part of the standard name (quantity).
  • reduce allocations (increased compared to base branch).

@SouthEndMusic
Copy link
Contributor

@vers-w I see you got rid of the nested names with periods in your TOML headers, but I make use of this structure in #519. I know I just started working on this without discussing with you, so let me know what your thoughts are (:

@JoostBuitink
Copy link
Contributor

@vers-w I see you got rid of the nested names with periods in your TOML headers, but I make use of this structure in #519. I know I just started working on this without discussing with you, so let me know what your thoughts are (:

Just to jump in this discussion here: we indeed decided to reorganize the toml file, so perhaps better to wait with #519 to prevent double work ;) ).

Rename these parameters to standard names.
 Additionally, made a start with standard name mapping (external standard name => internal model name). It makes use of `Wflow.param` functionality as much as possible, allowing to write any model output variable with the former TOML keys.
to standard names using `model_boundary_condition` (e.g. CSDMS uses `model_grid_ edge`) as objects.
Use lenses from `Accessors` for mapping standard names and for input parameters (`ncread`). Change parameter names of demand and groundwater to standard names. Writing any model output variable with the former TOML keys is possible (using `param`).
As the `sediment` model type makes use of hydrological forcing timeseries that are stored differently (internally) than the same timeseries used by model types `sbm` and `sbm_gwf`, the standard name mapping is done separately for the `sediment` model type (different dict). The same hydrological forcing data is used by the `SoilLoss` and `OverlandFlowSediment` components. This data is now only stored in the `SoilLoss` component and shared (memory) with the `OverlandFlowSediment` component.
@vers-w
Copy link
Collaborator Author

vers-w commented Dec 18, 2024

Hydrological forcing data in model type sediment is stored as part of the SoilLoss, OverlandFlowSediment and RiverSediment components, independently. In commit 8b38fb2 this data is now shared (in memory) between the SoilLoss and OverlandFlowSediment components. The same hydrological forcing time series are also present in the sbm and sbm_gwf model types stored at different internal model locations, compared to the sediment model. Because of this two different mappings (between the standard name and internal model name) are required.

Possible improvements:

  1. Store hydrological forcing data at one location in the sediment model (two mappings are required).
  2. Share the hydrological forcing data for SoilLoss and OverlandFlowSediment components (commit 8b38fb2, two mappings are required).
  3. Store the hydrological forcing data at the same internal model locations as the sbm and sbm_gwf models. One mapping is required and is likely most future-proof (e.g. run sbm and sediment in a combined wflow simulation).

Checking list of standard names (`input.state.variables`).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Mapping of internal model variables and parameters to standard names
3 participants