sbmlsolver-discuss — support and discussion for the SBML ODE Solver Library

Re: [SOSlib-discuss] Some typos in SBML_odeSolver (CVS HEAD)

[Rainer M. <ra...@tb...>]

Dear Takeshi-san,

Thanks! I will correct this in CVS code.

Rainer


On 04/12/2010 07:25 AM, Takeshi Abe wrote:
> Hi all,
> 
> I am learning SBML on my job, and happy to see that SOSLib is very useful
> to reduce an SBML model to a set of ODEs.
> Playing with the CVS HEAD of SOSLib, I have found some typos in its
> code base:
> 
> Index: src/odeModel.c
> ===================================================================
> RCS file: /cvsroot/sbmlsolver/SBML_odeSolver/src/odeModel.c,v
> retrieving revision 1.129
> diff -u -r1.129 odeModel.c
> --- src/odeModel.c	1 Apr 2009 20:23:28 -0000	1.129
> +++ src/odeModel.c	12 Apr 2010 05:05:19 -0000
> @@ -1585,7 +1585,7 @@
>  }
>  
>  
> -/** \brief Returns the total number of values in oodeModel, equivalent
> +/** \brief Returns the total number of values in odeModel, equivalent
>      to ODEModel_getNeq + ODEModel_getNumAssignments +
>      ODEModel_getNumConstants
>  */
> @@ -2518,7 +2518,7 @@
>  
>  /** \brief Creates and returns a variable index for ith assigned variable.
>  
> -Returns NULL if not existing (i > ODEModel_getNumAssignedVar(om)).
> +Returns NULL if not existing (i > ODEModel_getNumAssignments(om)).
>  The variableIndex must be freed by the calling application.
>  */
>  
> Index: src/sbmlsolver/integratorSettings.h
> ===================================================================
> RCS file: /cvsroot/sbmlsolver/SBML_odeSolver/src/sbmlsolver/integratorSettings.h,v
> retrieving revision 1.40
> diff -u -r1.40 integratorSettings.h
> --- src/sbmlsolver/integratorSettings.h	27 Mar 2009 15:55:03 -0000	1.40
> +++ src/sbmlsolver/integratorSettings.h	12 Apr 2010 05:05:19 -0000
> @@ -191,7 +191,6 @@
>    SBML_ODESOLVER_API void CvodeSettings_setDetectNegState(cvodeSettings_t *, int);
>    SBML_ODESOLVER_API void CvodeSettings_setTStop(cvodeSettings_t *, int);
>    SBML_ODESOLVER_API void CvodeSettings_setCompileFunctions(cvodeSettings_t *, int);
> -  SBML_ODESOLVER_API void CvodeSettings_setResetCvodeOnEvent(cvodeSettings_t *, int);
>  
>    /* Adjoint setttings */
>    SBML_ODESOLVER_API void CvodeSettings_setDoAdj(cvodeSettings_t *);
> 
> 
> (The last hunk just removes a duplidate declaration.)
> 
> Cheers,
> -- Takeshi Abe
> 
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> sbmlsolver-discuss mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbmlsolver-discuss

[SOSlib-discuss] Some typos in SBML_odeSolver (CVS HEAD)

[Takeshi A. <ta...@fi...>]

Hi all,

I am learning SBML on my job, and happy to see that SOSLib is very useful
to reduce an SBML model to a set of ODEs.
Playing with the CVS HEAD of SOSLib, I have found some typos in its
code base:

Index: src/odeModel.c
===================================================================
RCS file: /cvsroot/sbmlsolver/SBML_odeSolver/src/odeModel.c,v
retrieving revision 1.129
diff -u -r1.129 odeModel.c
--- src/odeModel.c	1 Apr 2009 20:23:28 -0000	1.129
+++ src/odeModel.c	12 Apr 2010 05:05:19 -0000
@@ -1585,7 +1585,7 @@
 }
 
 
-/** \brief Returns the total number of values in oodeModel, equivalent
+/** \brief Returns the total number of values in odeModel, equivalent
     to ODEModel_getNeq + ODEModel_getNumAssignments +
     ODEModel_getNumConstants
 */
@@ -2518,7 +2518,7 @@
 
 /** \brief Creates and returns a variable index for ith assigned variable.
 
-Returns NULL if not existing (i > ODEModel_getNumAssignedVar(om)).
+Returns NULL if not existing (i > ODEModel_getNumAssignments(om)).
 The variableIndex must be freed by the calling application.
 */
 
Index: src/sbmlsolver/integratorSettings.h
===================================================================
RCS file: /cvsroot/sbmlsolver/SBML_odeSolver/src/sbmlsolver/integratorSettings.h,v
retrieving revision 1.40
diff -u -r1.40 integratorSettings.h
--- src/sbmlsolver/integratorSettings.h	27 Mar 2009 15:55:03 -0000	1.40
+++ src/sbmlsolver/integratorSettings.h	12 Apr 2010 05:05:19 -0000
@@ -191,7 +191,6 @@
   SBML_ODESOLVER_API void CvodeSettings_setDetectNegState(cvodeSettings_t *, int);
   SBML_ODESOLVER_API void CvodeSettings_setTStop(cvodeSettings_t *, int);
   SBML_ODESOLVER_API void CvodeSettings_setCompileFunctions(cvodeSettings_t *, int);
-  SBML_ODESOLVER_API void CvodeSettings_setResetCvodeOnEvent(cvodeSettings_t *, int);
 
   /* Adjoint setttings */
   SBML_ODESOLVER_API void CvodeSettings_setDoAdj(cvodeSettings_t *);


(The last hunk just removes a duplidate declaration.)

Cheers,
-- Takeshi Abe

Re: [SOSlib-discuss] crash on AIX since cvs 2009-02-14[Scanned]

[Eric F. <efe...@ph...>]

 

> -----Original Message-----
> From: Eric Fernandez [mailto:efe...@ph...] 
> Sent: 30 March 2009 11:39
> To: sbm...@li...
> Subject: [SOSlib-discuss] crash on AIX since cvs 2009-02-14[Scanned]
> 
> Hi,
> 
> As I reported earlier, I have noticed a segfault when using 
> the CVS version (it segfaults when trying to display the 
> model using odeSolver -e model.xml). This occurred between 
> the 2009-02-13 (which is working) and 2009-02-14 (segfault).
> 
> The differences are in 3 files:
> 
> src/Makefile.am
> configure.in
> config/sundials.m4
> 
> The notable change is using sundials_ida by default (?) 
> instead of kinsol. Maybe there is a problem on AIX with it. 
> But if it is so, why would odeSolver crash when simply trying 
> to display the model (odeSolver
> -e) ?
> 
> Thanks,
> Eric
> 

Hi,

I'll answer to myself, because I identified the problem. Although very
specific to my configuration, this may interest other people.

I use gcc-4.3.4 on AIX 5.3, which was compiled with those options:
bash-2.05a$ gcc -v
Using built-in specs.
Target: powerpc-ibm-aix5.3.0.0
Configured with: $HOME/gnusrc/gcc-4.3.4/configure --enable-threads
--enable-languages=c,c++ --prefix=$HOME/gnu --enable-threads
--disable-shared --enable-version-specific-runtime-libs --disable-nls
--with-gmp=$HOME/gnu --with-mpfr=$HOME/gnu
Thread model: aix
gcc version 4.3.4 (GCC) 

Note that this gcc version is compiled with --disable-shared (btw, gcc
4.4 branch has an issue with it on AIX, so it recommended to stick to
the 4.3 branch). Since 2009-02-14 CVS of SOSlib, Makefile.am has been
changed to revision 1.29: "changed automake/autoconf framworke to
produce both static and shared library".

Therefore if you want SOSlib to work on AIX with a gcc version with only
static libraries, you also need to compile SOSlib with static libraries,
using:

 ./configure --prefix=$PREFIX --with-libsbml=$PREFIX
--with-sundials=$PREFIX --with-libxml2=$PREFIX --disable-shared

Otherwise odeSolver segfaults at runtime.
Eric

Re: [SOSlib-discuss] splitting soslib functionality, and high-performance computing

[Allan, B. <ba...@sa...>]

Hi,

Rainer wrote:
> 
> Hi Ben,
> 
> moving this discussion to the list, in case anyone else is interested.
> 
> On Mon, 2009-09-28 at 11:33 -0400, Ben Allan wrote:
> > I'm glad to hear there's still an active community around SOSlib.
> >
> > I'm working on a project which really wants to provide its own
> > drivers for montecarlo and ode/dae solutions, but to use
> > the fairly nice model evaluation engine you all have developed.
> 
> So you are only interested in the SBML -> ODEModel part, but not the
> Sundials wrapper, correct?

The current sundials wrapper is sufficiently entangled with the model that it's hard
to persuade the customer that it would be easy to bring into the
code base and maintain. We're also fairly expert in sundials locally,
so the inclination is to reinvent (and in some cases to use something
other than sundials). It would be really nice if there was a clean
rootstopping dae model interface defined, but it appear we would need
to contribute that. 

> Two things, first for the SBML -> ODEModel: we plan to formalize that
> approach, and introduce a stoichiometryMatrix object as an 
> intermediate
> between SBML and ODE system. This should allow easier integration with
> reaction-network-based model reduction algorithms, or general reaction
> network analysis tools. Don't know if you would be interested in this
> topic too. Probably most of these algorithms already exist somewhere
> with SBML-to-SBML interfaces, but I think it would be a natural
> extension for SOSlib.

I like the idea of exposing the stoichiometry matrix and the 
list of rates-of-progress (instead of just the RHS of the ode/dae).

> Second a bit of advertising for the integrator part of SOSlib 
> - although
> from what you say, you probably really want to use your own solver
> wrappers. Anyways, we do have a separate library which for unresolved
> licensing issues is not part of SOSlib (yet?), but uses our sundials
> wrappers for efficient parameter estimation (fitting experimental data
> stored in the same format as the soslib's commandline tool odeSolver
> output), both global and local.
> Once the error handling is moved to isntances instead of global, all
> should be set up for nice parallel usage.

As you say, licensing issues.
And of course the research content isn't solving ode's, the research is in solving
ugly parameter estimation problems. The research is really in the
modeling and results, not in the numerical engines, but
people always seem to get caught up in hiding their easy to reinvent source code
hoping to make money off it somehow. 

> >
> > A little report on what i've done so far in modifying the code in my
> copy:
> > () getting it to work with libsbml 4 (2.4 sbml spec).
> 
> Nice, are there many changes required?

Several places where libsbml now expects to be passed
2 integer arguments (e.g. Model_create(2,4); // version 2.4 sbml
I'll post a diff eventually. It also has added a feature for the
modeler to tell the solvers when a model is stiff (fast reactions)
and the integrator needs to be tuned accordingly.

> We once had a complete separation of structures, but due to some
> problems with compilation we got rid of it again. Can't remember what
> the problem exactly was, but in principle we wouldn't mind splitting
> into public and private headers again.

Good. I've done so. I'm working on (may have completed today) being
able to call on your odeModel without seeing all the tangled details
of your cvode and code generator headers. The key to this is a style
they use well in libsbml-- create a header which forward declares
all the public struct typedefs without exposing the struct contents.
All the public functions requiring pointers to these types are
happy at compile time now. This style cannot be used to hide the
contents of an enum-- I found that commented about in your code
someplace. But the enums aren't particularly needed outside soslib
as far as I can tell.

> BTW, we have biology, chemistry, physics and mathematics background,
> resp., so there is no dedicated computer scientist involved. Andrew
> Finney was the computer scientist (involved in SBML and libSBML once)
> who pushed the whole thing towards a library and would also have
> preferred C++ interfaces. Unfortunately none of us really speaks C++
> currently. But especially the interfaces (input settings and result
> structures) would probably be much easier to maintain and wrap in C++.
> CUDA sound great.

C++ doesn't have to be at all un-C-like-- see libsbml for a nice
clean example of an fairly complex interface that looks nice
in c and c++ and html. On a different project I have a bunch of people 
who think in fortran and write correspondingly fortran-like c++;
you can use as little of c++ as you like in a given project.

> Sourceforge repository is master. Do you want developer 
> access? I'd have
> to wait for internal discussion though.
> And in principle significant changes should be discussed on the list
> before submitting of course.

Especially since you clearly have your own development schedule,
I suspect the only way to proceed sanely would be making an alternate
c++-friendly version directory in your repository. You could then
look at the code I put in and decide which features you want to
migrate to your main code. I could (and if requested will) just
post a patch file to the mailing list or privately, but it's 
getting to be a pretty big patch. You can find me elsewhere on
sourceforge under the id ballan (cca-forum, bocca).
 
> > Would you be interested in splitting soslib internally
> > (or publically)
> > into an smbl evaluation engine library with a separate library of
> > integrations/statistical
> > methods on top of it?
> 
> Do you mean separate packages and build structures for these
> functionalities, or separate CVS branches? I wouldn't know how that
> works.
> In principle, we wouldn't oppose splitting into two libraries. As
> mentioned above, we have plans for extending the SBML<->ODE part and
> linking it with pure reaction network analysis, separate from the
> sundials wrappers, and on the other hand we already have an additional
> separate library build on top of the sundials integration and like to
> keep it general. Making it more modular is certainly in our interest.
> 
> But as said in the first email, our main limitation currently 
> is time :(

That's where open-source comes in-- free time obtained from other people.
I'm in the process of splitting out the odemodel and friends and
can contribute all that back if someone will use it or if you're
simply willing to host it for others even if you're unwilling to use it.

I can/will test all that change against odeSolver and examples/ before committing it
anywhere, but obviously I can't test or update other dependent code which isn't
in the public repository. So if one tried to use my new stuff with the non-public
dependent code, it would all be 'broken' and the typical gut reaction would
be "ah, the new guy just writes crap".  

For plain old c (and c++) simply splitting models and solvers into separate
directories (sharing only opaque pointer types) could be fairly simple.
The change to the build system would be fairly small.

You *might* chose to use a CVS branch for this, but I'm not a big fan of
CVS branches-- cvs doesn't really provide enough support for branching,
compared to SVN and newer systems.

thanks
Ben Allan 

[SOSlib-discuss] splitting soslib functionality, and high-performance computing

[Rainer M. <ra...@tb...>]

Hi Ben,

moving this discussion to the list, in case anyone else is interested.

On Mon, 2009-09-28 at 11:33 -0400, Ben Allan wrote:
> I'm glad to hear there's still an active community around SOSlib.
> 
> I'm working on a project which really wants to provide its own
> drivers for montecarlo and ode/dae solutions, but to use
> the fairly nice model evaluation engine you all have developed.

So you are only interested in the SBML -> ODEModel part, but not the
Sundials wrapper, correct?

Two things, first for the SBML -> ODEModel: we plan to formalize that
approach, and introduce a stoichiometryMatrix object as an intermediate
between SBML and ODE system. This should allow easier integration with
reaction-network-based model reduction algorithms, or general reaction
network analysis tools. Don't know if you would be interested in this
topic too. Probably most of these algorithms already exist somewhere
with SBML-to-SBML interfaces, but I think it would be a natural
extension for SOSlib.

Second a bit of advertising for the integrator part of SOSlib - although
from what you say, you probably really want to use your own solver
wrappers. Anyways, we do have a separate library which for unresolved
licensing issues is not part of SOSlib (yet?), but uses our sundials
wrappers for efficient parameter estimation (fitting experimental data
stored in the same format as the soslib's commandline tool odeSolver
output), both global and local.
Once the error handling is moved to isntances instead of global, all
should be set up for nice parallel usage.

In principle, the IntegratorInstance was designed so that ideally any
integrator can be plugged in (currently it only distinguishes SBML
models which have only assignment rules and no ODEs, but we'd like to
wrap sundials' IDA (DAE) solver, and keep it open for stochastic solvers
as well). Also, if the current wrapper of SUNDIALS is too overloaded for
high-performance stuff one could think of a stripped down version not
capable of re-initiation or the sensitivity and adjoint solvers (or
three dedicated wrappers for forward, sensitivity and adjoint
integration).

> 
> I did notice the code generation bit in your system; I did some fairly
> similar work for the ascend4 system back in the late 1990s while
> I was at school.

For clarification, there are currently two code generation systems. The
old one just writes the sundials right-hand-side functions as C-code
into a string buffer and compiles this as a dynamic library using the C
compiler used for compilation of the code (gcc et al.). Then the dynamic
library is loaded and pointers to these functions are passed to sundials
(see src/compiler.c). 
The second is really generation of internal compiler machine code
(currently only for intel processors, 32 and 64bit) for each equation
(from libSBML abstract syntax tree), and the hard-coded right-hand-side
function calls this dynamically compiled code for each equation of the
system (see src/arithmeticCompiler.c).

> 
> Is there a proper forum (mailing list? wiki?) for soslib that i might
> join, or is the email reply chain the preferred option to continue
discussing?

Yes, there is, and there are a few people subscribed who were using
soslib on or are interested in high-performance computation and might
also be interested in the above info. If you don't mind I could re-send
this email to sbm...@li...
or you could reply to this email directly to the list after subscribing
at
https://lists.sourceforge.net/lists/listinfo/sbmlsolver-discuss

> 
> A little report on what i've done so far in modifying the code in my
copy:
> () getting it to work with libsbml 4 (2.4 sbml spec).

Nice, are there many changes required?

> () making most of the ODEModel header private instead of public (C-
> style-- splitting it into
> ODEModel_pub.h with more accessor functions, and ODEModel_priv.h with
> the struct bodies).

We once had a complete separation of structures, but due to some
problems with compilation we got rid of it again. Can't remember what
the problem exactly was, but in principle we wouldn't mind splitting
into public and private headers again. 

> () running continously with valgrind to check for insanities.

I use valgrind to, on the command-line tool and the programs in the
example folder, but we unfortunately don't have a dedicated testing
framework.

> 
> After I get the application prototype finished for my client, I'm
hoping
> they will approve further development to make it more maintainable
> and perhaps to upgrade to sbml 3. In particular, the downstream
> users are NOT going to be strong C programmers, so conversion/wrapping
> to a completely c++ interface (preferably complete implementation)
> is of great interest. Then moving on to run on something like CUDA
> would require exactly the code generation approach you already have in
> place.
> 

BTW, we have biology, chemistry, physics and mathematics background,
resp., so there is no dedicated computer scientist involved. Andrew
Finney was the computer scientist (involved in SBML and libSBML once)
who pushed the whole thing towards a library and would also have
preferred C++ interfaces. Unfortunately none of us really speaks C++
currently. But especially the interfaces (input settings and result
structures) would probably be much easier to maintain and wrap in C++.
CUDA sound great.

> Is there a more active code repository than the one at sourceforge, or
is that
> the master?  

Sourceforge repository is master. Do you want developer access? I'd have
to wait for internal discussion though. 
And in principle significant changes should be discussed on the list
before submitting of course.

> Would you be interested in splitting soslib internally
> (or publically)
> into an smbl evaluation engine library with a separate library of
> integrations/statistical
> methods on top of it?

Do you mean separate packages and build structures for these
functionalities, or separate CVS branches? I wouldn't know how that
works. 
In principle, we wouldn't oppose splitting into two libraries. As
mentioned above, we have plans for extending the SBML<->ODE part and
linking it with pure reaction network analysis, separate from the
sundials wrappers, and on the other hand we already have an additional
separate library build on top of the sundials integration and like to
keep it general. Making it more modular is certainly in our interest. 

But as said in the first email, our main limitation currently is time :(

> 
> As an aside, I'm fairly expert in the SIDL/babel tool which produces
fully 2-way
> wrappers to any of the c/c++/fortran/python/java languages to an
implementation
> language (which may also be any of  c/c++/fortran/python/java). It
doesn't have
> the spread of language support (unless you then run swig on the C++
> binding headers)
> that swig does, but it preserves/exposes array and struct arguments
well
> compared to swig. If that kind of technology is of interest, I may be
> able to contribute
> such a wrapper. I've also done work in swig (creating new but
> unpublished language bindings, not
> just using swig) on top of sidl/babel.

This sounds great, but personally I don't know much about neither swig
nor SIDL/babel. Maybe Christoph can comment on that.

Thanks,
Rainer

> 
> Thanks,
> Ben
> 
> On Mon, Sep 28, 2009 at 3:05 AM, Rainer Machne <ra...@tb...>
wrote:
> > Hi Ben,
> >
> > Yes, we do plan some further extensions of SOSlib before a next
release:
> > most importantly
> > * attaching the currenlty global error handling into individual
ODEmodel
> > and integratorInstance objects,
> > * separating the current ODEmodel structures for inverse analysis
> > (objectiveFunction etc.) into separate structures,
> > * making the interface the our internal equation compiler public,
and
> > * providing some wrappers for scripting languages.
> >
> > But since we are in the final months of another project, we
currently
> > can't estimate when this will  the case. The current CVS version is
> > rather stable.
> >
> > In the long run, one possiblity would be to move some of the
interface
> > functionality to C++.
> >
> > You might especially be interested in our internal compilation
> > functionality, which speeds up integration times significantly.
> > Currently, it can be activated by defining "ARITHMETIC_TEST" on
compile
> > time and NOT use the "compileFunctions" option in cvodeSettings.
> >
> > We are open for further discussions and contributions!
> >
> > Rainer
> >
> >
> >
> > On Thu, 2009-09-24 at 15:36 -0400, Ben Allan wrote:
> >> I'm still interested in knowing the development status of soslib,
> >> but I see that changing the version listed in the sbml input
changes
> >> what libsbml thinks the model contains, including the
(dis)appearance
> >> of parameters.
> >> Now I'm off to solve the next bug that comes up...
> >>
> >> thanks,
> >> Ben
> >>
> >> On Thu, Sep 24, 2009 at 3:05 PM, Ben Allan <ba2...@gm...>
wrote:
> >> > Hi,
> >> >
> >> > I would like to know if you are still using/maintaining SOSLib
(or a
> >> > better open-source alternative with a similar purpose)?
> >> >
> >> > I'm working with the current version from sourceforge CVS and I'm
> >> > trying to figure out the solution
> >> > to errors I get when using a particular input file. I would
prefer to
> >> > fix bugs (if that's what it is) instead
> >> > of trying to rewrite soslib from scratch (probably in c++ instead
of
> >> > C). My ultimate aim is to use sbml
> >> > input in very large scale computations, possibly on gpus, with a
small
> >> > embedded engine for evaluating
> >> > the models.
> >> >
> >> > The current fatal symptom is that while evaluating rate laws with
> >> > parameters in their definitions it cannot find
> >> > names of constant parameter names in the om->names list during
evaluateAST.
> >> >
> >> > thanks,
> >> > Ben
> >> >
> >
> >

[SOSlib-discuss] Building on Windows

[Christoph F. <xt...@tb...>]

Hi all,

Frank Bergmann was so kind to provide a clean building mechanism of SOSlib
under Windows. He checked in the VisualStudio projektfiles into CVS in the
new subdirectory SOS_Win32.

Does anybody still uses Andrew Finney's (in the meantime) outdated Windows
code in the subdirectory  Win32. We would like to get rid of it and switch to
Frank Bergmann's mechanism for building SOSlib under Windows to get rid of
the source code duplication in the CVS repository.

If you have any objections against removing the subdirectory Win32 from the
CVS repository, please let us know.

=;) xtof

p.s. the building of SOSlib under Linux has been switched to use libtool,
     and now both static and shared libraries are made (hopefully in a
     portable way).

-- 
Christoph Flamm
Institut fuer Theoretische Chemie | email: xt...@tb...
Universitaet Wien                 | phone: ++43-1-4277-527-39
Waehringerstrasse 17/3/308        | fax:   ++43-1-4277-527-93
A-1090 Wien, Austria              | www: http://www.tbi.univie.ac.at/~xtof

[SOSlib-discuss] crash on AIX since cvs 2009-02-14

[Eric F. <efe...@ph...>]

Hi,

As I reported earlier, I have noticed a segfault when using the CVS
version (it segfaults when trying to display the model using odeSolver
-e model.xml). This occurred between the 2009-02-13 (which is working)
and 2009-02-14 (segfault).

The differences are in 3 files:

src/Makefile.am
configure.in
config/sundials.m4

The notable change is using sundials_ida by default (?) instead of
kinsol. Maybe there is a problem on AIX with it. But if it is so, why
would odeSolver crash when simply trying to display the model (odeSolver
-e) ?

Thanks,
Eric

Re: [SOSlib-discuss] autogen failure on AIX[Scanned]

[Eric F. <efe...@ph...>]

> hi eric,
> 
> actually you should use the system command autoreconf, with 
> this autogen.sh is obsolete.
> 
> try autoreconf -i -f
> 
> this should should copy the ltmain.sh to the proper location.
> 
> -i    copy missing auxiliary files
> -f    consider all files obsolete
> 
> =;) xtof
> 


Hi Christoph,

Thanks for the help, this worked.
However I get a segfault when running models (previous CVS ~ December
was working). I guess some changes have been made, I'll try to find out
what is going on.

Cheers,
Eric

Re: [SOSlib-discuss] autogen failure on AIX

[Eric F. <efe...@ph...>]

> I tried to fix this by installing libtool. However, I get 
> another error:
> 
> bash-2.05a$ ./autogen.sh
> Creating aclocal.m4...
> configure.in:76: required file `config/ltmain.sh' not found
> 
> Actually that is automake that fails here:
> bash-2.05a$ automake
> configure.in:76: required file `config/ltmain.sh' not found
> 
> My automake is the one I compiled from GNU sources, not a 
> default one from AIX, as I prefer to work with my own tools 
> and compiler on that platform.
> 
> Any idea ?
> 
> Eric

OK, I copied libtool-2.2.6/libltdl/config/ltmain.sh  to
SBML_odeSolver/config/ and could compile succesfully.
However, I segfault when trying to run a model with odeSolver. I'll try
to see what's happening.

Eric

[SOSlib-discuss] autogen failure on AIX

[Eric F. <efe...@ph...>]

> > Hi Rainer,
> > 
> > I have an issue when trying to compile the CVS on AIX since the 
> > changes that were made relatively recently:
> > 
> > bash-2.05a$ ./autogen.sh
> > Creating aclocal.m4...
> > src/Makefile.am:46: Libtool library used but `LIBTOOL' is undefined
> > src/Makefile.am:46:   The usual way to define `LIBTOOL' is to add
> > `AC_PROG_LIBTOOL'
> > src/Makefile.am:46:   to `configure.in' and run `aclocal' and 
> > `autoconf'
> > again.
> > src/Makefile.am:46:   If `AC_PROG_LIBTOOL' is in 
> `configure.in', make
> > sure
> > src/Makefile.am:46:   its definition is in aclocal's search path.
> > 
> > Although the message is quite clear I wonder is that a bug
> or just a
> > config problem with AIX ?
> > 
> > Thanks a lot
> > Eric
> 
> In order to bring more info, running autoconf returns:
> 
> bash-2.05a$ autoconf
> configure.in:76: error: possibly undefined macro: AC_PROG_LIBTOOL
>       If this token and others are legitimate, please use 
> m4_pattern_allow.
>       See the Autoconf documentation.
> 
> Eric
> 


I tried to fix this by installing libtool. However, I get another error:

bash-2.05a$ ./autogen.sh
Creating aclocal.m4...
configure.in:76: required file `config/ltmain.sh' not found

Actually that is automake that fails here:
bash-2.05a$ automake
configure.in:76: required file `config/ltmain.sh' not found

My automake is the one I compiled from GNU sources, not a default one
from AIX, as I prefer to work with my own tools and compiler on that
platform.

Any idea ?

Eric

Re: [SOSlib-discuss] autogen failure on AIX

[Eric F. <efe...@ph...>]

> Hi Rainer,
> 
> I have an issue when trying to compile the CVS on AIX since 
> the changes that were made relatively recently:
> 
> bash-2.05a$ ./autogen.sh
> Creating aclocal.m4...
> src/Makefile.am:46: Libtool library used but `LIBTOOL' is undefined
> src/Makefile.am:46:   The usual way to define `LIBTOOL' is to add
> `AC_PROG_LIBTOOL'
> src/Makefile.am:46:   to `configure.in' and run `aclocal' and 
> `autoconf'
> again.
> src/Makefile.am:46:   If `AC_PROG_LIBTOOL' is in `configure.in', make
> sure
> src/Makefile.am:46:   its definition is in aclocal's search path.
> 
> Although the message is quite clear I wonder is that a bug or 
> just a config problem with AIX ?
> 
> Thanks a lot
> Eric

In order to bring more info, running autoconf returns:

bash-2.05a$ autoconf
configure.in:76: error: possibly undefined macro: AC_PROG_LIBTOOL
      If this token and others are legitimate, please use
m4_pattern_allow.
      See the Autoconf documentation.

Eric

[SOSlib-discuss] autogen failure on AIX

[Eric F. <efe...@ph...>]

Hi Rainer,

I have an issue when trying to compile the CVS on AIX since the changes
that were made relatively recently:

bash-2.05a$ ./autogen.sh
Creating aclocal.m4...
src/Makefile.am:46: Libtool library used but `LIBTOOL' is undefined
src/Makefile.am:46:   The usual way to define `LIBTOOL' is to add
`AC_PROG_LIBTOOL'
src/Makefile.am:46:   to `configure.in' and run `aclocal' and `autoconf'
again.
src/Makefile.am:46:   If `AC_PROG_LIBTOOL' is in `configure.in', make
sure
src/Makefile.am:46:   its definition is in aclocal's search path.

Although the message is quite clear I wonder is that a bug or just a
config problem with AIX ?

Thanks a lot
Eric

Re: [SOSlib-discuss] ctypes python Integration not successful

[Michele M. <mat...@eb...>]

As Rainer spotted the name of the model is _wrong_ and there is no
proper integration.
It is kind of strange that no Exception or Error is raised when the
file is not found by the sbml library.

One interesting thing for others that maybe want to try to use ctypes
it's worth to know is that you must use _always_ the implicit cast to
int or double or anything else provided by ctypes when the C API
expect an int or a double.

For example when I was trying with a really simple model (testSimple)
the filename was exact but when I was setting the time I used to give
it without any cast, when the API expect a double. To overcome this
you should provide the time (or any other numerical values) as
ctype.c_double(time) or int according to the API.

So I fixed one problem and I met another in the same moment and I was puzzled.

Thanks for the help.

Cheers,
Michele.


On Thu, Feb 19, 2009 at 10:19 AM, Rainer Machne <ra...@tb...> wrote:
>
> Hi Michele,
>
> I don't speak Python, maybe Christoph or Colin can help you at a later
> point. However, a quick shot:
>
>> loadModel(model="../biochemical_circuits/MPAK.xml")
>
> The model's name is MAPK.xml, not MPAK.xml.
>
> I hope the solution is that simple :)
>
> Rainer
>
>

[SOSlib-discuss] ctypes python Integration not successful

[Michele M. <mat...@eb...>]

Dear list,

I' trying to replicate the examples for the odesolver with the ctypes in python.
In particular I'm trying to replicate the first one: integrate.c

Unfortunately the integration is not successful and the error that I
encounter is:

-1243916184

Odesolver can work perfectly with this model (it is the MAPK, used
also in the example)

I've attached the code.
Do you have any idea?

Cheers, Michele

Re: [SOSlib-discuss] Python binding for odesolver

[Michele M. <mat...@eb...>]

On Fri, Feb 13, 2009 at 5:43 AM, Rainer Machne <ra...@tb...> wrote:
> Hi Michele,
>
> Christoph is referring to the CVS version - we recommend to use this
> one.
>
> Unfortunately, we didn't manage to finalize things for a release in a
> long time (the swig bindings being one of the things that we want to
> include in the next release), but the CVS version works quite well.
>
>
> Please see http://sourceforge.net/cvs/?group_id=139893 how to obtain the
> CVS, or just run
>
> cvs -z3
> -d:pserver:ano...@sb...:/cvsroot/sbmlsolver
> co -P SBML_odeSolver
>
> After checking out, please run the script
>
> ./autogen.sh
>
> first (you might need additional stuff from the autotools for that).
>
> It generates the configure script. Then proceed as usual with
>
> ./configure
> make
> make install
>
> sosLib is then compiled with -fPIC option.
>
> HOWEVER, I just have tried this and no .so file is created. I don't know
> if with -fPIC the .a file can be used in the same way as a shared lib,
> or why that was apparently enough for creating the perl bindings.
>

That's exaclty where I was stucked :)
I was a little bit worried that no .so was showing up but it seems
it's a common problem :)



> Below I have outlined a possible temporary solution to create a
> libODES.so file, that works for me (ubuntu linux, 32bit) until we manage
> to include that in the normal configure/make process.
>
> Rainer
>
> Temporary solution to create a shared lib (.so):
>
> After compiling with make, go the src file and call gcc with -shared
> options manually:
>
> cd src
>
> gcc  -shared -o libODES.so ASTIndexNameNode.o arithmeticCompiler.o
> charBuffer.o compiler.o cvodeData.o cvodeSolver.o daeSolver.o
> drawGraph.o integratorInstance.o integratorSettings.o interpol.o
> modelSimplify.o nullSolver.o odeConstruct.o odeModel.o odeSolver.o
> processAST.o sbml.o sbmlResults.o sensSolver.o solverError.o util.o
> -L/usr/local/lib -L/usr/local/grace/lib -L/usr/lib/graphviz
> -lsundials_ida -lsundials_kinsol -lsundials_cvodes -lsundials_nvecserial
> -lsbml -lxml2 -lgrace_np -lgvc -lm -ldl -lm -lstdc++
>
> Note, that the library paths "/usr/local/lib" might need to be changed
> for your installation paths. Also if you compiled without the graphviz
> and xmgrace functionality, please remove the according arguments, i.e.
> graphviz: drawGraph.o -L/usr/lib/graphviz -lgvc.
> xmgrace: -L/usr/local/grace/lib -lgrace_np
>

The magic command worked and now I have my shared library that can be
loaded with ctypes as suggested by Colin.

I'm trying to replicate the examples.

I'll keep you posted.

Thanks for the help.

Cheers,
Michele.

Re: [SOSlib-discuss] Python binding for odesolver

[Rainer M. <ra...@tb...>]

Hi Michele,

Christoph is referring to the CVS version - we recommend to use this
one.

Unfortunately, we didn't manage to finalize things for a release in a
long time (the swig bindings being one of the things that we want to
include in the next release), but the CVS version works quite well.


Please see http://sourceforge.net/cvs/?group_id=139893 how to obtain the
CVS, or just run

cvs -z3
-d:pserver:ano...@sb...:/cvsroot/sbmlsolver
co -P SBML_odeSolver

After checking out, please run the script 

./autogen.sh

first (you might need additional stuff from the autotools for that).

It generates the configure script. Then proceed as usual with

./configure 
make 
make install

sosLib is then compiled with -fPIC option. 

HOWEVER, I just have tried this and no .so file is created. I don't know
if with -fPIC the .a file can be used in the same way as a shared lib,
or why that was apparently enough for creating the perl bindings.

Below I have outlined a possible temporary solution to create a
libODES.so file, that works for me (ubuntu linux, 32bit) until we manage
to include that in the normal configure/make process.

Rainer

Temporary solution to create a shared lib (.so):

After compiling with make, go the src file and call gcc with -shared
options manually:

cd src

gcc  -shared -o libODES.so ASTIndexNameNode.o arithmeticCompiler.o
charBuffer.o compiler.o cvodeData.o cvodeSolver.o daeSolver.o
drawGraph.o integratorInstance.o integratorSettings.o interpol.o
modelSimplify.o nullSolver.o odeConstruct.o odeModel.o odeSolver.o
processAST.o sbml.o sbmlResults.o sensSolver.o solverError.o util.o
-L/usr/local/lib -L/usr/local/grace/lib -L/usr/lib/graphviz
-lsundials_ida -lsundials_kinsol -lsundials_cvodes -lsundials_nvecserial
-lsbml -lxml2 -lgrace_np -lgvc -lm -ldl -lm -lstdc++

Note, that the library paths "/usr/local/lib" might need to be changed
for your installation paths. Also if you compiled without the graphviz
and xmgrace functionality, please remove the according arguments, i.e.
graphviz: drawGraph.o -L/usr/lib/graphviz -lgvc.
xmgrace: -L/usr/local/grace/lib -lgrace_np

If you compiled libSBML with another XML library (not default libXML2),
please replace the argument -lxml2 with that.

You should then get a libODES.so file, and should copy it to the
isntallation directory, in my case /usr/local/lib

sudo cp libODES.so /usr/local/lib/

Then test, if the examples work with that:

cd ../examples
make clean
make

Hope that works for you.


On Thu, 2009-02-12 at 13:09 +0000, Michele Mattioni wrote:
> Hi Christoph,
> 
> when I compile I can generate only a libODES.a .
> I run
> ./configure
> make
> make install
> 
> Am I missing something?
> 
> 
> On Thu, Feb 12, 2009 at 12:46 PM, Christoph Flamm <xt...@tb...> wrote:
> > hi Michele,
> >
> > -fPIC is set by default, since we have the compilation-on-the-fly feature.
> >
> > I will send you the Perl SWIG interface file during the next week.
> >
> > =;) xtof
> >
> > --
> > Christoph Flamm
> > Institut fuer Theoretische Chemie | email: xt...@tb...
> > Universitaet Wien                 | phone: ++43-1-4277-527-39
> > Waehringerstrasse 17/3/308        | fax:   ++43-1-4277-527-93
> > A-1090 Wien, Austria              | www: http://www.tbi.univie.ac.at/~xtof
> >
> > Michele Mattioni writes:
> >  > Hi Colin, Hi Christoff,
> >  >
> >  > thanks for the reply and for the suggestions.
> >  >
> >  > I will try to give a go to the ctypes and see if I can easily
> >  > replicate the examples in the example folder.
> >  >
> >  > How can I compile the library with the -fPIC flag?
> >  >
> >  > Thanks,
> >  > Michele.
> >  >
> >  >
> >  > On Wed, Feb 11, 2009 at 4:27 PM, Christoph Flamm <xt...@tb...> wrote:
> >  > > hi colin,
> >  > >
> >  > > yes, it is possible, it is done during the generation of the Perl
> >  > > binding. also our compilation-on-the-fly feature required, that we compile
> >  > > the library with the -fPIC option.
> >  > >
> >  > > =;) xtof
> >  > >
> >  > > --
> >  > > Christoph Flamm
> >  > > Institut fuer Theoretische Chemie | email: xt...@tb...
> >  > > Universitaet Wien                 | phone: ++43-1-4277-527-39
> >  > > Waehringerstrasse 17/3/308        | fax:   ++43-1-4277-527-93
> >  > > A-1090 Wien, Austria              | www: http://www.tbi.univie.ac.at/~xtof
> >  > >
> >  > >
> >  > > Colin Gillespie writes:
> >  > >  > Hi Michele,
> >  > >  >
> >  > >  > An easier way to interface with python is to use the ctypes library (I
> >  > >  > think it's part of the standard python installation). It would also make
> >  > >  > your code much more portable.
> >  > >  >
> >  > >  > To use ctypes is quite straighforward see
> >  > >  >
> >  > >  > www.jjj.sun.ac.za/~bgoli/codelib/libsbml3_ctypes-0.1.py
> >  > >  >
> >  > >  > for an example of using it with libsbml (of course you should just use
> >  > >  > the libsbml binding for python that is provided.)
> >  > >  >
> >  > >  > To access a C library, you have to be able to build a dynamic version of
> >  > >  > the library.
> >  > >  >
> >  > >  > Christoph, is it possible to create a dynamic version of ODEsolver?
> >  > >  >
> >  > >  > HTH,
> >  > >  >
> >  > >  > Colin
> >  > >  >
> >  > >  >
> >  > >  >
> >  > >  > Michele Mattioni wrote:
> >  > >  > > Can you tell me how to do that in C/C++?
> >  > >  > >
> >  > >  > > In the worst case scenario I can try to see how to integrate a C code
> >  > >  > > part directly in my application.
> >  > >  > > I need to see if I can achieve the results that I need for my
> >  > >  > > simulation, then I can try to play with swig.
> >  > >  > >
> >  > >  > > If you can send me the swig command you used for perl we can start
> >  > >  > > with really ugly but working python
> >  > >  > > bindings and refine them on the way :)
> >  > >  > >
> >  > >  > > Cheers,
> >  > >  > > Michele.
> >  > >  > >
> >  > >  > >
> >  > >  > > On Wed, Feb 11, 2009 at 3:37 PM, Christoph Flamm <xt...@tb...> wrote:
> >  > >  > >> hi michele,
> >  > >  > >>
> >  > >  > >> things like are in principle possible. Unfortunately the only bindings we
> >  > >  > >> currently have are Perl (experimental) and R bindings. To semi-automate the
> >  > >  > >> generation of the Perl bindings we use SWIG (http://www.swig.org/).
> >  > >  > >>
> >  > >  > >> Since we wanted to avoid to "pollute" the SOSlib Perl namespace with
> >  > >  > >> additional bindings to libSBML types like SBMLDocument_t (they have their
> >  > >  > >> own bindings), the SWIG interface file and typemaps contain a lot of Perl
> >  > >  > >> specific things and I currently don't know how to translate them to their
> >  > >  > >> Python equivalentes.
> >  > >  > >>
> >  > >  > >> I hope to get help with this problem during the SBML hackathon end of
> >  > >  > >> march.
> >  > >  > >>
> >  > >  > >> =;) xtof
> >  > >  > >>
> >  > >  > >> --
> >  > >  > >> Christoph Flamm
> >  > >  > >> Institut fuer Theoretische Chemie | email: xt...@tb...
> >  > >  > >> Universitaet Wien                 | phone: ++43-1-4277-527-39
> >  > >  > >> Waehringerstrasse 17/3/308        | fax:   ++43-1-4277-527-93
> >  > >  > >> A-1090 Wien, Austria              | www: http://www.tbi.univie.ac.at/~xtof
> >  > >  > >>
> >  > >  > >> Michele Mattioni writes:
> >  > >  > >>  > Hello list,
> >  > >  > >>  >
> >  > >  > >>  > I would like to know if it's possible to have a python binding for
> >  > >  > >>  > OdeSolver and an example code how to run a timecourse of a model.
> >  > >  > >>  >
> >  > >  > >>  > In particular what I would like to do is:
> >  > >  > >>  >
> >  > >  > >>  > run a model for x time
> >  > >  > >>  > get the species value
> >  > >  > >>  > change one specie value
> >  > >  > >>  > carry on the simulation with the new value for that specie and the
> >  > >  > >>  > last calculated value for all the others.
> >  > >  > >>  >
> >  > >  > >>  > Is possible to do something like that with odeSolver using some python
> >  > >  > >>  > binding?
> >  > >  > >>  >
> >  > >  > >>  > Thanks,
> >  > >  > >>  > Michele.
> >  > >  > >>
> >  > >  > >
> >  > >  > > ------------------------------------------------------------------------------
> >  > >  > > Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
> >  > >  > > software. With Adobe AIR, Ajax developers can use existing skills and code to
> >  > >  > > build responsive, highly engaging applications that combine the power of local
> >  > >  > > resources and data with the reach of the web. Download the Adobe AIR SDK and
> >  > >  > > Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
> >  > >  > > _______________________________________________
> >  > >  > > sbmlsolver-discuss mailing list
> >  > >  > > sbm...@li...
> >  > >  > > https://lists.sourceforge.net/lists/listinfo/sbmlsolver-discuss
> >  > >  > >
> >  > >  >
> >  > >  > --
> >  > >  > Dr Colin Gillespie
> >  > >  > http://www.mas.ncl.ac.uk/~ncsg3/
> >  > >
> >  > > ------------------------------------------------------------------------------
> >  > > Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
> >  > > software. With Adobe AIR, Ajax developers can use existing skills and code to
> >  > > build responsive, highly engaging applications that combine the power of local
> >  > > resources and data with the reach of the web. Download the Adobe AIR SDK and
> >  > > Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
> >  > > _______________________________________________
> >  > > sbmlsolver-discuss mailing list
> >  > > sbm...@li...
> >  > > https://lists.sourceforge.net/lists/listinfo/sbmlsolver-discuss
> >  > >
> >
> 
> ------------------------------------------------------------------------------
> Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
> software. With Adobe AIR, Ajax developers can use existing skills and code to
> build responsive, highly engaging applications that combine the power of local
> resources and data with the reach of the web. Download the Adobe AIR SDK and
> Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
> _______________________________________________
> sbmlsolver-discuss mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbmlsolver-discuss

Re: [SOSlib-discuss] Python binding for odesolver

[Michele M. <mat...@eb...>]

Hi Christoph,

when I compile I can generate only a libODES.a .
I run
./configure
make
make install

Am I missing something?


On Thu, Feb 12, 2009 at 12:46 PM, Christoph Flamm <xt...@tb...> wrote:
> hi Michele,
>
> -fPIC is set by default, since we have the compilation-on-the-fly feature.
>
> I will send you the Perl SWIG interface file during the next week.
>
> =;) xtof
>
> --
> Christoph Flamm
> Institut fuer Theoretische Chemie | email: xt...@tb...
> Universitaet Wien                 | phone: ++43-1-4277-527-39
> Waehringerstrasse 17/3/308        | fax:   ++43-1-4277-527-93
> A-1090 Wien, Austria              | www: http://www.tbi.univie.ac.at/~xtof
>
> Michele Mattioni writes:
>  > Hi Colin, Hi Christoff,
>  >
>  > thanks for the reply and for the suggestions.
>  >
>  > I will try to give a go to the ctypes and see if I can easily
>  > replicate the examples in the example folder.
>  >
>  > How can I compile the library with the -fPIC flag?
>  >
>  > Thanks,
>  > Michele.
>  >
>  >
>  > On Wed, Feb 11, 2009 at 4:27 PM, Christoph Flamm <xt...@tb...> wrote:
>  > > hi colin,
>  > >
>  > > yes, it is possible, it is done during the generation of the Perl
>  > > binding. also our compilation-on-the-fly feature required, that we compile
>  > > the library with the -fPIC option.
>  > >
>  > > =;) xtof
>  > >
>  > > --
>  > > Christoph Flamm
>  > > Institut fuer Theoretische Chemie | email: xt...@tb...
>  > > Universitaet Wien                 | phone: ++43-1-4277-527-39
>  > > Waehringerstrasse 17/3/308        | fax:   ++43-1-4277-527-93
>  > > A-1090 Wien, Austria              | www: http://www.tbi.univie.ac.at/~xtof
>  > >
>  > >
>  > > Colin Gillespie writes:
>  > >  > Hi Michele,
>  > >  >
>  > >  > An easier way to interface with python is to use the ctypes library (I
>  > >  > think it's part of the standard python installation). It would also make
>  > >  > your code much more portable.
>  > >  >
>  > >  > To use ctypes is quite straighforward see
>  > >  >
>  > >  > www.jjj.sun.ac.za/~bgoli/codelib/libsbml3_ctypes-0.1.py
>  > >  >
>  > >  > for an example of using it with libsbml (of course you should just use
>  > >  > the libsbml binding for python that is provided.)
>  > >  >
>  > >  > To access a C library, you have to be able to build a dynamic version of
>  > >  > the library.
>  > >  >
>  > >  > Christoph, is it possible to create a dynamic version of ODEsolver?
>  > >  >
>  > >  > HTH,
>  > >  >
>  > >  > Colin
>  > >  >
>  > >  >
>  > >  >
>  > >  > Michele Mattioni wrote:
>  > >  > > Can you tell me how to do that in C/C++?
>  > >  > >
>  > >  > > In the worst case scenario I can try to see how to integrate a C code
>  > >  > > part directly in my application.
>  > >  > > I need to see if I can achieve the results that I need for my
>  > >  > > simulation, then I can try to play with swig.
>  > >  > >
>  > >  > > If you can send me the swig command you used for perl we can start
>  > >  > > with really ugly but working python
>  > >  > > bindings and refine them on the way :)
>  > >  > >
>  > >  > > Cheers,
>  > >  > > Michele.
>  > >  > >
>  > >  > >
>  > >  > > On Wed, Feb 11, 2009 at 3:37 PM, Christoph Flamm <xt...@tb...> wrote:
>  > >  > >> hi michele,
>  > >  > >>
>  > >  > >> things like are in principle possible. Unfortunately the only bindings we
>  > >  > >> currently have are Perl (experimental) and R bindings. To semi-automate the
>  > >  > >> generation of the Perl bindings we use SWIG (http://www.swig.org/).
>  > >  > >>
>  > >  > >> Since we wanted to avoid to "pollute" the SOSlib Perl namespace with
>  > >  > >> additional bindings to libSBML types like SBMLDocument_t (they have their
>  > >  > >> own bindings), the SWIG interface file and typemaps contain a lot of Perl
>  > >  > >> specific things and I currently don't know how to translate them to their
>  > >  > >> Python equivalentes.
>  > >  > >>
>  > >  > >> I hope to get help with this problem during the SBML hackathon end of
>  > >  > >> march.
>  > >  > >>
>  > >  > >> =;) xtof
>  > >  > >>
>  > >  > >> --
>  > >  > >> Christoph Flamm
>  > >  > >> Institut fuer Theoretische Chemie | email: xt...@tb...
>  > >  > >> Universitaet Wien                 | phone: ++43-1-4277-527-39
>  > >  > >> Waehringerstrasse 17/3/308        | fax:   ++43-1-4277-527-93
>  > >  > >> A-1090 Wien, Austria              | www: http://www.tbi.univie.ac.at/~xtof
>  > >  > >>
>  > >  > >> Michele Mattioni writes:
>  > >  > >>  > Hello list,
>  > >  > >>  >
>  > >  > >>  > I would like to know if it's possible to have a python binding for
>  > >  > >>  > OdeSolver and an example code how to run a timecourse of a model.
>  > >  > >>  >
>  > >  > >>  > In particular what I would like to do is:
>  > >  > >>  >
>  > >  > >>  > run a model for x time
>  > >  > >>  > get the species value
>  > >  > >>  > change one specie value
>  > >  > >>  > carry on the simulation with the new value for that specie and the
>  > >  > >>  > last calculated value for all the others.
>  > >  > >>  >
>  > >  > >>  > Is possible to do something like that with odeSolver using some python
>  > >  > >>  > binding?
>  > >  > >>  >
>  > >  > >>  > Thanks,
>  > >  > >>  > Michele.
>  > >  > >>
>  > >  > >
>  > >  > > ------------------------------------------------------------------------------
>  > >  > > Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
>  > >  > > software. With Adobe AIR, Ajax developers can use existing skills and code to
>  > >  > > build responsive, highly engaging applications that combine the power of local
>  > >  > > resources and data with the reach of the web. Download the Adobe AIR SDK and
>  > >  > > Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
>  > >  > > _______________________________________________
>  > >  > > sbmlsolver-discuss mailing list
>  > >  > > sbm...@li...
>  > >  > > https://lists.sourceforge.net/lists/listinfo/sbmlsolver-discuss
>  > >  > >
>  > >  >
>  > >  > --
>  > >  > Dr Colin Gillespie
>  > >  > http://www.mas.ncl.ac.uk/~ncsg3/
>  > >
>  > > ------------------------------------------------------------------------------
>  > > Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
>  > > software. With Adobe AIR, Ajax developers can use existing skills and code to
>  > > build responsive, highly engaging applications that combine the power of local
>  > > resources and data with the reach of the web. Download the Adobe AIR SDK and
>  > > Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
>  > > _______________________________________________
>  > > sbmlsolver-discuss mailing list
>  > > sbm...@li...
>  > > https://lists.sourceforge.net/lists/listinfo/sbmlsolver-discuss
>  > >
>

Re: [SOSlib-discuss] Python binding for odesolver

[Christoph F. <xt...@tb...>]

hi Michele,

-fPIC is set by default, since we have the compilation-on-the-fly feature.

I will send you the Perl SWIG interface file during the next week.

=;) xtof

-- 
Christoph Flamm
Institut fuer Theoretische Chemie | email: xt...@tb...
Universitaet Wien                 | phone: ++43-1-4277-527-39
Waehringerstrasse 17/3/308        | fax:   ++43-1-4277-527-93
A-1090 Wien, Austria              | www: http://www.tbi.univie.ac.at/~xtof

Michele Mattioni writes:
 > Hi Colin, Hi Christoff,
 > 
 > thanks for the reply and for the suggestions.
 > 
 > I will try to give a go to the ctypes and see if I can easily
 > replicate the examples in the example folder.
 > 
 > How can I compile the library with the -fPIC flag?
 > 
 > Thanks,
 > Michele.
 > 
 > 
 > On Wed, Feb 11, 2009 at 4:27 PM, Christoph Flamm <xt...@tb...> wrote:
 > > hi colin,
 > >
 > > yes, it is possible, it is done during the generation of the Perl
 > > binding. also our compilation-on-the-fly feature required, that we compile
 > > the library with the -fPIC option.
 > >
 > > =;) xtof
 > >
 > > --
 > > Christoph Flamm
 > > Institut fuer Theoretische Chemie | email: xt...@tb...
 > > Universitaet Wien                 | phone: ++43-1-4277-527-39
 > > Waehringerstrasse 17/3/308        | fax:   ++43-1-4277-527-93
 > > A-1090 Wien, Austria              | www: http://www.tbi.univie.ac.at/~xtof
 > >
 > >
 > > Colin Gillespie writes:
 > >  > Hi Michele,
 > >  >
 > >  > An easier way to interface with python is to use the ctypes library (I
 > >  > think it's part of the standard python installation). It would also make
 > >  > your code much more portable.
 > >  >
 > >  > To use ctypes is quite straighforward see
 > >  >
 > >  > www.jjj.sun.ac.za/~bgoli/codelib/libsbml3_ctypes-0.1.py
 > >  >
 > >  > for an example of using it with libsbml (of course you should just use
 > >  > the libsbml binding for python that is provided.)
 > >  >
 > >  > To access a C library, you have to be able to build a dynamic version of
 > >  > the library.
 > >  >
 > >  > Christoph, is it possible to create a dynamic version of ODEsolver?
 > >  >
 > >  > HTH,
 > >  >
 > >  > Colin
 > >  >
 > >  >
 > >  >
 > >  > Michele Mattioni wrote:
 > >  > > Can you tell me how to do that in C/C++?
 > >  > >
 > >  > > In the worst case scenario I can try to see how to integrate a C code
 > >  > > part directly in my application.
 > >  > > I need to see if I can achieve the results that I need for my
 > >  > > simulation, then I can try to play with swig.
 > >  > >
 > >  > > If you can send me the swig command you used for perl we can start
 > >  > > with really ugly but working python
 > >  > > bindings and refine them on the way :)
 > >  > >
 > >  > > Cheers,
 > >  > > Michele.
 > >  > >
 > >  > >
 > >  > > On Wed, Feb 11, 2009 at 3:37 PM, Christoph Flamm <xt...@tb...> wrote:
 > >  > >> hi michele,
 > >  > >>
 > >  > >> things like are in principle possible. Unfortunately the only bindings we
 > >  > >> currently have are Perl (experimental) and R bindings. To semi-automate the
 > >  > >> generation of the Perl bindings we use SWIG (http://www.swig.org/).
 > >  > >>
 > >  > >> Since we wanted to avoid to "pollute" the SOSlib Perl namespace with
 > >  > >> additional bindings to libSBML types like SBMLDocument_t (they have their
 > >  > >> own bindings), the SWIG interface file and typemaps contain a lot of Perl
 > >  > >> specific things and I currently don't know how to translate them to their
 > >  > >> Python equivalentes.
 > >  > >>
 > >  > >> I hope to get help with this problem during the SBML hackathon end of
 > >  > >> march.
 > >  > >>
 > >  > >> =;) xtof
 > >  > >>
 > >  > >> --
 > >  > >> Christoph Flamm
 > >  > >> Institut fuer Theoretische Chemie | email: xt...@tb...
 > >  > >> Universitaet Wien                 | phone: ++43-1-4277-527-39
 > >  > >> Waehringerstrasse 17/3/308        | fax:   ++43-1-4277-527-93
 > >  > >> A-1090 Wien, Austria              | www: http://www.tbi.univie.ac.at/~xtof
 > >  > >>
 > >  > >> Michele Mattioni writes:
 > >  > >>  > Hello list,
 > >  > >>  >
 > >  > >>  > I would like to know if it's possible to have a python binding for
 > >  > >>  > OdeSolver and an example code how to run a timecourse of a model.
 > >  > >>  >
 > >  > >>  > In particular what I would like to do is:
 > >  > >>  >
 > >  > >>  > run a model for x time
 > >  > >>  > get the species value
 > >  > >>  > change one specie value
 > >  > >>  > carry on the simulation with the new value for that specie and the
 > >  > >>  > last calculated value for all the others.
 > >  > >>  >
 > >  > >>  > Is possible to do something like that with odeSolver using some python
 > >  > >>  > binding?
 > >  > >>  >
 > >  > >>  > Thanks,
 > >  > >>  > Michele.
 > >  > >>
 > >  > >
 > >  > > ------------------------------------------------------------------------------
 > >  > > Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
 > >  > > software. With Adobe AIR, Ajax developers can use existing skills and code to
 > >  > > build responsive, highly engaging applications that combine the power of local
 > >  > > resources and data with the reach of the web. Download the Adobe AIR SDK and
 > >  > > Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
 > >  > > _______________________________________________
 > >  > > sbmlsolver-discuss mailing list
 > >  > > sbm...@li...
 > >  > > https://lists.sourceforge.net/lists/listinfo/sbmlsolver-discuss
 > >  > >
 > >  >
 > >  > --
 > >  > Dr Colin Gillespie
 > >  > http://www.mas.ncl.ac.uk/~ncsg3/
 > >
 > > ------------------------------------------------------------------------------
 > > Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
 > > software. With Adobe AIR, Ajax developers can use existing skills and code to
 > > build responsive, highly engaging applications that combine the power of local
 > > resources and data with the reach of the web. Download the Adobe AIR SDK and
 > > Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
 > > _______________________________________________
 > > sbmlsolver-discuss mailing list
 > > sbm...@li...
 > > https://lists.sourceforge.net/lists/listinfo/sbmlsolver-discuss
 > >

Re: [SOSlib-discuss] Python binding for odesolver

[Michele M. <mat...@eb...>]

Hi Colin, Hi Christoff,

thanks for the reply and for the suggestions.

I will try to give a go to the ctypes and see if I can easily
replicate the examples in the example folder.

How can I compile the library with the -fPIC flag?

Thanks,
Michele.


On Wed, Feb 11, 2009 at 4:27 PM, Christoph Flamm <xt...@tb...> wrote:
> hi colin,
>
> yes, it is possible, it is done during the generation of the Perl
> binding. also our compilation-on-the-fly feature required, that we compile
> the library with the -fPIC option.
>
> =;) xtof
>
> --
> Christoph Flamm
> Institut fuer Theoretische Chemie | email: xt...@tb...
> Universitaet Wien                 | phone: ++43-1-4277-527-39
> Waehringerstrasse 17/3/308        | fax:   ++43-1-4277-527-93
> A-1090 Wien, Austria              | www: http://www.tbi.univie.ac.at/~xtof
>
>
> Colin Gillespie writes:
>  > Hi Michele,
>  >
>  > An easier way to interface with python is to use the ctypes library (I
>  > think it's part of the standard python installation). It would also make
>  > your code much more portable.
>  >
>  > To use ctypes is quite straighforward see
>  >
>  > www.jjj.sun.ac.za/~bgoli/codelib/libsbml3_ctypes-0.1.py
>  >
>  > for an example of using it with libsbml (of course you should just use
>  > the libsbml binding for python that is provided.)
>  >
>  > To access a C library, you have to be able to build a dynamic version of
>  > the library.
>  >
>  > Christoph, is it possible to create a dynamic version of ODEsolver?
>  >
>  > HTH,
>  >
>  > Colin
>  >
>  >
>  >
>  > Michele Mattioni wrote:
>  > > Can you tell me how to do that in C/C++?
>  > >
>  > > In the worst case scenario I can try to see how to integrate a C code
>  > > part directly in my application.
>  > > I need to see if I can achieve the results that I need for my
>  > > simulation, then I can try to play with swig.
>  > >
>  > > If you can send me the swig command you used for perl we can start
>  > > with really ugly but working python
>  > > bindings and refine them on the way :)
>  > >
>  > > Cheers,
>  > > Michele.
>  > >
>  > >
>  > > On Wed, Feb 11, 2009 at 3:37 PM, Christoph Flamm <xt...@tb...> wrote:
>  > >> hi michele,
>  > >>
>  > >> things like are in principle possible. Unfortunately the only bindings we
>  > >> currently have are Perl (experimental) and R bindings. To semi-automate the
>  > >> generation of the Perl bindings we use SWIG (http://www.swig.org/).
>  > >>
>  > >> Since we wanted to avoid to "pollute" the SOSlib Perl namespace with
>  > >> additional bindings to libSBML types like SBMLDocument_t (they have their
>  > >> own bindings), the SWIG interface file and typemaps contain a lot of Perl
>  > >> specific things and I currently don't know how to translate them to their
>  > >> Python equivalentes.
>  > >>
>  > >> I hope to get help with this problem during the SBML hackathon end of
>  > >> march.
>  > >>
>  > >> =;) xtof
>  > >>
>  > >> --
>  > >> Christoph Flamm
>  > >> Institut fuer Theoretische Chemie | email: xt...@tb...
>  > >> Universitaet Wien                 | phone: ++43-1-4277-527-39
>  > >> Waehringerstrasse 17/3/308        | fax:   ++43-1-4277-527-93
>  > >> A-1090 Wien, Austria              | www: http://www.tbi.univie.ac.at/~xtof
>  > >>
>  > >> Michele Mattioni writes:
>  > >>  > Hello list,
>  > >>  >
>  > >>  > I would like to know if it's possible to have a python binding for
>  > >>  > OdeSolver and an example code how to run a timecourse of a model.
>  > >>  >
>  > >>  > In particular what I would like to do is:
>  > >>  >
>  > >>  > run a model for x time
>  > >>  > get the species value
>  > >>  > change one specie value
>  > >>  > carry on the simulation with the new value for that specie and the
>  > >>  > last calculated value for all the others.
>  > >>  >
>  > >>  > Is possible to do something like that with odeSolver using some python
>  > >>  > binding?
>  > >>  >
>  > >>  > Thanks,
>  > >>  > Michele.
>  > >>
>  > >
>  > > ------------------------------------------------------------------------------
>  > > Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
>  > > software. With Adobe AIR, Ajax developers can use existing skills and code to
>  > > build responsive, highly engaging applications that combine the power of local
>  > > resources and data with the reach of the web. Download the Adobe AIR SDK and
>  > > Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
>  > > _______________________________________________
>  > > sbmlsolver-discuss mailing list
>  > > sbm...@li...
>  > > https://lists.sourceforge.net/lists/listinfo/sbmlsolver-discuss
>  > >
>  >
>  > --
>  > Dr Colin Gillespie
>  > http://www.mas.ncl.ac.uk/~ncsg3/
>
> ------------------------------------------------------------------------------
> Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
> software. With Adobe AIR, Ajax developers can use existing skills and code to
> build responsive, highly engaging applications that combine the power of local
> resources and data with the reach of the web. Download the Adobe AIR SDK and
> Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
> _______________________________________________
> sbmlsolver-discuss mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbmlsolver-discuss
>

Re: [SOSlib-discuss] Python binding for odesolver

[Christoph F. <xt...@tb...>]

hi colin,

yes, it is possible, it is done during the generation of the Perl
binding. also our compilation-on-the-fly feature required, that we compile
the library with the -fPIC option.

=;) xtof

-- 
Christoph Flamm
Institut fuer Theoretische Chemie | email: xt...@tb...
Universitaet Wien                 | phone: ++43-1-4277-527-39
Waehringerstrasse 17/3/308        | fax:   ++43-1-4277-527-93
A-1090 Wien, Austria              | www: http://www.tbi.univie.ac.at/~xtof


Colin Gillespie writes:
 > Hi Michele,
 > 
 > An easier way to interface with python is to use the ctypes library (I 
 > think it's part of the standard python installation). It would also make 
 > your code much more portable.
 > 
 > To use ctypes is quite straighforward see
 > 
 > www.jjj.sun.ac.za/~bgoli/codelib/libsbml3_ctypes-0.1.py
 > 
 > for an example of using it with libsbml (of course you should just use 
 > the libsbml binding for python that is provided.)
 > 
 > To access a C library, you have to be able to build a dynamic version of 
 > the library.
 > 
 > Christoph, is it possible to create a dynamic version of ODEsolver?
 > 
 > HTH,
 > 
 > Colin
 > 
 > 
 > 
 > Michele Mattioni wrote:
 > > Can you tell me how to do that in C/C++?
 > > 
 > > In the worst case scenario I can try to see how to integrate a C code
 > > part directly in my application.
 > > I need to see if I can achieve the results that I need for my
 > > simulation, then I can try to play with swig.
 > > 
 > > If you can send me the swig command you used for perl we can start
 > > with really ugly but working python
 > > bindings and refine them on the way :)
 > > 
 > > Cheers,
 > > Michele.
 > > 
 > > 
 > > On Wed, Feb 11, 2009 at 3:37 PM, Christoph Flamm <xt...@tb...> wrote:
 > >> hi michele,
 > >>
 > >> things like are in principle possible. Unfortunately the only bindings we
 > >> currently have are Perl (experimental) and R bindings. To semi-automate the
 > >> generation of the Perl bindings we use SWIG (http://www.swig.org/).
 > >>
 > >> Since we wanted to avoid to "pollute" the SOSlib Perl namespace with
 > >> additional bindings to libSBML types like SBMLDocument_t (they have their
 > >> own bindings), the SWIG interface file and typemaps contain a lot of Perl
 > >> specific things and I currently don't know how to translate them to their
 > >> Python equivalentes.
 > >>
 > >> I hope to get help with this problem during the SBML hackathon end of
 > >> march.
 > >>
 > >> =;) xtof
 > >>
 > >> --
 > >> Christoph Flamm
 > >> Institut fuer Theoretische Chemie | email: xt...@tb...
 > >> Universitaet Wien                 | phone: ++43-1-4277-527-39
 > >> Waehringerstrasse 17/3/308        | fax:   ++43-1-4277-527-93
 > >> A-1090 Wien, Austria              | www: http://www.tbi.univie.ac.at/~xtof
 > >>
 > >> Michele Mattioni writes:
 > >>  > Hello list,
 > >>  >
 > >>  > I would like to know if it's possible to have a python binding for
 > >>  > OdeSolver and an example code how to run a timecourse of a model.
 > >>  >
 > >>  > In particular what I would like to do is:
 > >>  >
 > >>  > run a model for x time
 > >>  > get the species value
 > >>  > change one specie value
 > >>  > carry on the simulation with the new value for that specie and the
 > >>  > last calculated value for all the others.
 > >>  >
 > >>  > Is possible to do something like that with odeSolver using some python
 > >>  > binding?
 > >>  >
 > >>  > Thanks,
 > >>  > Michele.
 > >>
 > > 
 > > ------------------------------------------------------------------------------
 > > Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
 > > software. With Adobe AIR, Ajax developers can use existing skills and code to
 > > build responsive, highly engaging applications that combine the power of local
 > > resources and data with the reach of the web. Download the Adobe AIR SDK and
 > > Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
 > > _______________________________________________
 > > sbmlsolver-discuss mailing list
 > > sbm...@li...
 > > https://lists.sourceforge.net/lists/listinfo/sbmlsolver-discuss
 > > 
 > 
 > -- 
 > Dr Colin Gillespie
 > http://www.mas.ncl.ac.uk/~ncsg3/

Re: [SOSlib-discuss] Python binding for odesolver

[Colin G. <c.g...@nc...>]

Hi Michele,

An easier way to interface with python is to use the ctypes library (I 
think it's part of the standard python installation). It would also make 
your code much more portable.

To use ctypes is quite straighforward see

www.jjj.sun.ac.za/~bgoli/codelib/libsbml3_ctypes-0.1.py

for an example of using it with libsbml (of course you should just use 
the libsbml binding for python that is provided.)

To access a C library, you have to be able to build a dynamic version of 
the library.

Christoph, is it possible to create a dynamic version of ODEsolver?

HTH,

Colin



Michele Mattioni wrote:
> Can you tell me how to do that in C/C++?
> 
> In the worst case scenario I can try to see how to integrate a C code
> part directly in my application.
> I need to see if I can achieve the results that I need for my
> simulation, then I can try to play with swig.
> 
> If you can send me the swig command you used for perl we can start
> with really ugly but working python
> bindings and refine them on the way :)
> 
> Cheers,
> Michele.
> 
> 
> On Wed, Feb 11, 2009 at 3:37 PM, Christoph Flamm <xt...@tb...> wrote:
>> hi michele,
>>
>> things like are in principle possible. Unfortunately the only bindings we
>> currently have are Perl (experimental) and R bindings. To semi-automate the
>> generation of the Perl bindings we use SWIG (http://www.swig.org/).
>>
>> Since we wanted to avoid to "pollute" the SOSlib Perl namespace with
>> additional bindings to libSBML types like SBMLDocument_t (they have their
>> own bindings), the SWIG interface file and typemaps contain a lot of Perl
>> specific things and I currently don't know how to translate them to their
>> Python equivalentes.
>>
>> I hope to get help with this problem during the SBML hackathon end of
>> march.
>>
>> =;) xtof
>>
>> --
>> Christoph Flamm
>> Institut fuer Theoretische Chemie | email: xt...@tb...
>> Universitaet Wien                 | phone: ++43-1-4277-527-39
>> Waehringerstrasse 17/3/308        | fax:   ++43-1-4277-527-93
>> A-1090 Wien, Austria              | www: http://www.tbi.univie.ac.at/~xtof
>>
>> Michele Mattioni writes:
>>  > Hello list,
>>  >
>>  > I would like to know if it's possible to have a python binding for
>>  > OdeSolver and an example code how to run a timecourse of a model.
>>  >
>>  > In particular what I would like to do is:
>>  >
>>  > run a model for x time
>>  > get the species value
>>  > change one specie value
>>  > carry on the simulation with the new value for that specie and the
>>  > last calculated value for all the others.
>>  >
>>  > Is possible to do something like that with odeSolver using some python
>>  > binding?
>>  >
>>  > Thanks,
>>  > Michele.
>>
> 
> ------------------------------------------------------------------------------
> Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
> software. With Adobe AIR, Ajax developers can use existing skills and code to
> build responsive, highly engaging applications that combine the power of local
> resources and data with the reach of the web. Download the Adobe AIR SDK and
> Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
> _______________________________________________
> sbmlsolver-discuss mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbmlsolver-discuss
> 

-- 
Dr Colin Gillespie
http://www.mas.ncl.ac.uk/~ncsg3/

Re: [SOSlib-discuss] Python binding for odesolver

[Michele M. <mat...@eb...>]

Can you tell me how to do that in C/C++?

In the worst case scenario I can try to see how to integrate a C code
part directly in my application.
I need to see if I can achieve the results that I need for my
simulation, then I can try to play with swig.

If you can send me the swig command you used for perl we can start
with really ugly but working python
bindings and refine them on the way :)

Cheers,
Michele.


On Wed, Feb 11, 2009 at 3:37 PM, Christoph Flamm <xt...@tb...> wrote:
> hi michele,
>
> things like are in principle possible. Unfortunately the only bindings we
> currently have are Perl (experimental) and R bindings. To semi-automate the
> generation of the Perl bindings we use SWIG (http://www.swig.org/).
>
> Since we wanted to avoid to "pollute" the SOSlib Perl namespace with
> additional bindings to libSBML types like SBMLDocument_t (they have their
> own bindings), the SWIG interface file and typemaps contain a lot of Perl
> specific things and I currently don't know how to translate them to their
> Python equivalentes.
>
> I hope to get help with this problem during the SBML hackathon end of
> march.
>
> =;) xtof
>
> --
> Christoph Flamm
> Institut fuer Theoretische Chemie | email: xt...@tb...
> Universitaet Wien                 | phone: ++43-1-4277-527-39
> Waehringerstrasse 17/3/308        | fax:   ++43-1-4277-527-93
> A-1090 Wien, Austria              | www: http://www.tbi.univie.ac.at/~xtof
>
> Michele Mattioni writes:
>  > Hello list,
>  >
>  > I would like to know if it's possible to have a python binding for
>  > OdeSolver and an example code how to run a timecourse of a model.
>  >
>  > In particular what I would like to do is:
>  >
>  > run a model for x time
>  > get the species value
>  > change one specie value
>  > carry on the simulation with the new value for that specie and the
>  > last calculated value for all the others.
>  >
>  > Is possible to do something like that with odeSolver using some python
>  > binding?
>  >
>  > Thanks,
>  > Michele.
>

Re: [SOSlib-discuss] memory exhaustion creating odeModels

[Eric F. <efe...@ph...>]

> Hi Eric,
> 
> Using examples/MAPK.xml I can get up to 40000 models (on 2GB RAM), but

> then I also get a segfault with your example program, while reading 
> the SBML model alone is Ok.
> 
> So odeModel seems to be comparatively big! We should profile that and 
> maybe try to optimize. Second, we should find out why it segfaults and

> doesn't just return NULLs and issue proper "out of memory" messages.

Hi Rainer,

The segfault is probably caused because I tested this on AIX, and memory
exhaustion checks were partially disabled on that platform. This is
caused by the fact the static memoryExhaustion variable is not correcly
initialised on AIX/gcc. This problem with static variables on AIX can be
found around on the net and nobody came up with a clear explanation
(although it is surprising such an important bug has not been
corrected). I'll contact people on gcc-users ML, but to be honest there
are no many AIX users there.
I should test it on Linux to check the memory exhaustion detection. 

> 
> It is important to note, that there is no leak in sosLib directly :) -

> and maybe also the big size is due to libSBML errors - not in parsing 
> from file but in creating a model, as outlined in the following:
> 
> Unfortunately, I can confirm real memory leaks (i.e. 
> increasing memory usage even when freeing each created odeModel 
> immediately), for which however libSBML seems to be responsible. I 
> tested version 3.1.1 so far, and memtest reports several leaks like 
> the one reported below, pointing to problems in ASTNode creation and 
> copying.

I used latest libSBML 3.3.0.

> 
> Maybe we can at least get rid of the internal simplified
> odeModel->simple which only consists of rate rules. Much work though.
> 
> One additional thought: maybe we should try to have one working 
> version of libSBML's ASTNode directly included in our source-code, so 
> we don't depend on libSBML versions which in many releases caused 
> (minor leak) problems.
> 
> 
> And finally some better news: No leaks and low memory footprint for 
> integratorInstance (incl. integration), and I can easily create 100000

> MAPK.xml integrators, after 30000 creations (without freeing of 
> course), memory is still only at 12% of my 2GB RAM.

Indeed, and this may be the best way to keep multiple instances of a
model.

> 
> I have copied my extended test file, derived from Eric's at 
> http://www.tbi.univie.ac.at/~raim/odeSolver/bugs/memleaks/
> 
> Please use something like:
> gcc -Wall memleak.c -o memleak -L/usr/local/lib -lODES -lsbml 
> -lsundials_kinsol -lsundials_cvodes -lsundials_nvecserial -ldl to 
> compile.
> 
> I used:
> valgrind --tool=memcheck --leak-check=yes --leak-check=full 
> --show-reachable=yes ./memleak to test for memory leaks.
> 
> Summary:
> 1) profile and optimize memory footprint of odeModel
> 2) avoid seg. fault when out of memory
> 3) check different libSBML versions
> 4a) get internal version of all ASTNode functionality and/or
> 4b) get rid of internal SBML with rate rules, directly construct 
> odeModel
> 
> Solution:
> Don't create thousands of odeModels (as odeModel_t is a constant and 
> completely unchangeable structure anyways!!), create thousands of 
> integratorInstances instead :) and set values there.
> 
> Rainer

Many thanks Rainer, I'll try to test this. I hope I can compile valgrind
on AIX :)

Kind regards,
Eric

[SOSlib-discuss] Python binding for odesolver

[Michele M. <mat...@eb...>]

Hello list,

I would like to know if it's possible to have a python binding for
OdeSolver and an example code how to run a timecourse of a model.

In particular what I would like to do is:

run a model for x time
get the species value
change one specie value
carry on the simulation with the new value for that specie and the
last calculated value for all the others.

Is possible to do something like that with odeSolver using some python binding?

Thanks,
Michele.

Re: [SOSlib-discuss] memory exhaustion creating odeModels

[Rainer M. <ra...@tb...>]

On Tue, 10 Feb 2009, Eric Fernandez wrote:

>
>
>> -----Original Message-----
>> From: Rainer Machne [mailto:ra...@tb...]
>> Sent: 06 February 2009 09:16
>> To: Eric Fernandez
>> Subject: RE: [SOSlib-discuss] memory exhaustion creating
>> odeModels[Scanned]
>>
>>
>> Maybe you can update to a later release or SVN version of
>> libSBML, I remember at least one memory leak in ASTNode in
>> the first 3.x.x versions.
>> Rainer
>
> Hi,
>
> My mistake, it seems the memory run-out occurs when creating
> odeModel_t*:
>
> This does work:
>
> int main()
> {
>
>  int ctit;
>  string modelFilename = "../../models/CC.xml";
>  SBMLDocument_t *d;
>  Model_t *m;
>
>  d = readSBML(modelFilename.c_str());
>  m = SBMLDocument_getModel(d);
>
>  for(ctit = 0; ctit != 10000; ++ctit)
>    {
>      m = SBMLDocument_getModel(d); //DOES NOT EXHAUST!!
>    }
> }
>
> but this segfaults after only 114 created instances of odeModels:

Hi Eric,

Using examples/MAPK.xml I can get up to 40000 models (on 2GB RAM), but 
then I also get a segfault with your example program, while reading the 
SBML model alone is Ok.

So odeModel seems to be comparatively big! We should profile that and 
maybe try to optimize. Second, we should find out why it segfaults and 
doesn't just return NULLs and issue proper "out of memory" messages.

It is important to note, that there is no leak in sosLib directly :) - and 
maybe also the big size is due to libSBML errors - not in parsing from 
file but in creating a model, as outlined in the following:

Unfortunately, I can confirm real memory leaks (i.e. increasing 
memory usage even when freeing each created odeModel immediately), for 
which however libSBML seems to be responsible. I tested version 3.1.1 so 
far, and memtest reports several leaks like the one reported below, 
pointing to problems in ASTNode creation and copying.

Maybe we can at least get rid of the internal simplified odeModel->simple 
which only consists of rate rules. Much work though.

One additional thought: maybe we should try to have one working version of 
libSBML's ASTNode directly included in our source-code, so we don't depend 
on libSBML versions which in many releases caused (minor leak) problems.


And finally some better news: No leaks and low memory footprint for 
integratorInstance (incl. integration), and I can easily 
create 100000 MAPK.xml integrators, after 30000 creations (without freeing 
of course), memory is still only at 12% of my 2GB RAM.

I have copied my extended test file, derived from Eric's at
http://www.tbi.univie.ac.at/~raim/odeSolver/bugs/memleaks/

Please use something like:
gcc -Wall memleak.c -o memleak -L/usr/local/lib -lODES -lsbml -lsundials_kinsol -lsundials_cvodes -lsundials_nvecserial -ldl
to compile.

I used:
valgrind --tool=memcheck --leak-check=yes --leak-check=full  --show-reachable=yes ./memleak
to test for memory leaks.

Summary:
1) profile and optimize memory footprint of odeModel
2) avoid seg. fault when out of memory
3) check different libSBML versions 
4a) get internal version of all ASTNode functionality
and/or
4b) get rid of internal SBML with rate rules, directly construct odeModel

Solution:
Don't create thousands of odeModels (as odeModel_t is a constant 
and completely unchangeable structure anyways!!), create thousands of 
integratorInstances instead :) and set values there.

Rainer


==10916== 9,648 bytes in 268 blocks are definitely lost in loss record 6 
of 8
==10916==    at 0x4023294: operator new(unsigned) 
(vg_replace_malloc.c:224)
==10916==    by 0x412ECEB: ASTNode::ASTNode(ASTNodeType_t) (in 
/usr/local/lib/libsbml.3.1.1.so)
==10916==    by 0x412EEB1: ASTNode::deepCopy() const (in 
/usr/local/lib/libsbml.3.1.1.so)
==10916==    by 0x40D3CF0: Rule::setMath(ASTNode const*) (in 
/usr/local/lib/libsbml.3.1.1.so)
==10916==    by 0x40D3D53: Rule_setMath (in 
/usr/local/lib/libsbml.3.1.1.so)
==10916==    by 0x8063D44: Model_reduceToOdes (odeConstruct.c:324)




>
> int main()
> {
>
>  int ctit;
>  string modelFilename = "../../models/CC.xml";
>  SBMLDocument_t *d;
>  Model_t *m;
>
>  d = readSBML(modelFilename.c_str());
>  m = SBMLDocument_getModel(d);
>
>  for(ctit = 0; ctit != 10000; ++ctit)
>    {
>      m = SBMLDocument_getModel(d); //DOES NOT EXHAUST!!
>      odeModel_t* om = ODEModel_create(m); //SEGFAULT!!
>    }
> }
>
> Is an odeModel structure that big, or is there a possible memleak ?
>
> Eric
>
> ------------------------------------------------------------------------------
> Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
> software. With Adobe AIR, Ajax developers can use existing skills and code to
> build responsive, highly engaging applications that combine the power of local
> resources and data with the reach of the web. Download the Adobe AIR SDK and
> Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
> _______________________________________________
> sbmlsolver-discuss mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbmlsolver-discuss
>