Dsd int 2014 - open mi symposium - openmi and other model coupling standards, bert jagers and stef...

Delft Software Days, OpenMI Symposium, October 31st 2014

OpenMI and other model coupling standards / frameworks Bert Jagers Stef Hummel Deltares

Overview

• Aspects of Modelling Frameworks • OpenMI

• Overview • OpenMI 2.0 versus OpenMI 1.4

• Other frameworks • Various initiatives • Comparison

• Conclusions

2 Delft Software Days, OpenMI Symposium, October 31st 2014

Aspects of Modelling Standards / Frameworks

• Interface based / file based • Specification (paper / software) • Implementation environment (c# / java / fortran / …) • Meta data for exchanged data? • User interface? • Run time framework?


OpenMI

• Interface based (ILinkableComponent) • No framework required; GUI and runner available • Data exchange:

• Configuration time: Meta data (‘What’ / ‘Where’) • Run time, pull driven: Get values per time step (‘When’)

string ID string Description string DetailedDescription ITimeStamp EarliestNeededTime

<<Interface>> ILinkableComponent

void Create(IArgument[] properties) void Initialize() IInputExchangeItem[] GetInputExchangeItems() IOutputExchangeItem[] GetOutputExchangeItems() void AddLink(ILink link) void RemoveLink(string linkID) void PrepareForComputation() IValueSet GetValues(ITime time, string linkID) void Finalize() void Dispose()

What: Quantity Where: ElementSet (Spatial definition)

When: GetValues(time) (time stamp or time span)


What: Quantity

ID ( “Runoff” ) Description ( “Rainfall runoff” ) Dimension ( e.g. L3 T-1 )

• GetPower ( <dimensionBase> ) Unit:

• ID ( “CFS” ) • Descr ( “Cubic feet per second “ ) • ConversionFactorToSI ( 0,0283168439 ) • OffsetToSI ( 0 )


R1

R2

R3

R4

S4

S1

S2 S3

S5

y

2000 m

10000 m

4000 m

6000 m

5000 m

ISIS River

MOUSE Sewer

SOBEK RR Catchments

S6

Ground- Water

Rainfall, IsoHyet 2

Rainfall, IsoHyet 1

x

Where: ElementSets


R1

R2

R3

R4

S4

S1

S2 S3

S5

y

2000 m

10000 m

4000 m

6000 m

5000 m

River

Sewer

Rainfall Runoff Catchments

S6

Ground- Water

Rainfall, IsoHyet 2

Rainfall, IsoHyet 1

x

Where: ElementSets


Linking: What / Where

GUI OpenMI 1.4 (OATC)


Linking: What / Where

FluidEarth GUI OpenMI 2.0


OpenMI 2.0

• SetValues added • ‘Quality’ added (catagorized data)

• More efficient linking • Mapping no longer in the link, but

by means of (a chain of) adapters • GetValues(time) on output items and on adapters

instead of on the linkable component

Component 1

Component 3

Component 2

June 2014: OpenMI 2.0 OGC standard!


3D flow model with data - at XYZ vertices - at certain timesteps

Link

1.4

2.0

Point1.H

Point2.H

Outflow Inflow

Point1.H

Point2.H

Grid.H

Input- item

Output- item

Linkable Compo- nent

Legend:

Grid.H

Adapted- Output

polygon to point

t

t

t

t

Provider/Consumer

From 1.4 to 2.0: More efficient linkage


1.4

2.0

lateral discharge

friction

lateral discharge

friction

Set the values into the input item, according to its location specification and/or its time specification

friction.Values = …

lateralDischarge.Values = …

Tools that (repeatedly) analyse certain "what if" scenario‘s:

Calibration: What if the bottom friction is adjusted, will the model perform better?

Decision support tools: What if somewhere upstream more water is extracted, will there be problems downstream?

From 1.4 to 2.0: Optimizers, Calibration tools


OpenMI Software Development Kits (SDK’s)

OpenMI 1.4: • c# (OATC, OpenMI Association Techinical Committee) • java (OATC, Alterra) • proprietary SDK’s

OpenMI 2.0: • c# (OATC) • Fluid Earth • proprietary SDK’s


Wrapping computational (Fortran) cores

Computational core

Initialize

PerformTimeStep

Finalize

Initialize PerformTimeStep

Finalize

GetValues(…) Set<varType>(varId)

Get<varType>(varId)

Get<varType>(varId)

GetValues(…)

GetValues(…)

Standardized interface (ILinkableComponent)

Non-standardized interface (in OpenMI)

Non-standardized interface (in OpenMI)

However, obvious level for standardization. E.g.: CSDMS’ BMI (Basic Model Interface)


Other frameworks

and many more … FRAMES CHyMP DeltaShell LIQUID ModCom Danubia …

OASIS

OMS

HLA

Delft-FEWS

HydroPlatform


http://csdms.colorado.edu/wiki/File:CSDMS_high_res_weblogo.jpg

Other frameworks

Topics

HLA

OMS

All technologies listed define component as a software package or a module that encapsulates a set of related functions. Science components generally represent a coherent subset of the physical processes for the whole (or part of the) simulation domain. However …

OASIS


Comparison

Topics

Framework

Interfaces

Implementation provided

… the technologies differ with respect to the degree to which they impose an overall architecture/provide a framework, restrict component interfaces, and provide an implementation for the framework and interface routines.

Topics

Framework

Interfaces

Implementation provided R R


Comparison

Topics

Framework

Interfaces


Exchanged var.s defined

Although most technologies prescribe a component interface, it turns out that only half of them demand a description of the variables exchanged. If they do, it’s generally in some kind of parameter-location-time way.


Comparison

Topics

Framework

Interfaces



Code invasiveness -- + ++ -

A basic comparison of code invasiveness was carried out for four of these coupling technologies by Lloyd et al (2009). A (scalar) water balance model was used for this evaluation. The OMS framework came out as least invasive, mainly due to the use of Java annotations to identify input and output arguments.


Comparison

Topics

Framework

Interfaces



Code invasiveness -- + ++ -

Plug & play (GUI)

About half of the groups allow components to be brought together at run time (contrary to compile/link time). In some cases thre’s a GUI that supports this plug & play character.


Comparison

Topics

Topics

Support for HPC

C/Fortran support W W W W

Java support

.NET support

Roughly half of the technologies have been developed with HPC applications in mind. All technologies have solutions to adopt components written in C/C++ and Fortran. Java support is less common, but more frequent than .NET support.


Conclusions

• There are a lot of different technologies that one can use to connect components in a modular way.

• The various technologies have been developed from different backgrounds, but are converging towards common concepts.

• Due to differences in application requirements, various technologies will continue to co-exist.

• However, co-operation between coupling technology developers is strongly recommended to improve reusability of components across these frameworks.

• OpenMI is highly fit for hydrological applications: • Establish the correct links by using meta data

(large variability in model concepts, quantities, and units) • Very flexible data conversions by means of the adapters


Dsd int 2014 - open mi symposium - openmi and other model coupling standards, bert jagers and stef...

Science

Transcript of Dsd int 2014 - open mi symposium - openmi and other model coupling standards, bert jagers and stef...