-
Notifications
You must be signed in to change notification settings - Fork 35
Description
Building a coupled model from process-oriented software components (models or model elements)
-- advanced, challenging in general
Building “system of systems” models by assembling sub-models of particular systems (for example, a “lake system” model integrated with a “watershed system”)
-- advanced, highly challenging in general
Operating models/components in multiple different frameworks
-- advanced, challenging in general
Operating models and data inputs/outputs efficiently as part of a sequence of tasks (approach: use/encourage file formats that are both standardized and open)
-- intermediate, a matter of standardisation
Swapping input data sources (for example, comparing behavior of a model with two different satellite-based inputs of land cover, as opposed to having the model hard-wired to one particular source)
-- advanced in general, challenging in general
Controlling parameter values and behavior without recompiling
-- intermediate for some kinds of model, possible, takes some care in design
Operating a model on multiple platforms
-- intermediate -- should be standard for programming frameworks these days (but hard if your framework is limited to one environment) -- should be aimed at the framework level rather than individual model level
Retrieving information about a model’s current state (including state variables) (implementation question: direct memory exchange vs. file-based exchange vs. web API)
-- intermediate but challenging to add into all programming frameworks
Pausing and continuing model execution
-- intermediate possible in frameworks
Adjusting model variables and/or control parameters during a run (for example, to support data assimilation)
-- intermediate possible if frameworks make this possible
Computing derivatives where applicable, to facilitate operations such as sensitivity analysis, optimization, and inference (note: different views among participants about whether this should be included in a standard, a “best practice” guideline, or not at all)
-- intermediate - intermediate results should be somehow available
Metadata and documentation related to interoperability
Clarity and precision in definitions of parameters and variables (ontology)
Data items to include in metadata: scale (space and time), typical run time, limits (e.g., range of calibration data)
-- Minimal, generic, not technical
Metadata
Metadata
Assignees
Labels
Type
Projects
Status