DHI.Mike1D.ResultDataAccess Namespace

The Ascii1 bridge only stores reach data. All other data items are ignored.

The Ascii2 bridge only stores reach data. All other data items are ignored.

At most BufferSize time steps are stored in the result data object, hence if reading more than BufferSize number of time steps, the first read time step are removed again (based on reading, not on access).

The Dfs0 bridge only stores reach data. All other data items are ignored.

The Dfs0 bridge also supports reading an arbitrary dfs0 file data into the GlobalData set, adding support for dfs0 in the ResultDiff tool and GUI.

After connecting to the file, use the GetNextBlockType to quiery the block type, and then any of the ReadBlock methods or the SkipBlock to read/skip the next block. At end-of-file, GetNextBlockType returns EndOfFile.

The bridge can also handle other type of MOUSE result files that has the same structure as PRF file. Some of these PRF-like files are missing the full network definition, and if loaded as a stand-alone file, network is not complete. To get complete network, data must be added to an existing "primary" file, by merging in the data items. Different types of MOUSE results that are supported, are listed below:

• PRF: HD primary result output.
• PRF: HD result selection output. Must be added to primary PRF file
• XRF: HD additional output. Must be added to primary PRF file
• TRF: AD data. Should be added to primary PRF file, can load standalone with some definitions missing

When TimeValueGetter(Int32) is called, a TimeDataValueGetter is returned.

The Res1DNetworkDataSetWrapper provides temporal and spatial interpolation of data from a IResultData.

This class supports reading files from a .NET stream.

By default the following bridges are available:

• res1d
• dfs0 - only write support
• res11 - only read support

Class that contains a number of resultdata files. In case of more than one component needing access to the same result data file, it should only be opened once (performance/ressource issues). Hence, each component using a result data file should ask this buffer for the file and if it already exist in the buffer, the existing file will be used.

Each result data file is idenfitied by its full filepath name.

Required for certain functions related to COM interop.

This class has some buffer functionality such that results for the same inputs are returned immediately, without a need for searching.

If data is read using a lazy reader, this can incur a severe performance hit. In that case, the bridge must implement the unit conversion.

The SWMM5 Interface File contains outlet node flows.

The asRR argument to the constructor flags if data is stored as catchment TotalRunOff or node DischargeOutflow.

The "usual" integration in MIKE 1D is to convert the flow to runoff, and attach to MIKE 1D as catchment runoff file. There can be issues with the catchment connections and these must be regenerated.

To integrate node outflow to MIKE 1D, we probably need to introduce a new type of boundary (Runoff Node Inflow), which assigns directly to the node matching the Id.

There is currently not that much error reporting.

It stores an array of element values for each time step.

The ResultDataTimeInterpolator can be used by several instances of this class, in case temporal interpolation is required by more than one data item at the same times.

It stores an array of element values for each time step.

For each element it stores a list of time steps.

In the CHANNEL descripter part information is stored about each specific data series in the data part of the file. In the ITEM descripter part there could as an example be one record describing "water level in nodes". In the CHANNEL description part there must be one record for each node. The record can hold individual information about the node shuch as top and bottom level.

Additional information about each CHANNEL may be placed in a number of extra records just after the CHANNEL descripter record.

ONE channel descriptor record must exist for each channel.

CHANNEL descripter records MUST appear in the same order as the data they represent appears in the logical data record.

The ITEM descripter part contains one ITEM descripter record for each type of data channel. Examples of ITEMs are "water level" and "flow". If data channels with values for water level as a funtion of time is to be devided into groups e.g. "water level in nodes" and "water level in pipes" then there must exist an ITEM descripter record for each of the groups.

Each item descripter record may represent several data channels of the described ITEM.

In this part of the file no extra records are allowed. Note in particular that ITEM descripter records for data channels with time values must be defined too

ONE item descirptor record for each type of data channel.

No extra records allowed in this part

The TIME descripter part must start with one and only one TIME descripter record. This record contains information about the type of time data in the file. The type of time data ranges from information about an offset time and a constant time step which applies for all data channels, to individual time data for each data value in each data channel.

The individual information is added in a number of extra records after the TIME descripter record. The number of extra records must be specified in the TIME descripter record in variable NR_XREC. If there are no extra records, NR_XREC is defined as zero.

For rectype 1 and 2, the following values are present DivReal[0] : Number of time steps/values in each data channel DivReal[1] : Time between first and last value, time span of file

For constant time steps, the time step size can be calculated by: double timestepSize = DivReal[1] / (DivReal[0]-1.0);

An IDataItem contains data for one quantity and for a number of time steps and elements. For each set of time data there is an array of data element values.

Depending on the type of data in the file, this can be cast to a similar IRes1DItemDataT and the Data can be cast to its raw array data type.

This interface is never implemented directly.

Required for certain functions related to COM interop.

Special kind of read functionality can be required in different scenaries. Examples of read functionality include lazy reading (read only when required), time-filtered reading etc. The data reader implements this special read functionality for the IResultRandomReadBridge bridges.

Provided for COM interop.

The Save method is used for storing the entire content of the result data object to persistant storage. When Save is called, the bridge should initialize and open the persistant storage, write data to the storage and finalise and close the storage.

The methods Prepare(IDiagnostics), Flush(Boolean) and Finish are used for storing data from the result data into persistent storage during a simulation.

The Prepare(IDiagnostics) is called during the prepare phase of the simulation, where all static data is available. The method must initialise the storage, open it for writing and write any required static data (not time dependent data) to the storage.

The Flush(Boolean) method is called regurlarly during the simulation, depending on the SecondsBetweenFileFlush parameter. There can be data for more than one time step in the result data object. The method must store all data present in the result data object. After the flush method, the current data in the result data object is removed. A final call to flush is issued when the simulation is done.

The Finish method will be called when the simulation is done and after the last flush call. It must finalize and close down the persistant storage.

It has methods for handling as well single valued items (one element) and vector items with several elements.

Example