Download Links

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

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. 

Tuesday, February 9, 2010

Computational Tools for the Annotation of SBML Models

I was asked to give a brief talk  for the Semantic Web in Biomedicine Seminar, on computational tools that make the task of using all the great ontologies (like MIRIAM, SBO, ChEBI, UniProt, KEGG) that we have come to love easier.

I will add the full presentation below. However, as always without all too much text, thus I’m going to continue below.

I’m deeply involved with the Systems Biology Workbench (SBW), a lightweight framework that enables applications to share their functionality regardless of operating system or programming language. With SBW we also deliver a full toolset for modeling, simulating and analyzing SBML models. About five years back we started to get involved with SBGN. So today it would be great if we could automatically generate SBGN diagrams out of our SBML models. What is needed for that are annotations. Not just any annotations but annotations in the form of SBO ( the material entity branch) would be perfect. Unfortunately this is not quite enough. Additional MIRIAM annotations are needed for example to describe complexes in more detail.

I’ve been looking at this for some time and there are a couple of interesting developments to mention, of course first and foremost the EBI Web Services. They certainly make the work much easier. I introduce the:

  • BioModels Web Service
  • SBO Web Service
  • MIRIAM Web Service
  • Ontology Lookup Web Service

Each web service is briefly tested, using a Generic Soap Client, as this will allow to show the sort of information that is being provided first hand.

Of course it would be great if one would not have to hunt each Web Service down and it would seem that others had the same idea. I mention libAnnotationSBML first, a neat Java library that promises to provide a unified interface for a whole list of web services:


(photo grabbed from Neil’s presentation on Slideshare). The only drawback I could find with it is that the library is IMHO not quite ready to use by non Java geniuses. Everyone hearing me: If you are developing a library … especially a library for Java / .NET or any of the other cross platform virtual machines … please please provide a binary for people to use.  It’s been a while that I worked with Java, and an ant build script that won’t work is trouble for me. As it turned out the build failed because just of a couple of missing jar files and a test failure due to changes in the SBO. Still at the end of it all I ended up with a jar file and no instructions on what to do with it. I’ve seen great demos of libAnnoationSBML with the SBMLReactionBalancer for example. This could be made available online as binary as is …

The presentation will go on to introduce SAINT: a lightweight integration environment for model annotation. It follows the same great idea as in libAnnoationSBML of hunting down the individual web services for annotations of your SBML file. However, whereas libAnnotationSBML is a Java library, SAINT is nifty web application based on the Google Web Toolkit(GWT). As such it really brings a long a snappy AJAX UI. SAINT has a lot of potential, but again it would seem I was out of luck, I could not manage to get a model annotated. Here is what went wrong: a) no upload button, but that is fine copying the SBML to clipboard and pasting it was not all that hard b) once I clicked “Annotate” however a whole bunch of Asynchronous worker bee's must have been sent out in order to fetch all my new Annotations. But when they came back they brought along a whole list of annotations I had no interested in:


The above image represents all the results found for “glucose”. And while it is great to find so many Pathway Commons Identifiers, the link to Pathway Commons lead to 404. The trick seems to be for me to disable the “New Reactions” checkbox in advanced options. Then I received a couple of SBO terms for my model, however not much more. But SBO terms are a good start, so from here I went to the “Get Annotated Model Code” tab, but try as I might I was never able to actually retrieve my annotated model. 


Looking at other currently available software tools like CellDesigner and COPASI, both tools that support MIRIAM annotations I am not sure whether users of the tools will take full advantage of the Annotation process. Thus I end the presentation with a couple of screenshots of software tools using the EBI Web Services, to interact with the BioModels Database, resolve the publication citation and visualize the annotations in a way better suited to the community.


Why should we just display the ChEBI identifiers, when we could just as well show a formula, or the name, with a click revealing the full set of annotations.