Implementation of CVODEs in OEM

[konstantinos@…]

Please implement the CVODES solver in OEM editor simulation options.

[Francesco Casella]

@lochel, this feature has strategic value for Berkeley Imperial. I also saw in other tools that, contrary to what I expected, the BDF method of CVODE is much faster than IDA and DASSL when handling ODEs.

I understand you are already implementing CVODE for FMI-CS, I guess also implementing it in the normal simulation runtime shouldn't be a big deal. Can you please confirm?

[Andreas Heuermann]

I started implementing CVODE in the C-runtime. With this it will be a smaller task to implement it for FMI 2.0 CS export and we have enough data to make good tests.

[Andreas Heuermann]

Added with ​commit 419f112 and will be available in the next nightly-build.

CVODE for the C runtime can be used via -s=cvode and from OMEdit by choosing the integrator methodcvode in the simulation setup.
You can use BDF or ADAMS method to integrate your model.

The feature is marked as experimental for now.
If it's faster than IDA or DASSL remains to be tested.

[Francesco Casella]

Great, thanks @AnHeuermann!

I see we already have a very short description of this new feature in the ​-s flag documentation. Please add a more detailed description in the ​solver documentation page, possibly in the Experimental Solvers section until you are happy with the testing. Please make sure it doesn't stay there forever :)

Regarding speed, I understood from some colleagues that CVODE's BDF could be substantially faster than DASSL used as ODE solver. We should definitely ascertain if that is the case and, if so, we could eventually switch to CVODE as a default solver for odeMode simulation.

A great opportunity for testing comes with Jenkins. We are already experimenting some combinations like newInst or newInst+daeMode, see the index here ​here.

We could start with a single test, where we try MSL 3.2.3 with CVODE. This could be added as an extra test to ​newInst run, and would allow to check the performance on a wide range of models, including verification against reference trajectory.

Alternatively, we could add one more task newInst-cvode that runs the entire testsuite. @adrpo, @sjoelund.se, what do you think?

[Andreas Heuermann]

The nightly build for OS-X failed because of my commit even though I did run ​PR 9087 with CI/Build OSX.
What does the PR test different than the nightly build so that the error was not catched?

From the [Hudson] Build failed in Hudson: OpenModelica_OSX_NIGHTLY_BUILD #2608 mail. See ​Hundosn #2608.

--->  Scanning binaries for linking errors
Could not open libsundials_cvodes.2.dylib: Error opening or reading file (referenced from /opt/openmodelica/lib/x86_64-darwin15.4.0/omc/libOpenModelicaFMIRuntimeC.dylib)
libsundials_cvodes.2.dylib seems to be referenced using a relative path. This may be a problem with its canonical library name and require the use of install_name_tool(1) to fix.
--->  Found 1 broken file, matching files to ports

But I did use @rpath:

test ! `uname` = Darwin || install_name_tool -change libsundials_cvodes.2.dylib @rpath/libsundials_cvodes.2.dylib $(builddir_lib)/$(LIBSIMULATION)

So am I missing another call like with install_name_tool in ​SimulationRuntime/c/Makefile.common#L295? And how can I test it without waiting for the next nighly build?
It was running fine on our Max machine at omodmac.ida.liu.se.

[Andreas Heuermann]

So the build of OMEdit is failing?

From ​Hudson #2608:

x ./Applications/MacPorts/OMEdit.app/Contents/
x ./Applications/MacPorts/OMEdit.app/Contents/Info.plist
x ./Applications/MacPorts/OMEdit.app/Contents/MacOS/
x ./Applications/MacPorts/OMEdit.app/Contents/PkgInfo
x ./Applications/MacPorts/OMEdit.app/Contents/Resources/
x ./Applications/MacPorts/OMEdit.app/Contents/Resources/empty.lproj
x ./Applications/MacPorts/OMEdit.app/Contents/Resources/omedit.icns
x ./Applications/MacPorts/OMEdit.app/Contents/MacOS/OMEdit
--->  Cleaning openmodelica-devel
--->  Removing work directory for openmodelica-devel
--->  Scanning binaries for linking errors
Could not open libsundials_cvodes.2.dylib: Error opening or reading file (referenced from /opt/openmodelica/lib/x86_64-darwin15.4.0/omc/libOpenModelicaFMIRuntimeC.dylib)
libsundials_cvodes.2.dylib seems to be referenced using a relative path. This may be a problem with its canonical library name and require the use of install_name_tool(1) to fix.
--->  Found 1 broken file, matching files to ports
--->  Found 1 broken port, determining rebuild order
--->  Rebuilding in order
     openmodelica-devel @1.16.0~dev-419-gf0d7921 +gfortran5+libraries+omnotebook+qt
--->  Computing dependencies for openmodelica-devel.
--->  Cleaning openmodelica-devel
--->  Removing work directory for openmodelica-devel
--->  Scanning binaries for linking errors
Could not open libsundials_cvodes.2.dylib: Error opening or reading file (referenced from /opt/openmodelica/lib/x86_64-darwin15.4.0/omc/libOpenModelicaFMIRuntimeC.dylib)
libsundials_cvodes.2.dylib seems to be referenced using a relative path. This may be a problem with its canonical library name and require the use of install_name_tool(1) to fix.
--->  Found 1 broken file, matching files to ports
--->  Found 1 broken port, determining rebuild order
--->  Rebuilding in order
     openmodelica-devel @1.16.0~dev-419-gf0d7921 +gfortran5+libraries+omnotebook+qt

I rebuild OMEdit and did run the testsuite on machine at omodmac.ida.liu.se and could not see anything strange.

[Andreas Heuermann]

Some otool action:

omodmac:omc andreas$ otool -L libSimulationRuntimeC.dylib
libSimulationRuntimeC.dylib:
        @rpath/libSimulationRuntimeC.dylib (compatibility version 0.0.0, current version 0.0.0)
        /opt/openmodelica/lib/libcurl.4.dylib (compatibility version 11.0.0, current version 11.0.0)
        /opt/openmodelica/lib/libexpat.1.dylib (compatibility version 8.0.0, current version 8.11.0)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1226.10.1)
        /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 120.1.0)
        @rpath/libsundials_idas.0.dylib (compatibility version 0.0.0, current version 0.0.0)
        @rpath/libsundials_cvodes.2.dylib (compatibility version 2.0.0, current version 2.0.0)
        @rpath/libsundials_kinsol.1.dylib (compatibility version 1.0.0, current version 1.0.0)
        @rpath/libsundials_nvecserial.0.dylib (compatibility version 0.0.0, current version 0.0.2)
        /opt/openmodelica/lib/libopenblas-r1.dylib (compatibility version 0.0.0, current version 0.0.0)
        @rpath/libipopt.0.0.0.dylib (compatibility version 1.0.0, current version 1.0.0)
        @rpath/libcoinmumps.1.5.2.dylib (compatibility version 7.0.0, current version 7.2.0)
        @rpath/libumfpack.dylib (compatibility version 0.0.0, current version 0.0.0)
        @rpath/libklu.dylib (compatibility version 0.0.0, current version 0.0.0)
        @rpath/libbtf.dylib (compatibility version 0.0.0, current version 0.0.0)
        @rpath/libcolamd.dylib (compatibility version 0.0.0, current version 0.0.0)
        @rpath/libamd.dylib (compatibility version 0.0.0, current version 0.0.0)
        @rpath/liblis.dylib (compatibility version 1.0.0, current version 1.0.0)
        @rpath/libcminpack.dylib (compatibility version 1.0.0, current version 1.3.4)
        /opt/openmodelica/lib/libiconv.2.dylib (compatibility version 9.0.0, current version 9.1.0)

omodmac:omc andreas$ otool -L  libsundials_cvodes.2.dylib
libsundials_cvodes.2.dylib:
        libsundials_cvodes.2.dylib (compatibility version 2.0.0, current version 2.0.0)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1226.10.1)
        @rpath/libklu.dylib (compatibility version 0.0.0, current version 0.0.0)
        @rpath/libamd.dylib (compatibility version 0.0.0, current version 0.0.0)
        @rpath/libcolamd.dylib (compatibility version 0.0.0, current version 0.0.0)
        @rpath/libbtf.dylib (compatibility version 0.0.0, current version 0.0.0)
        /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libLAPACK.dylib (compatibility version 1.0.0, current version 1.0.0)

[Adrian Pop]

What is different on OSX nightly-build for the Hudson is that it checks if all the dlls are accessed properly using rpath.

[Andreas Heuermann]

Okay, I still don't see the error. When looking at libsundials_idas.0.dylib I get:

omodmac:omc andreas$ otool -L libsundials_idas.0.dylib
libsundials_idas.0.dylib:
        libsundials_idas.0.dylib (compatibility version 0.0.0, current version 0.0.0)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1226.10.1)
        @rpath/libklu.dylib (compatibility version 0.0.0, current version 0.0.0)
        @rpath/libamd.dylib (compatibility version 0.0.0, current version 0.0.0)
        @rpath/libcolamd.dylib (compatibility version 0.0.0, current version 0.0.0)
        @rpath/libbtf.dylib (compatibility version 0.0.0, current version 0.0.0)
        /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libLAPACK.dylib (compatibility version 1.0.0, current version 1.0.0)

Looks similar to libsundials_cvodes.2.dylib to me and I'm assuimg that this is correct since it was working all the time.

@sjoelund.se What did you say is the error?

I understood that we would need something like this?

omodmac:omc andreas$ otool -L  libsundials_cvodes.2.dylib
libsundials_cvodes.2.dylib:
        @rpath/libsundials_cvodes.2.dylib (compatibility version 2.0.0, current version 2.0.0)
        ....

[Andreas Heuermann]

OSX is back online with commit ​58b509d.

Added documentation in commit ​2c23e69.

[Andreas Heuermann]

Continue discussion on improving CVODE in ticket #5997.