...
Priority | Data Type | Comment |
1 | Time Series | sufficient to cover most modules used in flood forecasting systems, including e.g. Mike-11 and NAM |
1 (a) | Time series of grid data | additionaly required for modules with 2D I/O formats (e.g inundation codes) |
2 | Parameters | Module parameters may be passed where the module allows calibration through the NFFS calibration facilities |
2 (a) | Longitudinal profile data | For hydrodynamic modules longitudinal data types may be passed - not a strict requirement. |
3 | Static data (cross sections, branches, etc) | This data is not required for operational forecasting. In exceptional cases data such as on branches may be required (for display purposes), but this need not be passed through the adapter and can be configured as appropriate. |
| Anchor | ||||
|---|---|---|---|---|
|
| Anchor | ||||
|---|---|---|---|---|
|
...
OpenMI developments be used in the module adapter? If so, will appropriate tools be provided?
Unfortunately, the OpenMI standard is not (yet) strict enough to provide a 100%
guarantee that any OpenMI modelcomponent can work within a FEWS forecasting
environment. However, with an additional agreement between the OpenMI component
supplier and FEWS this can be achieved. In a few sentences, I will try to
explain this in more detail
Within a forecasting system, model states are updated on a regular basis, such
that you run a new forecast with a recent 'warm' state. Within FEWS, models
(model adapters) have to be able to dump their state to file, which is handed
back to FEWS. When conducting a new forecast, this state is then put back to
the model to be used for its run. Crucial aspect is however, that this forecast
may be conducted on a different machine. Hence a persistent state needs to be
handled.
Within the OpenMI, a callable interface has been defined which asks a component
to keep (save) or restore its current form the General Adapter does not use the HarmonIT (OpenMI) module interchange facilities. The DELFT-FEWS application will in the near future be extended with an OpenMI compatible adapter, but this is as yet not considered an NFFS requirementstate. Unfortunately, the current version of
OpenMI leaves it up to the component if it keeps the state in memory or saves
it persistently on disk. In other words, OpenMI by itself does not guarantee
that a state can be persistently handled.
To apply an OpenMI modelcomponent within a FEWS forecasting system, an
additional agreement is needed in which the result of a
'OpenMI.KeepCurrentState'-call is a persistent file, with the file reference
available to be handed back to FEWS. Furthermore, an agreement is needed to
exchange relevant logging/diagnostics as OpenMi is also not very strong on this
aspect.
To conclude: currently, FEWS can exchange data with OpenMI components on a
scalar (point) data set. Grid support has not been implemented yet. Although we
do have a preferred and simple data exchange format for state exchange, this
has not been implemented yet, since we haven't had a real case where this
support is required.
A outstanding change request for persistent state management is recognized and
accepted by the OpenMI Association Technical Committee as a required change for
version 2 of the OpenMI Standard..
| Anchor | ||||
|---|---|---|---|---|
|
| Anchor | ||||
|---|---|---|---|---|
|
...