Date: April 14-16, 2008
Venue: Deltares, Rotterdamseweg 185, 2629 HD Delft, The Netherlands
Jan Gregersen, DHI / LicTek (firstname.lastname@example.org) (chairman of the meeting)
Adrian Harper, Wallingford Software (email@example.com)
Stef Hummel, Deltares (firstname.lastname@example.org)
Unknown User (don) (Gena), Deltares (email@example.com)
Peter Gijsbers, Deltares (Peter.Gijsbers@deltares.nl)
Unknown User (onnoroos), Alterra (Onno.Roosenschoon@wur.nl)
Rob Knapen, Alterra (Rob.Knapen@wur.nl) (only on Monday)
Peter Schade, Bundesanstalt fuer Wasserbau, Germany (Peter.Schade@BAW.DE)
Jon Goodall, Univ South Carolina (firstname.lastname@example.org)
Unknown User (email@example.com), DHI - Water & Environment (firstname.lastname@example.org)
OpenMI version 2.0
Agenda & Minutes
1. Maintenance and support
- Reported bugs
(GOTO bug list on SourceForge)
- Feature requests
(GOTO Feature requests on SourceForge)
(GOTO Feature requests on SourceForge (under forums))
- Help issues
(GOTO help issues on SourceForge)
- Discussion issues
(GOTO discussion issues on SourceForge)
We reviewed the reported bugs and assigned persons to make corrections. These corrections will be done to the Svn branch "OpenMI-1.4.1-dev" and as such be included in the OpenMI SDK and GUI release 1.4.1.
2. OpenMI 2.0 Issues
2.1 Development model
Review the iterative development plan (Goto Plan)
Please also read "March 2006, OpenMI 2.0 by Brinkman, Hummel, and Gijsbers"
Deltares will in the period until the next OATC meeting in June work on a proposed architecture for the OpenMI 2.0 standard. The main focus will be on the first two issues described in the development plan (iteration 1 & 2). Deltares will try to get at full implementation ready (including the configuration editor) by May 28, which will allow the OATC to prepare themselves for the discussions on the OATC June meeting.
2.2 Use cases
There were no changes to the use cases
2.3 OpenMI 2.0 architecture
Quality versus Quantity
_We tried to remind ourselves about the outcome of previous discussions about quality, quantity, and categorized data.
The figure below shows the Interfaces we wanted to be implemented._
Rob Knapen, will implement this in these interfaces in the Java implementation in the svn trunk. Notice that the trunk on sourceforge now represents the developments towards version 2
2.4 Development and release roadmap
3. OpenMI Java and OpenMI .net synchronization
Rob will follow up on the progress of JGrass, and report back to the OATC
Rob will upload the OpenMI 1.4 Java SDK, developed by Alterra to a directory under the MyOpenSource on SourceForge (create new subdirectory called Alterra).
4. OATC Procedures
Review and update the OATC procedures (GOTO OATC procedures)
Jan Gregersen will update the proceedures
5. OpenMI WIKI
A page called HowTO get the most recent source code was added to the getting started page
Peter Schade will create a page describing issues relevant for running OpenMI under Linux
A new link page were added under the getting started page
7. Miscellaneous issues
7.1 OpenMI and Linux (Peter Schade)
- short overview, why BAW is interested in linux
- OpenMI (C#) standard has to be ported, which OpenMI version is suitable for Mono?
- the C# wrappers have to be ported
- the Fortran engines have to be ported, which compiler, ifort or Compaq Digital?
- accessing the Fortran dll from C#
Peter Schade gave a presentation of his experiences so far with running OpenMI under Linux
See OpenMIGoesLinux_200804.pdf presentation from BAW.
Peter Schade and Gena Donchyts propose the following porting strategy:
7.1.1. Porting the OpenMI environment
Peter will, supported by Gena, port
- the OpenMI standard v. 1.4.0,
- the SDK v 1.4.1 and
- the OmiEd v.1.4.1
to Linux. It is expected that most work can be done by running the Microsoft Visual Studio 2005 DLLs on the Linux system. If problems occur the sources will be compiled with the gmcs compiler.
7.1.2. Porting the Fortran Code from Compaq to ifort on Windows
Generation of a ifort gei.nt.dll and a main program and running the 31 test cases. (Peter)
- generation and testing of gei.win.dll
7.1.3.Porting the ifort Code from Windows to Linux
Peter will compile a Linux shared library gei.xe.sl with the ifort. Adri Mourits has given hints how to access the methods from outside. BAW will run its 31 test cases with a Fortran main program calling the shared library.
- generation of all necessary ifort shared objects inclusive the interface gei.linuxxe32.so;
- the linux results of the 31 testcases are similar to the ifort windows results (few rounding errors)
- system: SLED10 with 32bit
7.1.4. Porting GEIWrapper to Linux
The BAW will port the GEIWrapper and test the connection between this C# shared library and the Fortran gei.xe.sl.
7.1.5. Porting trisim and WLDelftWrapper to Linux
After finishing step 1.4, it could be reasonable to port the OpenMI compliant Fortran trisim shared library and the WLDelftWrapper to Linux (Deltares). Alternatively, Deltares can offer a Linux trisim and the information how to access it from a Windows WLDelftWrapper.
7.1.6. Test of a composition
It is the aim to run a WLDelftWrapper - GEIWrapper composition under Linux. A GEIWrapper - DataMonitor composition would be the second best alternative. (BAW and Deltares)
7.1.7. General information
188.8.131.52. Test System
The BAW test system will be a Linux workstation with one Intel Xeon Dual Core Processor and SLED 10 in 32 bit mode, since a 64bit Delft3D would cost sizeable additional effort. Bert Jagers has indicated that the current OpenMI is designed for shared memory. Guntram Seiss (BAW) and Peter will find out, what this means for running it on BAW's Linux cluster Altix XE 1300. This machine is binary compliant with the test system.
According to Guntram, the eight CPUs of one Altix XE 1300 node share their local memory. Running Delft3D with up to eight domains should be possible as well as using 32bit mode.
7.2 SourceForge version control
We need to decide how to handle the version control on source forge. Should version 2 be developed as the trunk and version 1.4.1 a branch? Whatever we decide should be described in a OATC procedure.
We reorganized the svn repository. The development towards version 1.4.1 will now take place in the branch called OpenMI-1.4.1-dev and the developments towards version 2.0 will take place in the trunk. Tags and branches were renamed so the names will indicate the version number.
Se tags and branches after the update below.
8. Tasks and unresolved issues
All tasks and unresolved issues are managed via the sourceForge server: (GOTO OpenMI tasks on SourceForge)