Summary

Explain typical components which need to be connected in a generic way (not OpenMI-specific) and data which should be connected.
Explain typical scenario with all steps required to run all these components together.
Describe data flows data structures involved at configuration and run-time.

A US-customer asks for a DelftFEWS application, operating in real-time, where his own data feeds are connected to FEWS. FEWS has two physical computation servers available to run three different OpenMI compliant river-catchment models. One of them is HEC-RAS without error correction, the oether one is Mike11 with error correction and data assimilation. FEWS wants to feed and retrieve time series in one go. Results should be provided at same time interval as the data being fed.

Issues:

  • ability to feed timeseries in one go and to retrieve time series in one go, without the need to worry how the models run 9only once or seevral times)
  • ability to perserve a persistent state and restart from this perssitent state (if needed on another machine).
  • ability to set time horizon and time of forecast

How to address in Version 1

_Describe

how you'd approach above mentioned use case in terms of OpenMI 1.0. Example source code can be listed using {code} macro._

Drawbacks

List all possible problems that you may expect in version 1.x of OpenMI.

How to address in Version 2

Present ideas in any form how you'd expect it to work in the OpenMI 2.0

  • No labels