Download Links

Simulate 3D | SBW (Win32) | Bifurcation Discovery | FluxBalance

Monday, August 9, 2010

Writing Plug-ins for the Simulation Tool – Part 2 – Setup - MonoDevelop


MonoDevelop is a free IDE by Novell, that is available on all operating systems. IT does not feature a visual designer and has no advanced debugging facilities as we see them in Visual Studio but it still is quite good. So let us try and create a project by hand that would create the above plug-in.  To make this authentic I add screenshots from doing it on OS X 10.6.

First let us start MonoDevelop and create a new Project:

Screen shot 2010-08-05 at 11.59.56 AM 

Next let us load all the required libraries (I’ve copied the files from the SBW Installation, which is either in /Application/SBW/lib or ~/SBW/lib on Linux):

Screen shot 2010-08-05 at 12.00.20 PM 

don’t forget to add System.Drawing and System.Windows.Forms from the GAC. The result should look like this:

Screen shot 2010-08-05 at 12.18.47 PM

(I went ahead and already copied some code for a plug-in into my project) 

When this is loaded let us modify the project settings:

Screen shot 2010-08-05 at 12.23.05 PM

Here we can change the default namespace:

Screen shot 2010-08-05 at 12.23.21 PM

and the target machine (x86):

Screen shot 2010-08-05 at 12.23.49 PM

And the output directory:

Screen shot 2010-08-05 at 12.24.12 PM

The output directory should *for now* be the SBW lib directory (that is where all the C# assemblies are). Under Linux that would be:


and on OSX it is /Applications/SBW/lib.

for now this should be the same as the SBW one.  

All this has been saved in this project:

(It already uses the output directory /Application/SBW/lib as needed for OS X 10.6)

Unfortunately, similarly to Visual Studio Express there is no debugging support for Libraries … thus after a build you will need to start the simulation tool manually. (for example by double clicking on the Simulation Tool in /Applications/SBW (on OS X), or by launching ~/SBW/Simulation Tool … or if the SBW/bin is in the path by starting sbw_simultool.

Screen shot 2010-08-05 at 2.48.26 PM 

if you test it with ‘oscli.xml’ you see this:

Screen shot 2010-08-05 at 2.49.05 PM

Thursday, August 5, 2010

Writing Plug-ins for the Simulation Tool – Part 3 – Setup – Command Line

Command Line

for the command line compilation 1st ensure that you have mono installed ( (or on windows .NET 3.5 has to be installed). Next download the project we created above:

once extracted you can compile those files from the command line using:

gmcs *.cs -r:3rdParty/Microsoft.ComponentModel.Composition.Diagnostics.dll -r:3rdParty/SimulationToolAPI.dll -r:3rdParty/System.ComponentModel.Composition.dll  -r:3rdParty/ZedGraph.dll  -r:System.Windows.Forms -r:System.Drawing -target:library -platform:x86 -out:SimulationToolPlugin1.dll

on mono or:

\Windows\Microsoft.NET\Framework\v3.5\csc.exe  -r:3rdParty/Microsoft.ComponentModel.Composition.Diagnostics.dll -r:3rdParty/SimulationToolAPI.dll -r:3rdParty/System.ComponentModel.Composition.dll  -r:3rdParty/ZedGraph.dll  -target:library -platform:x86 -out:SimulationToolPlugin1.dll *.cs

using microsofts compiler.

next you copy the resulting SimulationToolPlugin1.dll into the SBW directory:

~/SBW/lib on linux

/Applications/SBW/lib on OS X

c:\program files\KGI\SBW\roadrunner on win32 and

C:\Program Files (x86)\KGI\SBW\roadrunner on win64.

Now if you start the simulation tool you again should see the newly build plug-in in an unnamed category.

Writing Plug-ins for the Simulation Tool – Part 1 – Setup - Visual Studio

With the release 2.8.1 of the Systems Biology Workbench the Simulation Tool now has a plug-in system based on MEF. This enabled me to enhance the simulation tool by both new layouts (changing the look and feel) as well as include new Simulation Experiments (like the Signal Injection plug-in). But now that we have this new plug-in API it also allows Y O U to write for it. And I’m excited to see  Y O U R contributions. (I’m preparing a online repository for plug-ins). So how do you write these plug-ins? In this series I show you how to set up the IDE, so that you can start writing plug-ins, and then give a couple of examples of simple plug-ins one could write.

There are three ways that I envision people would write plug-ins:

  • using Visual Studio (2010 / 2008 / Express (free))
  • using MonoDevelop (
  • using the command line (either on windows / posix)

Visual Studio

Visual Studio is my tool of choice when it comes to programming. Luckily most universities have contracts with microsoft, so ask your IT department for a copy (ours had 2010 Ultimate!). If they don’t you still have the option of getting a full version at dreamspark:

Or of course the express editions will work:

In the following I use screenshots from Visual Studio 2010, but the same will apply to Visual Studio 2008 and Express editions.

In order to ease the process of writing plug-ins I have created Visual Studio Templates. You can download them from:

simply download the Zip files and place them into:

C:\Users\fbergmann\Documents\Visual Studio 2010\Templates\ProjectTemplates\Visual C#

(just replace fbergmann with whatever your user name is). The same templates also work for Visual Studio 2008 where you place them into:

C:\Users\fbergmann\Documents\Visual Studio 2008\Templates\ProjectTemplates\Visual C#

Once this is done start Visual Studio and create a new project. Now in the template wizard you can simply select the SimulationToolPlugin template:

Screen shot 2010-08-05 at 10.59.59 AM

Once you confirm the new project will be created and loaded. The code already implements a simple plug-in. So let us set up the properties, so that we can run it. For this go to

Project\SimulationTool1Plugin Properties

Screen shot 2010-08-05 at 11.05.23 AM

Here you want to change the ‘Assembly Information’ to provide a short description of your plug-in an set your Copyright information. Next you might want to change the Default Namespace and the Assembly Name. My recommendation is to use the same name for both. The Assembly Name controls what the name of the resulting .DLL will be.

Next let us flip to the Build tab:

Screen shot 2010-08-05 at 11.08.40 AM

The key  elements here are: The platform target: make sure to select x86 (as the simulation tool uses native libraries that are compiled for 32bit only). The output path:

you want to set this one *for now* to the directory of the Simulation Tool:

C:\Program Files (x86)\KGI\SBW\roadrunner

on 64-bit systems and:

C:\Program Files\KGI\SBW\roadrunner

on 32 bit systems.

Finally, let us set up how to start the debug session:

Screen shot 2010-08-05 at 11.15.02 AM

we want to start an external program:

C:\Program Files (x86)\KGI\SBW\roadrunner\SimDriverNET.exe or

C:\Program Files\KGI\SBW\roadrunner\SimDriverNET.exe

and we want to set the working directory to:

C:\Program Files (x86)\KGI\SBW\roadrunner or

C:\Program Files\KGI\SBW\roadrunner

(One note for express users: you won’t be able to start an external program in the express edition … I suggest you choose a Post Build Event to start the SimDriverNET executable by adding:

cd C:\Program Files\KGI\SBW\roadrunner && SimDriverNET.exe

as post build event now after every build you see the simdriver loaded with the new plugin, alas no debugging support.)

THAT IS IT … now we are ready to test our plug-in! close the property tab and press RUN. Our new plug-in is in an unnamed category so you can easily find it:

Screen shot 2010-08-05 at 11.19.33 AM

And when you load a model you can perform time course scans by entering values into it. Here a screenshot for the ‘oscli.xml’ file:

Screen shot 2010-08-05 at 11.25.20 AM

This is it you are all set up and ready to play with the plug-in. 

Graphical Initializer for CompuCell 3D

Currently, I’m with Herbert at the Indiana University, giving our SBW / CompuCell course. Over dinner we talked about how cumbersome it is to manually edit the Potts Initialization Files (PIF). This made me launch a new open source project, dubbed PifDesigner. I’ve put together a first prototype for 2D initializations, by either drawing, or initializing from images. The project is:

And here a screenshot of the new website.


Saturday, July 31, 2010

Systems Biology Workbench (SBW) 2.8.1 Released

We are pleased to announce the a release of the Systems Biology Workbench 2.8.1, available from:

The Systems Biology Workbench (SBW), is a software framework that allows heterogeneous application components-written in diverse programming languages and running on different platforms – to communicate and use each others' capabilities via a fast binary encoded-message system. Our goal was to create a simple, high performance, open-source software infrastructure which is easy to implement and understand. SBW enables applications (potentially running on separate, distributed computers) to communicate via a simple network protocol.

The interfaces to the system are encapsulated in client-side libraries that we provide for different programming languages.

There are a number of significant changes in this release:

  1. The SBW Simulation Tool has been largely rewritten to allow for a variety of interactive simulation experiments. Thanks to a new plug-in mechanism it is easy to extend the Simulation Tool.
  2. The script based modeling tool JarnacLite has been enhanced to make it easier to select Kinetic Laws to use.
  3. RoadRunner now supports SBML Level 3 (with the same restrictions that applied to Level 2, i.e.: no algebraic rules, no delays, no fast flag).
  4. Numerous bug fixes and usability improvements (such as a favorites menu bar, that allows to quickly edit / simulate SBML models in most applications).

For a full list of changes see:

With SBW 2.8.1 we have a new full release, with binaries for Windows, OSX (10.6) and Linux (tested with openSUSE 10.2 and Ubuntu Lucid). We are well aware that there are many more platforms available out there and regret not having the manpower to provide binaries for additional platforms. For this reason we have created a set of Virtual Machine (VMware/VirtualBox & Xen), hard drive image,  and Live CD image (running openSUSE 11.2). For all of these the username is ‘sbw’ and password is ‘linux’.

For a list of modules included with the Systems Biology Workbench and a description of what they do please have a look at

More details can also be found on my blog at:

In case you are interested in instruction in how to use the Systems Biology Workbench join our tutorial at this year's ICSB.

As always we appreciate any feedback from users send to:

Friday, July 30, 2010

JarnacLite – Helping with Kinetics!

The new version of JarnacLite, that is distributed with SBW 2.8.1 finally helps out in the arduous task of entering the kinetics. By using a customizable list of kinetic rate laws, it is now rather easy to construct models in this simple script format.

There are two steps to using this assistance:

  1. Enter the reaction scheme: In order to be able to filter the available rate laws, a reaction scheme needs to be present. Special note should be given to the reversible notation:

    S1 –> S2

    would mean that a species S1 is converted to S2, while

    S1 => S2

    would mean that this reaction is reversible. Different kinetics will be suggested.
  2. Once the reaction scheme is entered, pressing CTRL+SPACE or clicking the ‘Edit kinetic’ button will bring up the rate law selection dialog.
  3. All that is left to do after selecting a rate law is to adjust the parameters.

And here an example of how this looks in practice:

The SBW Simulation Tool – Part 4 – Parameter Scanning

It was always a bit cumbersome to perform parameter scans with our tools. Thus, with the new release of SBW a new plug-in was written that makes performing 1 or 2d parameter scans a snap. Be it steady state, or time course scans it should be easy to do. We support ranges (varying a parameter from a min to a max value in a number of steps), logarithmic ranges, or even just entering of specific parameter values to be used.

In order to be able to plot the scan results we interface with Gnuplot and allow users to tweak the gnuplot scripts. Resulting figures can then be exported as PDF or image.

Below a demonstration of the feature:

As you can see towards the end instead of just the floating species a wealth of output options is available.

The SBW Simulation Tool – Part 3 – The Script Plug-in

The new SBW Simulation Tool also features a script plug-in. By embedding IronPython, the popular python scripting language is available to power users. The script plug-in has access to the currently active Simulator (i.e.: RoadRunner) in its current state. Via simple programming one can influence all model variables and perform all kind of perturbation experiments. Also exposed are a Gillespie Simulator, the LibStructural Library. Of course access is granted to the host application, the plug-in itself and the graph panel. Finally, it is possible to programmatically access the BioModels database.

Admittedly the current implemented console is no substitute for a real Python editor, however, it is suited for inspections of the current state. For advanced use we recommend writing Python scripts in a separate editor and executing these scripts from the python console.

Below a short introduction to the script console. More documentation about the available methods is to come soon!

The SBW Simulation Tool – Part 2 – Signal Injection

The new simulation tool also comes with a couple of new interactive simulation experiments. The first one to be described here is the Signal injection plug-in as seen below.

It couldn’t be simpler to use. Simply load the model you want to experiment with, click the ‘add signal’ button, and choose parameter and signal type. Immediately the signal will be displayed in the graphing window and can be moved about with the mouse allowing you to directly see the influence this has.

For the sine  (or square wave) signal type it is possible to change the angular frequency by holding down the CTRL key and moving the mouse.

Here a video demonstrating this feature:

The SBW Simulation Tool – Part 1 – Look And Feel

The new release of the Systems Biology Workbench brings with it a largely rewritten version of the SBW Simulation Tool. Based on a new plug-in system, the Simulation Tool is now easily extendable. This allows not just to add new interactive simulation experiments, but also change the visual aspect of the Simulation Tool.

Changing the Look and Feel

By allowing the layout of the Simulation Tool customized by plug-ins it is now possible to find a layout that suits everyone. Here a the inbuilt examples:

image image image

But of course it would be easy to extend it … say by using a ribbon layout on windows:


I wonder what the simulation tool will look like tomorrow :)

In order to change the layout a user simply selects one of the options from the menu:


Thursday, April 29, 2010

RoadRunner & Java (!?)

Darren Wilkinson is here this week early for the Hackathon this weekend. One of his projects is CaliBayes, which addresses the issue of estimating  parameters of kinetic laws. CaliBayes uses Java, and until now using RoadRunner required to go through the SBW Java bindings, to the SBW Broker to RoadRunner. It seems apparent, that this won’t deliver the best possible performance.

A couple of weeks ago I first dabbled in embedding the mono runtime for use of RoadRunner in C++. So it seemed clear, that this could be extended to the JNI world.

A prototype was quickly written and tested on OSX (10.6, using a 32bit JVM) and verified to work on Ubuntu 9.10 (32 bit). So far the version is not working in 64bit Linux. Mainly because all our libraries are not yet available for 64bit. Oh well … but it is a start …

The Ubuntu version is now online on the source forge project, source code an all:

Wednesday, April 28, 2010

SED-ML in Pictures

Today a question came up on the sbml-discuss list on freely available software for simulating BioModels 139 and BioModel 140. Someone tried to reproduce the simulation results with these models and failed to do so. In the future of course SED-ML will help us out in these cases, by essentially encoding the simulation experiment directly.

So I went ahead and created some SED-ML examples for these models. You will find them below. Admittedly, so far only our tools seem to support the format, but other groups are showing interest. To give it a try, you could download the latest version of the Systems Biology Workbench. Once it is installed, start the ‘Simulation Tool’. Which now comes with an experimental support for SED-ML, and there you can open and run SED-ML files from the ‘SED-ML’ tab.

Here is how it looks for the BioModel 139:


And here the result for BioModel 140:


Of course SED-ML is still in its infancy, but as you can see, there is a need for it now. So don’t wait for the final version, start implementing it in your tools now! Or if you don’t develop for a software package yourself, ask the authors of your favorite tool to do so!

BioModel 139:

BioModel 140:

Monday, March 8, 2010

Getting Started with LibSedML (on linux)

A couple of days ago I announced the LibSedML sourceforge project, a library for reading / writing SED-ML files. However, what was missing so far is information on how one would start using the library. (If you feel lucky, I provided a binary at the end of this post!)

Preparing the Virtual Machine

In the following, I’ll describe how to set up an OpenSuse 11.2 Virtual Machine, in order to run SED-ML Simulation Experiments:

  1. Actually, we are not setting up the virtual machine, but instead take the one provided by the Mono team. Simply download the VMware image from:

    unzip and start the Virtual Machine. It will automatically log in as user ‘rupert’
  2. The first thing we might want to do is to get SBW started. While not strictly necessary … it will help us later on, when we just copy the binary libraries for LibSedMLRunner to execute the simulations. The Latest SBW version for linux can be found here:

    The file is simply installed by making it executable (chmod +x SBW-*bin) and executing the binary installer.
  3. Next we might want to install a fresh copy of LibSBML, which is easily done by checking out libsbml from SVN:

    svn co libsbml

    the virtual machine at this point has no g++ so we get one by going to a root shell (root password is ‘mono’) and installing:

    zypper install gcc-c++
    zypper install libxml2-devel

    (i also installed additional packages like ‘lapack’ but I’m not sure they are necessary)
  4. Next we get the latest SWIG from, I just downloaded the 1.3.40 version, unpacked it with tar zxf, ran:

    ./configure && make && sudo make install

    which installes SWIG into /usr/local
  5. Now we can compile and run libsbml:

    ./configure --with-libxml=/usr --with-swig=/usr/local --with-csharp --enable-layout=no && make

    which will compile libsbml and create the bindings in the src/bindings/csharp folder

Compiling LibSedML

So far for the prerequisites. The remaining could not be simpler. Here the whole session:

Directory: /home/rupert/Desktop
Tue Mar 9 02:35:51 UTC 2010
rupert@linux:~/Desktop> cd
rupert@linux:~> cd Development/
rupert@linux:~/Development> l
stotal 12
drwxr-xr-x 3 rupert users 4096 2010-03-08 20:20 ./
drwxr-xr-x 33 rupert users 4096 2010-03-08 22:21 ../
drwxr-xr-x 8 rupert users 4096 2010-03-08 20:21 sbwbuild/
rupert@linux:~/Development> svn co LibSedML
A LibSedML/SEDML.sln
A LibSedML/libSedMLScript
A LibSedML/libSedMLScript/
A LibSedML/libSedMLScript/libSedMLScript.csproj
A LibSedML/libSedMLScript/SedMLPythonConverter.cs
A LibSedML/libSedMLScript/ITextImporter.cs
A LibSedML/libSedMLScript/ITextExporter.cs
A LibSedML/libSedMLScript/Properties
A LibSedML/libSedMLScript/Properties/AssemblyInfo.cs
A LibSedML/libSedMLScript/Properties/Resources.resx
A LibSedML/libSedMLScript/Properties/Resources.Designer.cs
A LibSedML/libSedMLScript/SedMLScript.cs
A LibSedML/SedMLWeb
A LibSedML/SedMLWeb/Default.aspx.designer.cs
A LibSedML/SedMLWeb/MasterASPX.master
A LibSedML/SedMLWeb/SedMLWeb.csproj
A LibSedML/SedMLWeb/Web.config
A LibSedML/SedMLWeb/Default.aspx.cs
A LibSedML/SedMLWeb/_sysbiostyles.css
A LibSedML/SedMLWeb/MasterASPX.master.cs
A LibSedML/SedMLWeb/SysBio_MasterASPX.master
A LibSedML/SedMLWeb/KGI0717_MasterASPX.master
A LibSedML/SedMLWeb/Properties
A LibSedML/SedMLWeb/Properties/AssemblyInfo.cs
A LibSedML/SedMLWeb/SysBio_MasterASPX.master.cs
A LibSedML/SedMLWeb/Default.aspx
A LibSedML/SedMLWeb/KGI0717_MasterASPX.master.cs
A LibSedML/Samples
A LibSedML/Samples/model1.xml
A LibSedML/Samples/sedmltest.txt
A LibSedML/Samples/curien.xml
A LibSedML/Samples/EllowitzRepressilator.miase
A LibSedML/Samples/lorenz.txt
A LibSedML/Samples/BIOMD0000000021.xml
A LibSedML/Samples/miaseTest.xml
A LibSedML/Samples/sedmlCurienJWS.xml
A LibSedML/Samples/JanaWolf.miase
A LibSedML/Samples/miaseBioModels21.xml
A LibSedML/Samples/brusselator.miase
A LibSedML/Samples/brusselator.xml
A LibSedML/Samples/lorenz.miase
A LibSedML/Samples/lorenz.xml
A LibSedML/Samples/sedMLBIOM21.miase
A LibSedML/Samples/sedMLBIOM21.xml
A LibSedML/libSedMLRunner
A LibSedML/libSedMLRunner/SedMLRunner.cs
A LibSedML/libSedMLRunner/libSedMLRunner.csproj
A LibSedML/libSedMLRunner/RunResult.cs
A LibSedML/libSedMLRunner/SimpleRunner.cs
A LibSedML/libSedMLRunner/Properties
A LibSedML/libSedMLRunner/Properties/AssemblyInfo.cs
A LibSedML/SedMLConsole
A LibSedML/SedMLConsole/ICON_MIASE.ico
A LibSedML/SedMLConsole/Web References
A LibSedML/SedMLConsole/Web References/BioModels
A LibSedML/SedMLConsole/Web References/BioModels/Reference.cs
A LibSedML/SedMLConsole/Web References/BioModels/BioModelsWebServices.wsdl
A LibSedML/SedMLConsole/Web References/BioModels/
A LibSedML/SedMLConsole/Web References/MIRIAM
A LibSedML/SedMLConsole/Web References/MIRIAM/Reference.cs
A LibSedML/SedMLConsole/Web References/MIRIAM/MiriamWebServices.wsdl
A LibSedML/SedMLConsole/Web References/MIRIAM/
A LibSedML/SedMLConsole/SedMLConsole.csproj.user
A LibSedML/SedMLConsole/app.config
A LibSedML/SedMLConsole/SedMLConsole.csproj
A LibSedML/SedMLConsole/Resources
A LibSedML/SedMLConsole/Resources/ICON_MIASE.ico
A LibSedML/SedMLConsole/Program.cs
A LibSedML/SedMLConsole/Properties
A LibSedML/SedMLConsole/Properties/AssemblyInfo.cs
A LibSedML/SedMLConsole/Properties/Settings.settings
A LibSedML/SedMLConsole/Properties/Settings.Designer.cs
A LibSedML/SedMLConsole/Properties/Resources.resx
A LibSedML/SedMLConsole/Properties/Resources.Designer.cs
A LibSedML/3rdParty
A LibSedML/3rdParty/Microsoft.Scripting.ExtensionAttribute.dll
A LibSedML/3rdParty/LibRoadRunner.dll
A LibSedML/3rdParty/Microsoft.Scripting.dll
A LibSedML/3rdParty/IronPython.dll
A LibSedML/3rdParty/ICSharpCode.SharpZipLib.dll
A LibSedML/3rdParty/mathLibrary.dll
A LibSedML/3rdParty/CompareData.dll
A LibSedML/3rdParty/IronPython.Modules.dll
A LibSedML/3rdParty/ZedGraph.Web.dll
A LibSedML/3rdParty/Microsoft.Dynamic.dll
A LibSedML/3rdParty/SBMLSupport.dll
A LibSedML/3rdParty/libsbmlcsP.dll
A LibSedML/3rdParty/SBWCSharp.dll
A LibSedML/3rdParty/Microsoft.Scripting.Core.dll
A LibSedML/3rdParty/LibStructuralCSharp.dll
A LibSedML/3rdParty/Microsoft.Scripting.Debugging.dll
A LibSedML/3rdParty/ZedGraph.dll
A LibSedML/SedMLScript
A LibSedML/SedMLScript/ICON_MIASE.ico
A LibSedML/SedMLScript/MainForm.resx
A LibSedML/SedMLScript/SedMLScriptTest.csproj
A LibSedML/SedMLScript/MainForm.Designer.cs
A LibSedML/SedMLScript/Program.cs
A LibSedML/SedMLScript/icons
A LibSedML/SedMLScript/icons/run.png
A LibSedML/SedMLScript/MainForm.cs
A LibSedML/SedMLScript/Properties
A LibSedML/SedMLScript/Properties/AssemblyInfo.cs
A LibSedML/SedMLScript/Properties/Settings.settings
A LibSedML/SedMLScript/Properties/Settings.Designer.cs
A LibSedML/SedMLScript/Properties/Resources.resx
A LibSedML/SedMLScript/Properties/Resources.Designer.cs
A LibSedML/libSedML
A LibSedML/libSedML/Report.cs
A LibSedML/libSedML/Util.cs
A LibSedML/libSedML/ModelStore.cs
A LibSedML/libSedML/UniformTimeCourse.cs
A LibSedML/libSedML/TaskStore.cs
A LibSedML/libSedML/DataGenerator.cs
A LibSedML/libSedML/Parameter.cs
A LibSedML/libSedML/SedMLInfo.cs
A LibSedML/libSedML/Simulation.cs
A LibSedML/libSedML/Variable.cs
A LibSedML/libSedML/Change.cs
A LibSedML/libSedML/libSedML.csproj
A LibSedML/libSedML/Properties
A LibSedML/libSedML/Properties/AssemblyInfo.cs
A LibSedML/libSedML/DataGeneratorStore.cs
A LibSedML/libSedML/SedMLBase.cs
A LibSedML/libSedML/Output.cs
A LibSedML/libSedML/Model.cs
A LibSedML/libSedML/SimulationStore.cs
A LibSedML/libSedML/Task.cs
A LibSedML/libSedML/Plot2D.cs
A LibSedML/IronPythonScript
Checked out revision 4.
rupert@linux:~/Development> cd LibSedML/
rupert@linux:~/Development/LibSedML> ls
3rdParty libSedML Samples SEDML.sln
ICON_MIASE.ico libSedMLRunner SedMLConsole SedMLWeb
IronPythonScript libSedMLScript SedMLScript
rupert@linux:~/Development/LibSedML> mdtool build -c:Release
MonoDevelop Build Tool
Loading solution: ./SEDML.sln
Loading solution: ./SEDML.sln
Loading projects ..
Building: SEDML (Release)
Building Solution SEDML
Building: libSedML (Release)
Performing main compilation...
/usr/bin/gmcs /noconfig
dll" "/r:/home/rupert/Development/LibSedML/3rdParty/libsbmlcsP.dll"
"/r:System.dll" "/r:System.Data.dll" "/r:System.Xml.dll" /nologo
/warn:4 /optimize+ /codepage:utf8 /platform:x86 "/define:TRACE"
/t:library "/home/rupert/Development/LibSedML/libSedML/Change.cs"
Compilation succeeded - 1 warning(s)

/home/rupert/Development/LibSedML/libSedML/Util.cs(307,18): warning
CS0219: The variable `length' is assigned but its value is never used

Build complete -- 0 errors, 1 warning
Building: libSedMLRunner (Release)
Performing main compilation...
/usr/bin/gmcs /noconfig
"/r:System.dll" "/r:System.Data.dll" "/r:System.Drawing.dll"
"/r:System.Windows.Forms.dll" "/r:System.Xml.dll"
"/r:/home/rupert/Development/LibSedML/bin/libSedML.dll" /nologo
/warn:4 /optimize+ /codepage:utf8 /platform:x86 "/define:TRACE"
fo.cs" "/home/rupert/Development/LibSedML/libSedMLRunner/RunResult.cs"
Build complete -- 0 errors, 0 warnings
Building: SedMLConsole (Release)
Performing main compilation...
Compiling resource
x with /usr/bin/resgen2
/usr/bin/gmcs /noconfig
"/r:System.dll" "/r:System.Drawing.dll"
"/r:System.EnterpriseServices.dll" "/r:System.Web.Services.dll"
"/r:System.Windows.Forms.dll" "/r:System.Data.dll" "/r:System.Xml.dll"
"/r:/home/rupert/Development/LibSedML/bin/libSedML.dll" /nologo
/warn:4 /optimize+
co" /codepage:utf8 /platform:x86 "/define:TRACE" /t:winexe
igner.cs" "/home/rupert/Development/LibSedML/SedMLConsole/Web
Compilation succeeded - 1 warning(s)

warning CS0169: The private method
`SedMLConsole.Program.CreateSedMLProgramatically()' is never used

Build complete -- 0 errors, 1 warning
Building: libSedMLScript (Release)
Performing main compilation...
Compiling resource
esx with /usr/bin/resgen2
/usr/bin/gmcs /noconfig

.dll" "/r:System.dll" "/r:System.Core.dll" "/r:System.Xml.Linq.dll"
"/r:System.Data.DataSetExtensions.dll" "/r:System.Data.dll"
"/r:/home/rupert/Development/LibSedML/bin/libSedML.dll" /nologo
/warn:4 /optimize+ /codepage:utf8 "/define:TRACE" /t:library
cs" "/home/rupert/Development/LibSedML/libSedMLScript/SedMLScript.cs"
Build complete -- 0 errors, 0 warnings
Building: SedMLScriptTest (Release)
Performing main compilation...
WARNING: Assembly 'System.Deployment' not found. Make sure that the
assembly exists in disk. If the reference is required to build the
project you may get compilation errors.
Compiling resource
/home/rupert/Development/LibSedML/SedMLScript/MainForm.resx with
Compiling resource
with /usr/bin/resgen2
/usr/bin/gmcs /noconfig
"/r:System.dll" "/r:System.Core.dll" "/r:System.Xml.Linq.dll"
"/r:System.Data.DataSetExtensions.dll" "/r:System.Data.dll"
"/r:System.Drawing.dll" "/r:System.Windows.Forms.dll"
"/r:/home/rupert/Development/LibSedML/bin/libSedML.dll" /nologo
/warn:4 /optimize+
o" /codepage:utf8 /platform:x86 "/define:TRACE"
/main:SedMLScriptTest.Program /t:winexe
Build complete -- 0 errors, 1 warning
Building: SedMLWeb (Release)
Generating CodeBehind members...
Waiting for project type database to finish updating...
Object reference not set to an instance of an object
rupert@linux:~/Development/LibSedML> cd bin
rupert@linux:~/Development/LibSedML/bin> ls
CompareData.dll Microsoft.Dynamic.dll
ICSharpCode.SharpZipLib.dll Microsoft.Scripting.Core.dll
IronPython.dll Microsoft.Scripting.Debugging.dll
LibRoadRunner.dll Microsoft.Scripting.dll
libsbmlcsP.dll Microsoft.Scripting.ExtensionAttribute.dll
libSedML.dll SBMLSupport.dll
libSedMLRunner.dll SBWCSharp.dll
libSedMLScript.dll SedMLConsole.exe
LibStructuralCSharp.dll SedMLScriptTest.exe
mathLibrary.dll ZedGraph.dll
rupert@linux:~/Development/LibSedML/bin> cp ~/Development/sbwbuild/cvs-dl/libsbml/src/bindings/csharp/libsbmlcs* .
rupert@linux:~/Development/LibSedML/bin> ls
CompareData.dll mathLibrary.dll
ICSharpCode.SharpZipLib.dll Microsoft.Dynamic.dll
IronPython.dll Microsoft.Scripting.Core.dll
LibRoadRunner.dll Microsoft.Scripting.Debugging.dll Microsoft.Scripting.dll
libsbmlcsP.dll Microsoft.Scripting.ExtensionAttribute.dll
libsbmlcs.snk SBMLSupport.dll SBWCSharp.dll
libSedML.dll SedMLConsole.exe
libSedMLRunner.dll SedMLScriptTest.exe
libSedMLScript.dll ZedGraph.dll
rupert@linux:~/Development/LibSedML/bin> cp ~/SBW-2.7.10/CSharp/libcvode*.so .
rupert@linux:~/Development/LibSedML/bin> cp ~/SBW-2.7.10/CSharp/ .
rupert@linux:~/Development/LibSedML/bin> cp ~/SBW-2.7.10/CSharp/lib libsbl2SBML.dll libsbmlcsP.dll
rupert@linux:~/Development/LibSedML/bin> cp ~/SBW-2.7.10/CSharp/libLib*.so .
rupert@linux:~/Development/LibSedML/bin> ls
CompareData.dll libSedMLRunner.dll
ICSharpCode.SharpZipLib.dll libSedMLScript.dll
IronPython.dll LibStructuralCSharp.dll mathLibrary.dll Microsoft.Dynamic.dll Microsoft.Scripting.Core.dll Microsoft.Scripting.Debugging.dll Microsoft.Scripting.dll
LibRoadRunner.dll Microsoft.Scripting.ExtensionAttribute.dll SBMLSupport.dll
libsbmlcsP.dll SBWCSharp.dll
libsbmlcs.snk SedMLConsole.exe SedMLScriptTest.exe
libSedML.dll ZedGraph.dll
rupert@linux:~/Development/LibSedML/bin> mono ./SedMLConsole.exe ../Samples/lorenz.miase

The Results

This will result in the Lorenz Attractor simulated, and you should see:

Screen shot 2010-03-08 at 7.10.19 PM

I hope this gave a little over view in how to compile the library at this stage. I’ve archived the resulting binary and uploaded it to SF:

Nested Simulation Experiments

A couple of days ago, I posted a proposal for a Nested Simulation Experiment for SED-ML. There I proposed that instead of defining a new Simulation class for each experiment you’d like to run, it would be better for implementers and modelers alike to be able to compose simulation experiments out of primitives. That is instead of defining:

  • a TimeCourse Simulation experiment like this:

    <timeCourse id="s1" name="time course definition" algorithm="KiSAO:0000019">
    <uniformRange start="0" end="100" numberOfPoints="10" />
  • and next like this:

    <timeCourse id="s1" name="time course definition" algorithm="KiSAO:0000019">
    <value> 1 </value>
    <value> 4 </value>
    <value> 10 </value>
    <value> 23 </value>
    <value> 42 </value>

one could compose these same experiments with primitives. (Just as an aside, note that in the cases above a simulator supporting the simulation experiment would have to implement a different set of operations).

The Primitives

I would envision three primitives:

  • OneStep: this calculates one further output step for the model from its current state. Note that this does NOT have to mean one integration step. The simulator is allowed to take as many steps as needed, all that has to be fulfilled with this simulation class, is that, at the end, the desired output time is reached.
  • SteadyState: This brings the model from its current state to a steady state. This simulation class will also just provide one output row for attached data generators, the state of the model at steady state.
  • SetValue: This is not a simulation class, but rather a convenience function, to change a model variable/parameter. In this way it is akin to ChangeMath / ChangeAttribute / ChangeXML we would have to discuss the actual syntax of it.

These primitives then are used in a nested simulation experiment to describe virtually any simulation experiment. Through the nested class construct. This construct allows to refer to:

  • A task object, which defines the model and simulation experiment to be called repeatedly,
  • A range object, which defines how often the simulation task above is to be called,
  • A SetValue construct describing how model variables are to be changed. Note:that the SetValue construct will have to be able to refer to the ranges current value.

Additionally, flags would indicate, whether the model is supposed to be reset after each run or not.


So far the proposal, so how would this look in an example. Lets go through each one and make up some examples as we go along.

  • OneStep: This is a simulation class, causing the model time variable to be adapted from the current time with a given step (that determines where the desired output point is):

    <oneStep id="s1" algorithm="KiSAO:0000019" step="0.1"/>

    when used in a task, this simulation task simulates the model from 0 to 0.1. The data generators are supposed to be calculated to yield the desired outputs for time point 0.1.
  • SteadyState: This is another simulation class, so we would define it as such. Unfortunately KISAO does not currently describe any steady state solvers and instead mostly integrators. So suppose in the following that:

    KISAO:0000099 = steady state solver (it would probably somewhere below KISAO:0000018)

    <steadyState id="s2" algorithm="KiSAO:0000099" />

    when used in a task, this simulation task brings the model to steady state. Once finished the data generators are supposed to be calculated to yield the desired output points for the model variables at steady state.
  • NestedSimulation: So how would this now look in a nested simulation experiment:
  • <listOfSimulations>
        <nestedSimulation id="s3" algorithm="KiSAO:0000019"
                             resetModel="false" originalTask="task1">
             <value> 1 </value>
            <value> 4 </value>
            <value> 10 </value>
        <setValue target="/sbml/model/listOfParameters/parameter[@id='w']">
             <variable id="current" name="current range value" target="#current" />

    The nested simulation above, would carry out task1 3 times. Each time the value of a model parameter ‘w’ is varied by applying one of the three values.  If task1 specifies a steady state primitive, then this snippet produces the steady state values for w=1, w=4 and w=10.

    Or we could have used a uniform range to sweep the parameter. Or a functional range, to vary the parameter in logScale for example.

    If task1 would refer to a uniformTimeCourse Simulation then this would actually perform a simulation, where a parameter is changed in steps. After each time we would see how the model reacts to this discrete parameter change.

Note that you could even define a uniform time course simulation using this approach. Here task1 refers to a ‘oneStep’ simulation task. We would just vary the models time each time:

    <nestedSimulation id="s3" algorithm="KiSAO:0000019"
                         resetModel="false" originalTask="task1">
    <uniformRange start="0" end="100" numberOfPoints="10" />
    <setValue target="#time">
         <variable id="current" name="current range value" target="#current" />

You could even think about nesting the nestedSimulation experiments in order to for example perform 2D parameter scans or what have you.


Defining simulation experiments through these primitives will open up SED-ML and make it really useful. These primitives are easy to implement. In fact they are already implemented in available simulators. They are what is needed to implement the proposed Range construct anyway.

So let us not be shackled by having to each time define a new simulation class. The nested approach here will be what is needed to define most simulation experiments. By adding new primitives later on it can be easily extended.

I’m perfectly happy to open it up further. What one could envision would be multiple <setValue> elements to change multiple parameters. or even multiple ranges, though then each would have to have an id, to be used in the SetValue constructs. But I’m sure it could be sorted out.

Wednesday, March 3, 2010

Supporting SED-ML

SED-ML, the Simulation Experiment Description – Markup Language, offers the possibility to exchange simulation experiments. That is, instead of receiving a model and wondering how you can make it do what it is supposed to do, you would simply run the accompanying SED-ML document and see the figures reproduced.


As with any new standards initiative, it will only be taken up if there are computational resources, that make it easy to use, and of course if the standard can be helpful. Currently, with SED-ML in a very early stage it is already possible to exchange time course simulation experiments, but not much more. However, it could be extended easily, such as by using a Nested Simulation Experiment, as described at the link below.

But what about computational resources? As it so happens, I’ve created a new project:

LibSedML - 

There, I provide three libraries:

  • LibSedML – a .NET library for reading and writing SED-ML
  • LibSedMLRunner  – a library on top of LibSedML, that schedules and runs simulation experiments.
  • LibSedMLScript – a utility library, turning a human readable script format into SED-ML.

Three applications support these libraries so far:

  • SED-ML Script: This application provides an easy way to define new Simulation Experiments using the human readable script format. No more struggling with API calls or XML, a simple script defines a simulation experiment. It can also be readily tested right then and there.
  • A web application provides the same functionality and provides a test bed, without having to download any software.
  • A plug-in for the SBW Simulation Tool, allows to run SED-ML files directly from it and provides capabilities for saving simple simulation experiments. (screenshot at beginning of this post)

The libraries and tools have been implemented using .NET, and have been confirmed to run fine on Windows, Linux and OS X!


Bergmann, Frank. A Simple Nested Simulation for SED-ML. Available from Nature Precedings <> (2010)

Saturday, February 13, 2010

RoadRunner & C++/CLI vs. Embedding the MONO Runtime

RoadRunner, our simulation main simulation engine in the Systems Biology Workbench, has been written in C#. This allows RoadRunner to be used in scripting scenarios with languages like IronPython, or even from the csharp-shell or Windows PowerShell. But what if you wanted to use RoadRunner from plain old C / C++?

C++ / CLI

On Windows operating systems the obvious choice would probably be C++/CLI.  And really, the task could not be easier. Just add the RoadRunner reference to the application include the RoadRunner namespace and you are good to go:

   1: // RoadRunnerCLI.cpp : main project file.


   3: #include "stdafx.h"


   5: using namespace System;

   6: using namespace CSharpSimulator;


   8: static void PrintResult(cli::array<double, 2>^ data)

   9:     {

  10:         for (int i = 0; i < data->GetLength(0); i++)

  11:         {

  12:             for (int j = 0; j < data->GetLength(1); j++)

  13:             {

  14:                 Console::Write(data[i,j]);

  15:                 Console::Write("\t");

  16:             }

  17:             Console::WriteLine();

  18:         }

  19:     }


  21: int main(array<System::String ^> ^args)

  22: {


  24:     sbwInterface roadRunnerInstance;


  26:     roadRunnerInstance.loadSBMLFromFile

  27:         (L"C:\\Users\\fbergmann\\Documents\\SBML Models\\BorisEJB.xml");

  28:     roadRunnerInstance.setTimeStart(0.0);

  29:     roadRunnerInstance.setTimeEnd(100.0);

  30:     roadRunnerInstance.setNumPoints(11);


  32:     cli::array<double, 2>^ result = roadRunnerInstance.simulate();


  34:     PrintResult(result);


  36:     return 0;

  37: }

The only drawback would be that this will not work on Linux or OS X.

MONO Embedding

So what about MONO Embedding? Or in other words, writing a C++ application, that would embed the MONO Runtime. This enables the C++ application to directly reference RoadRunner. The idea is basically the same as when using any SBW Module. First we get a hold of the RoadRunner module, or in this case an instance of the RoadRunner class:

   1: mono_set_dirs(NULL, NULL);

   2: domain = mono_jit_init ("LibRoadRunner.dll");

   3: mono_set_dirs(NULL, NULL);

   4: mono_config_parse(NULL);

   5: assembly = mono_domain_assembly_open (domain, "LibRoadRunner.dll");

   6: if (assembly == NULL)

   7:     cout << "Couldn't load RR assembly" << endl;

   8: image = mono_assembly_get_image (assembly);

   9: rr_class = mono_class_from_name (image, "CSharpSimulator", "sbwInterface");

  10: if (rr_class == NULL)

  11:     cout << "Couldn't get hold of the RoadRunner class" << endl;


  13: // create new roadRunner instance

  14: rr_instance = mono_object_new (domain, rr_class);   

  15: // call constructor

  16: mono_runtime_object_init (rr_instance);

Next one would get hold of all the method one would like to call, as in:

   1: // get the loadSBML 

   2: methodLoadSBML = mono_class_get_method_from_name(rr_class, "loadSBML", -1);

   3: if (methodLoadSBML == NULL) 

   4:     cout << "Couldn't get loadSBML" << endl;


finally for calling the method all that’s needed is to wrap the arguments into arguments that MONO would understand:

   1: void HostRR::LoadSBML(const char* model)

   2: {

   3:     MonoString *str = mono_string_new (domain, model);

   4:     void *args[1]; args[0] = str; 

   5:     MonoObject *exception = NULL;

   6:     mono_runtime_invoke(methodLoadSBML, rr_instance, args, &exception);

   7:     if (exception != NULL)

   8:     {

   9:         PrintException("Error while loading SBML", exception);

  10:     }

  11: }

continuing like that for the remaining methods that have to be available for C++. For a client calling into RoadRunner the result would look like this:

   1: #include "HostRR.h"

   2: #include <iostream>

   3: #include <iomanip>


   5: using namespace std;


   7: void PrintResult(double** data, int numRows, int numCols)

   8: {

   9:     if (data == NULL) return;


  11:     for (int y = 0; y < numRows; y++) 

  12:     {

  13:         for (int x = 0; x < numCols; x++) 

  14:         {

  15:             cout << setiosflags(ios::fixed) 

  16:                  << setw(7) << setprecision(2) << setfill(' ') 

  17:                  <<  data[y][x] << "\t";

  18:         }

  19:         cout << endl;

  20:     }

  21:     cout << endl;

  22: }


  24: int main(int argc, char* argv[])

  25: {

  26:     HostRR instance;


  28:     instance.LoadSBMLFromFile("BorisEJB.xml");


  30:     instance.SetTimeStart(0.0);

  31:     instance.SetTimeEnd(1100.0);

  32:     instance.SetNumPoints(100);


  34:     int numRows; int numCols;

  35:     double** result = instance.Simulate(&numRows,&numCols);


  37:     PrintResult(result, numRows, numCols);


  39:     return 0;

  40: }

And the advantage? It runs like a charm on Linux and OS X. However I did struggle a bit with getting it compiled. After all one draws several dependencies when embedding mono, the most troublesome for me proved to be glib2 and OS X. At the end the problem turned out to be that Snow Leopard liked the executable to be 64bit by default, but the glib libraries were only available for 32bit and ppc. Since I have Qt installed on all my systems, I used a qmake project, to generate the make files (or Xcode projects as the case may be). So here is what worked for me:


   2: TEMPLATE = app

   3: CONFIG = console

   4: TARGET = HostRR

   5: DEPENDPATH += .

   6: INCLUDEPATH += . 


   8: mac { 

   9: CONFIG += x86 

  10: CFLAGS += -arch i386

  11: INCLUDEPATH += /Library/Frameworks/Mono.framework/Versions/2.6.1/include/mono-1.0 /sw/include/glib-2.0 /sw/lib/glib-2.0/include

  12: LIBS += -L/Library/Frameworks/Mono.framework/Versions/2.6.1/lib -L/sw/lib -pthread -lmono -lpthread -lm -lgthread-2.0 -lglib-2.0 -lintl

  13: }


  15: unix { 

  16: DEFINES +=_REENTRANT -pthread 

  17: INCLUDEPATH += /usr/include/mono-1.0 /usr/include/glib-2.0 /usr/lib/glib-2.0/include

  18: LIBS += -Wl,--export-dynamic -pthread -lmono -ldl -lpthread -lm -lgthread-2.0 -lrt -lglib-2.0 

  19: }


  21: win32 {

  22: INCLUDEPATH += "C:\Program Files (x86)\Mono-2.6\include\glib-2.0"  "C:\Program Files (x86)\Mono-2.6\lib\glib-2.0\include" "C:\Program Files (x86)\Mono-2.6\include\mono-1.0"

  23: LIBS +=  -L"." -lmono

  24: }


  26: # Input

  27: HEADERS += HostRR.h

  28: SOURCES += HostRR.cpp main.cpp


If you’d like to give it a try, I’ve posted all the source to sourceforge. The results are right here:


We’ve seen, that accessing a .NET assembly from C/C++ is really no issue at all. C++/CLI is a great language it provides access to all of the .NET framework in a snap, however it will lock you in to the Windows world. With MONO Embedding, it is easy to break out! Given the reflection capabilities of .NET I believe the way to go forward would be to have a wrapper generator, that would just write the wrapper code.

Going forward if I were to use C++ to interact with RoadRunner, I’d probably combine the best of two worlds by falling back to C++/CLI on Windows systems and Mono embedding on Linux / OS X. But this might be a personal preference.