...
Documents:
http://www.openmi.org/
http://sourceforge.net/projects/openmi
wiki.openmi.org/OATC
Agenda & Minutes
1. Minutes from previous OATC meeting
2. Maintenance and support
- Reported bugs
(GOTO bug list 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.
...
3. OpenMI 2.0 Issues
3.1 Use cases
There were no changes to the use cases
...
3.2 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
...
3.3 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
...
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
6. www.OpenMI.org
No changes
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#
...
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)
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.
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
7.1.7.1. 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
...
and unresolved issues
...