Introduction

The main goal of this activity is to design and develop a framework which will enable to construct a user-friendly applications to work with different models.

...

• Define dictionary of all model-/modelling system-related terms.
• Define an architecture, provide components/packages diagram.
• Define concept of the Project, TasksTask, Models, Scenarios and WorkflowsModel, Data objects used to store Project and Models data.
• Define concept of data management classes like Quantity, Unit, TimeSeries, Grid or ElementSet...
• Design generic persistency/data access layer.
• Define concept of the models integration.
• Define concept of the GUI (Model-View-Controller, event-driven, plugin-based).

...

Typical structure of the modelling system would need at least some framework class library which will define all classes to work with different data. Such framework will also provide an IModelinterface. It will be required to implement that interface by any model which will need to be integrated into the system. Such an interface has to be designed to be as simple as possible and should not contain anything else than mapping of the model data from/to the model engine and providing control functions to run the model.

Core

Project

• A main working document of the user.
• Is a main repository mainly containing Data and Tasks (Models)Is always a starting point for a user in the system.
• Contains a set of data (measurements data, etc.) which may be used across the project.
• Contains a set of spatial data / maps.Contains a set of Scenarios defining some modelling tasks.

A typical project may look like:

Project1/
  Data/                 - any project can have any set of data which are used across the project
     DataFolder1/       -  the data can be orginized freely using folders
        time series1     - but at the same time they represent actual data and not the files
        elevation2      -  e.g.: rating_curve1, measured_concentration_of_pecticides_Station1,...
        rating curve1
        ...
     DataFolder2/
     ...
  Geometry/             - geometry-related data (maps) which can be used across the project
     Rhine/             -  folders are used to orginize layers in the same way as in case of Data
        water line (polyline)
        bridges (point)
     North Sea/
        water body (polygon)
        ...
     ...
  ScenarioFolder1/
     Scenario1Folder2/         - defines a set of tasks to simulate some region.
        Task1/            - a manager of the model (model instance + concrete data + run-time management) models which can be linked with each other
          Model1/
            input data1   - any data types provided by the model
            output data1  
            ...
        Task2  Model2/
            input data1
   - any data types provided by the model
            output data2data1  
            output... data1
          ...
      Scenario2  Task2/
         Task1/
 Model1/
            input data1
            ...
output data2
            Task2/output data1
            ...
         ...
     ...

Notes:
1. Probably all groups Data, Geometry Maps and Scenarios should Models can be put into a separate
Tabs view/tabs (like classes, files, favorites in any IDE, IntelliJ, Visual Studio).
2. Probably when system will run as embedded into ArcGIS - Geometry Maps tab will not be used at all,
because it will be also provided by ArcGIS

A typical use of the system (use case) may look likeelike:

• Start system GUI
• Open , select Project to work with or create a new one.
• Maybe import Import some data into the project from external files or create/edit a new one.Import some spatial data.
• Create Scenario Task to simulate some situation
  • Put some Tasks on Scenario.
  • Define Workflow of the scenario (in what sequence tasks will run and how the data will flow by defining connections between tasks).
  • Maybe connect/copy some of the Tasks data to existing project data, e.g. use specific bathymetry from the project data as an input to Delft3D model simulation task.
  • Run scenario to get results of the simulation.
  • Probably copy some of the model results to have them in your project data.

Scenario

Alternative names: Case.

• Represents application of some specific models to describe some area using concrete input data.
• Consists from the set of Tasks.
• Has a Workflow which defines how data are exchanged across the tasks and in which order tasks will run.
• Can be considered as a complex Task to model some area with pre-defined input data.

Task

• Manages any instance of the concrete Model.
• Can be in one of the states: Initial, Running, Paused, Failed, Completed.
• For the user Task is an instance of some Model with some set of input/output data.

Example:

When user starts some Application (e.g. notepad.exe) - the Process is created by
the operation system. Using Task Manager it is possible to manage that process.
For Task Manager it doesn't matter which concrete process is running. Using task
manager user can do Process.SetPriority, Process.Kill...

Task/Model is some analogue to the Process/Application.

Model

• • Add different models to task, each model can be added many times, for example to simulate different domains, schematisations.
  • Modify different model input data using available editors such as:
    • Schematisation editor based on map.
    • Time series editors
    • Model parameter / attribute editors
    • Other model data such as initial, boundary conditions.
  • Link different models together using automatic or manual linkage based on:
    • Model meta information (physical quantities, types of data)
    • Model schematization (spatial)
  • Run task(s) of model(s) to obtain results of the simulation.
  • Observe results from the model which they run or wait until it will finishes.

Task

• Contains a set of Models which can be linked and run together
• Can be in one of the states: Initial, Running, Paused, Failed, Completed.

Model

• Wraps any computitional engine such as SOBEK 1D Flow, Delft3D Flow, Waq, etcDefines interface which needs to be implemented by any specific model adapter which should be integrated into the system.
• Provides access to the model input/output data at design and run-time.

...

• Defines data flow and components for some Scenario.

Data Objects

The next issues are important when designing model data classes.

• Data declaration Declaration - meta information about data like data value type, data role, common properties.
• Concept of time.
• Concept of space.
• Value classes Values - define entities to store different value types: scalar, field of values, time series, ....
  • Scalar Parameters / Parameter Sets.
  • Time- and space-related data.
  • Definition of arbitrary functions.
• Concept of time.
• Concept of space.

Ideas about classes to define fields of values on different grids are wanted (0D, 1D, 2D, 3D). Review existing ideas used in VANDA, FEWS, Netter...

DataItem

Alternative names: ExchangeItemExchangeItem (OpenMI).

• Any atomic data item in the system (concrete parameter, function, a set of parameters, time series, etc.).

...

Notes: for more detailed definition of Function and it's properties see ModellingSystem#Function Function.

Any of DataItem has a set of properties which describe what kind of data it stores. Minumum set of properties would include:

• Name - real name of the data: "rating curve", "bathymetry", "velocity field"...
• Qyantity - physical quantity defining data: "flow", "elevation", "velocity"...
• Substance - "sediments", "acidity", "nitrates"...

Quantity

Defines real physical quantity of the data.

Properties:

• Name - real name of the data: "massrating curve", "bathymetry", "concentration"
• Unit - unit of measure.

Substance

• In some / many cases we have data valid for specific substances.
• Substance probably may be also used as an argument to some other data types.

Note: but this can make our class library more complex and at the beginning this feature will not be available to avoid confusions.

Type

• velocity field"...
• Quantity - physical quantity defining data: "flow", "elevation", "velocity"...

Quantity

Defines real physical quantity of the data.

Properties:

• Name - real name: "mass", "concentration"
• Unit - unit of measure.

Type of data

• Currently Defines what type of data is represented by the the DataItem, currently the next types will be supported:
  • Parameter - any data defined by only one value, f = v.
  • Function - any function defined as a discrete or analytical function.
    • TimeSeries - Function with at least one argument / dimension defined as Time, f = f(t).
    • Field - Function with at least one argument / dimension defined as Location / Geometry.

All data types listed here will be described later in more details.

Parameter

• Any scalar parameter defined by only one single value of any type (int, float, string, ...).

...

In HDF5 library alternative to FunctionArgument and FunctionComponent can be Dimension and Variable.

See also:

• http://wiki.opendap.org/twiki/bin/view/Developers/ModelSummary^{Image Removed} - comparison of HDF5 and NetCDF terms.
• Google keywords: "NetCDF HDF5", "NetCDF HDF5 performance"
• http://www.unidata.ucar.edu/software/netcdf-java/^{Image Removed} - java implementation of CDM (common data model)
• http://www.unidata.ucar.edu/software/netcdf/CDM/CDM.html^{Image Removed} - a generalization of netCDF, HDF5 and OpenDAP data models.
• http://wiki.opendap.org/twiki/bin/view/Developers/ModelSummary^{Image Removed} - summary of differend data models.

...

See also:

• http://geoapi.sourceforge.net/snapshot/javadoc/org/opengis/coverage/Coverage.html^{Image Removed}.
• http://docs.codehaus.org/display/GEOTOOLS/ISO+19123+progress+and+future+plan^{Image Removed}.
• http://jira.codehaus.org/browse/GEO-59^{Image Removed} - an JIRA issue related to replacement of current GeoTools implementation of Coverage.
• http://geotools.org/Multidimensional+Georegistered+Grid^{Image Removed}.
• http://hdf.ncsa.uiuc.edu/HDF5/papers/presentations/HDF5_overview/sld001.htm^{Image Removed}
• ftp://ftp.unidata.ucar.edu/pub/netcdf-java/v2.2/NetcdfJavaUserManual-2.2.pdf^{Image Removed}
• http://www.wadi.nl/gegmodel/wadi-rdfs-browse/toc.html#_fc_S^{Image Removed} - RIKZ.
• Generic Data (geometry) definition for WL applications, Berg Jagers.

...

• Storage mechanism for different types of coverages:
  • Store all values of the Field object as a Blob column in the DB.
  • Blob representing values may be stored as a HDF5 object then we will have nice API to work with it.
  • Use approach similar to PostGIS: provite a set of functions to work with values in the blobs.

Geometry

...

Types (gis-enabled model schematization and data connected geometry)

In this section we provide all minimum set of Geometry / Location classes which are required to store data of the models.

In general they should include minimum subset of the OpenGIS specifications which will be able to describe:

• Domain area Schematisation of the model: river, pipe network, water body, measurement station network, etc.
• Model numerical grids: graph grids, rectangular regular / irregular grids, triangulated irregular grids and also a set of boundaries on these grids. See also Field in Data Objects section.

...

• A set of cell numbers defined as a sequence of as a range of cell indices.

See also http://geoapi.sourceforge.net/snapshot/javadoc/org/opengis/coverage/grid/GridRange.html^{Image Removed}

Model-specific plugins

...