The interface describes an on-line or operational system. However the XML templates and data types described apply to off-line modelling. Is it the intention for the DELFT-FEWS databases to hold data such as cross-sections, river channels etc. which are used to develop the model from scratch?

The interface is indeed intended to be operated an on-line operational system. It's prime communication with external forecasting modules is through dynamic data such as time series, model states and diagnostics (see below). The published interface formats have been defined to cover a wider range of data types, but these need not be used in all cases - i.e. there is no requirement to allow communication of all data types. Indeed there is currently no module that caters for the full range of formats. Although the EA is to decide to what extent data should be passed, the practical approach followed with e.g. ISIS and the CEH modules is to pass only time series, module states and diagnostics information.
In exchanging data between a module and NFFS, a prioritisation of data types can be identified.

Does FEWS Support OpenMI? (http://www.openmi.org/)

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, we 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 state. 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...

A major part of the document consists of XML templates for a wide range of data types. It is our understanding that relatively few of these are used in practice and that these are simply made available to ensure a general system.

This assumption is correct - see also G.1.1

On what platform is the system running (Windows, Linux or other)?

The DELFT-FEWS system has been developed in JAVA and is platform independent. However, in the configuration of NFFS, all runs of forecasting modules are executed on dedicated servers. Presently, we have only used this on Windows and Linux systems.

What is the module adapter (script, bat-file, win32dll, win exe, or other)? There are no technology specifications for the adapter.

There is no specific requirement for the module adapter. The only requirement is that it can communicate through the XML file formats. The use of standard methods for reading and writing XML files, based on the schemas provided is highly recommended. This not only reduces implementation efforts but also guarantees compatibility. The general adapter currently allows the external module to be run either as an executable, or as a Java method. A minor extension will allow running of DLL's. Batch files are not recommended as the General Adapters monitors return codes from the external module. These are not always correctly passed in Batch files, and as such ungraceful failure of a module is not easily identified.

How does the module adapter and the general adapter communicate (win32 API, files, or other)?

The general adapter initiates the executable, Java method (or DLL) through the system/Java calls. Arguments may be passed when required, though these must be static. The general adapter may also be used to set environment variables for the module where required.

The module normally runs in a dedicated directory (tree). A working directory can be configured to act as the root of the module run.

Figure 1 on page 4-1 indicates that all communication between the NFFS system and the system that is delivered by a model supplier goes through the Module adapter. I this a correct assumption and can everything under the blue line be considered as a black box ?. If so, is it possible to describe the specific requirements to such a black box ?

This is correct. The most specific requirement is that the module must not have any manual interaction. This would preclude running the module in a distributed system.

Are there any specific requirements for the data formats used in communication between the module and the module adapter (e.e. binary or ASCII?)

This is a sole choice of the module adapter. There is a slight preference to ASCII formats as this eases debugging. However, if this has implications as to module performance (additional pre-processing requirements) then the binary format is advocated.

Could we ask for further clarification to distinguish between module states and module results and under what circumstances these are stored in the NFFS databases?

The general adapter has full state management facilities. This means the module is provided with an initial state for the start of run. The module should also provide a resulting state at the end of run, or at an intermediate time. When required this resulting state is administered and stored in the NFFS database for later use.
It is important to note that the actual module state file is handled blindly - ie it is not interpreted. NFFS takes the state and time-stamps it for storage in the database. NFFS will not change the content of the state, though renaming of files/directories on import/export is possible.
For cold start runs a default state is provided to the module.
Module results are generally passed back through the Published Interface XML format and stored in the database. Obviously only the required locations need be passed.

What tools are provided within the system for derived data such as catchment mean rainfall, catchment evaporation, etc.?

DELFT-FEWS provides a full set of generic tools for these derived data, including all of the above. Generally DELFT-FEWS is configured to pre-process all data and provide the module directly with required inputs. The module need not do any additional processing.

What tools are provided for updating/data assimilation and how are these integrated into the module structure shown in figure 1?

DELFT-FEWS provides an internal ARMA error modelling tool. This is module independent and is run in sequence to the module when required.

What adapter mechanisms will be used for sequences of modules?

Sequences of modules and data handling functions are run in sequence by so-called workflows. This means that a workflow may be configured to first run a rainfall-runoff model (e.g. NAM, PDM) through the General adapter, then run an error correction routine to the output and subsequently run a hydrodynamic module (e.g. ISIS, MIKE11, SOBEK)

What are the requirement for migrating from an stand-alone system to an on-line system for the module adapter

There is no difference to the module if it is on or off line. This layer is managed by DELFT-FEWS.

Diagnostics: must all diagnostics from a model run be reported in one diagnostics-file or does the interface allow for multiple files (this could be relevant if the model adapter executes a sequence of sub-modules during a model-run)?

In its current form the diagnostics file to each external module run should be one file. The general adapter does, however, allow for executing a sequence of modules, with a diagnostics file for each.

Diagnostics: can any information be passed back - or is it limited to the status type messages with one line of text per status code?

The diagnostics passed back should be relatively limited - there is no strict requirement on the length of the message, but to the point messaging is advocated. The message should provide the level of knowledge to the operational forecaster to monitor the system. Different levels of messages should be used, with information useful in debugging being labelled appropriately.
For more detailed messaging - native module formats can be used, but this is only for specialist analysis. It should be noted that when a module fails, a zipped dump files is made of all module files and I/O. This is set aside for later, detailed, analysis.

Execution: since all model runs of a particular setup seems to be running in the same fixed location (URI) it is the responsibility of the run-time adapter to clean up used files after a model run. Will DELFT-FEWS overwrite existing files during subsequent runs (e.g. the input TS XML files)? This would reduce the cleaning up to files, which are not overwritten by the model tool itself.

It is good practice for a module to clean up redundant files after use. The general adapter does allow configuration of a purge activity either before the module run or after the module run (or both).

Dynamic files: who decides the location of the dynamic files which are created by the general adapter? Both the model adapter and the general adapter must know the location (one to write and the other to read them), but who determines the structure in which they are created?

In the general adapter configuration (XML) the location of the PI-XML files to pass to the module is given, as well as the location where PI-XML files are expected. The location of diagnostics files and work directories can also be configured. The structure is dictated by the Published Interface. All files passed to the module will be in the same directory and all files passed back are expected in the same directory (with the exception of the diagnostics file).

Dynamic files: Can/will DELFT-FEWS pass other dynamic module parameters? Especially, how will DELFT-FEWS pass information of simulation period - start date/time and end date/time and optionally time-of-forecast date/time for the model module to use?

To ensure simplicity, the length of the module run is dictated by the length of the time series passed. When a distinction is to be made between forecast and historic run, these will be passed as separate time series. The module adapter should identify run times from these.

Model states: It is assumed that DELFT-FEWS decides which of the available states (default, scenario) will be supplied to. How will the model adapter know which type of model state to return?

Indeed. The module state returned will be administered by DELFT-FEWS. Depending on the status of the run it will be administered as a state to be used in ensuing forecasts, or disregarded.

We presume that the adapter will run at the time of forecast, and therefore the general adapter will provide data on request for specified intervals. Correct?

Indeed. The General Adapter is configured to provide the module with the required data. Data may be provided at equidistant or non-equidistant intervals.

Is it correct that one module run can supply one set of state information as output, i.e. data for one timestamp (and time step) only?

Yes. A state represents the state of a module at a single point in time.

Please advise on what quality checks are made for observations used for updating that can be used to switch off updating if the updating observations are missing or of poor quality.

The following quality checks can be made within DELFT-FEWS (when configured by the user)

• Detection of outliers (data flagged unreliable)
• Check of exceedance of hard limits (data flagged unreliable)
• Check of exceedance of soft limits (data flagged doubtful)
• Rate of change check. When a rate of change exceeds a pre-set value, data is flagged unreliable
• Same readings check: When data remains within a pre-set range for a configured period, data is flagged unreliable
• Temporary shift check. When a 'temporary shift' is detected, data is flagged unreliable

Can paths for files and directories include several levels of subdirectories - or only one relative to the general paths?

Several levels are possible.