Skip to content

BE rankings  #144

@BruceEdmonds

Description

@BruceEdmonds
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

No type

Projects

Status

Done

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions