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

Re: [SOSlib-discuss] long pause in sosLib

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

Hi Rainer,

On Mon, 04 Apr 2011 09:37:18 +0900 (JST), Takeshi Abe <ta...@fi...> wrote:
>> One of our first moves might however be to move the code from sourceforge to
>> github. Opinions on that?
> I think GitHub is a good way to go because many of developers are familiar
> with its usage today.
In order to check how a migration looks like I have tried to port the current
CVS repository to GitHub's one of mine:
https://github.com/tabe/SBML_odeSolver
It is achieved with git-cvsimport(1). Note that there is only the "master"
branch on the above repository, but the command also dumps other branches
such as 'physiomics'.
HTH.

Cheers,
-- Takeshi Abe

Re: [SOSlib-discuss] long pause in sosLib

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

Hi Rainer,

On Fri, 1 Apr 2011 13:09:06 +0200 (CEST), Rainer Machne <ra...@tb...> wrote:
> Not sure if you have noticed, but I did check in some minor new functions
> recently, btw.
Thanks for noticing that, I check it out now.

> One of our first moves might however be to move the code from sourceforge to
> github. Opinions on that?
I think GitHub is a good way to go because many of developers are familiar
with its usage today.

Cheers,
-- Takeshi Abe

Re: [SOSlib-discuss] long pause in sosLib

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

Hi Takeshi,

good idea - thanks for reminding us!

I will have more free time from mod of April and will investigate this 
possibility - it is high time to get soslib going again!

Not sure if you have noticed, but I did check in some minor new functions 
recently, btw.

One of our first moves might however be to move the code from sourceforge 
to github. Opinions on that?

Rainer


On Fri, 18 Mar 2011, Takeshi Abe wrote:

> Hi,
>
> On Wed, 14 Apr 2010 09:28:05 +0200 (CEST), Rainer Machne <ra...@tb...> wrote:
>>
>> That sounds interesting! Maybe we can try that next year.
> So do you apply for it in this year?
>
> Cheers,
> -- Takeshi Abe
>
>>
>> Rainer
>>
>> On Mon, 12 Apr 2010, Allan, Benjamin wrote:
>>
>>> It's too late to bring it up for this year (my apologies), but
>>> google summer of code might be a good way to move soslib forward
>>> more regularly and without much budget.
>>>
>>> Ben
>
> ------------------------------------------------------------------------------
> Colocation vs. Managed Hosting
> A question and answer guide to determining the best fit
> for your organization - today and in the future.
> http://p.sf.net/sfu/internap-sfd2d
> _______________________________________________
> sbmlsolver-discuss mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbmlsolver-discuss
>

Re: [SOSlib-discuss] long pause in sosLib

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

Hi,

On Wed, 14 Apr 2010 09:28:05 +0200 (CEST), Rainer Machne <ra...@tb...> wrote:
> 
> That sounds interesting! Maybe we can try that next year.
So do you apply for it in this year?

Cheers,
-- Takeshi Abe

> 
> Rainer
> 
> On Mon, 12 Apr 2010, Allan, Benjamin wrote:
> 
>> It's too late to bring it up for this year (my apologies), but
>> google summer of code might be a good way to move soslib forward
>> more regularly and without much budget.
>>
>> Ben

Re: [SOSlib-discuss] A spec file for RPM package of SBML_odeSolver

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

Hi Rainer,

On Tue, 28 Sep 2010 23:49:59 +0200 (CEST), Rainer Machne <ra...@tb...> wrote:
> Wow, great. we will be testing this (we also use Fedora at our institute). What
> would be the right location/folder to place such files in the CVS (once tested)?
Not sure where it sould be, anyway you can place it on top of SBML_odeSolver/
since rpmbuild's -t option is able to find a spec file in a source tarball.
More details are available at http://www.rpm.org/max-rpm-snapshot/rpmbuild.8.html.

Cheers,
-- Takeshi Abe

[SOSlib-discuss] soslib upgrade

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

Hi,

Next week is the SBML COMBINE meeting and maybe I will have time to do 
some minor or even major clean-ups. Also we want to start 
testing/implementing libSBML 4.x (recommendations?). Do you have any 
suggestions/preferences/opinions what should be done next?

E.g. localizing error handling, splitting objectiveFunction from 
odeModel, libSBML 4.x, new sundials (?), moving the internal compiler to 
standard compilation and adding options, adding stoichiometryMatrix 
structure and API, ... (whew) ... other ideas/necessities?

Rainer

Re: [SOSlib-discuss] A spec file for RPM package of SBML_odeSolver

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

Wow, great. we will be testing this (we also use Fedora at 
our institute). What would be the right location/folder to place such 
files in the CVS (once tested)?
Rainer

On Tue, 21 Sep 2010, Takeshi Abe wrote:

> Hi,
>
> It would be nice if there is an official RPM package of SBML_odeSolver to
> ease touble on the installation process for RetHat-flavor Linux distributions.
> To create it from CVS HEAD with rpmbuild, I have a .spec file as attached;
> it recognizes the dependencies of:
> * libSBML 3.4.1
> * Grace
> * GraphViz
> * Sundials
> and looks to work fine on my Fedora 13 (but not yet CentOS 5.5).
>
> Cheers,
> -- Takeshi Abe
>

Re: [SOSlib-discuss] fix for m4 scripts to adapt to x86_64

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

Great, thanks. I checked the patch in today.
rainer

On Tue, 28 Sep 2010, Takeshi Abe wrote:

> Hi,
>
> Tried installing SBML_odeSolver on my x86_64 machine, I found that
> its ./configure fails to detect some libraries in /usr/lib64 rather
> than /usr/lib etc.
> The attached patch can fix it.
>
> Cheers,
> -- Takeshi Abe
>

[SOSlib-discuss] fix for m4 scripts to adapt to x86_64

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

Hi,

Tried installing SBML_odeSolver on my x86_64 machine, I found that
its ./configure fails to detect some libraries in /usr/lib64 rather
than /usr/lib etc.
The attached patch can fix it.

Cheers,
-- Takeshi Abe

[SOSlib-discuss] A spec file for RPM package of SBML_odeSolver

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

Hi,

It would be nice if there is an official RPM package of SBML_odeSolver to
ease touble on the installation process for RetHat-flavor Linux distributions.
To create it from CVS HEAD with rpmbuild, I have a .spec file as attached;
it recognizes the dependencies of:
* libSBML 3.4.1
* Grace
* GraphViz
* Sundials
and looks to work fine on my Fedora 13 (but not yet CentOS 5.5).

Cheers,
-- Takeshi Abe

Re: [SOSlib-discuss] small new functionality

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

On Fri, 3 Sep 2010, Takeshi Abe wrote:
>> The only problem currently is some strange binary stuff printed to stdout
>> before the model itself is printed, and missing XML namespace declaration
> But no such a stuff were reproduced. Something missing?

no sorry, it was a tiny bug, my fault, didn't program any C for quite a 
while. You probably downloaded the fixed version already.

r


>
> Cheers,
> -- Takeshi Abe
>
> ------------------------------------------------------------------------------
> This SF.net Dev2Dev email is sponsored by:
>
> Show off your parallel programming skills.
> Enter the Intel(R) Threading Challenge 2010.
> http://p.sf.net/sfu/intel-thread-sfd
> _______________________________________________
> sbmlsolver-discuss mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbmlsolver-discuss
>

Re: [SOSlib-discuss] small new functionality

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

Hi,

On Thu, 2 Sep 2010 15:56:16 +0200 (CEST), Rainer Machne <ra...@tb...> wrote:
> the command-line tool (in CVS) has a tiny but handy new function: the 
> input SBML file can be updated with the values of the last time-point of 
> integration. This is e.g. useful if you want to initialize your model to 
> some steady-state: in that case you use the new option with the 
> steady-state finder, e.g
> 
> odeSolver yourmodel.xml --ti 2e5 --printstep 1e5 -s -p
I've tried the options with some of SBML models. They seem to work well.

> The only problem currently is some strange binary stuff printed to stdout 
> before the model itself is printed, and missing XML namespace declaration 
But no such a stuff were reproduced. Something missing?

Cheers,
-- Takeshi Abe

[SOSlib-discuss] small new functionality

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

Hi,

the command-line tool (in CVS) has a tiny but handy new function: the 
input SBML file can be updated with the values of the last time-point of 
integration. This is e.g. useful if you want to initialize your model to 
some steady-state: in that case you use the new option with the 
steady-state finder, e.g

odeSolver yourmodel.xml --ti 2e5 --printstep 1e5 -s -p

Option -s will terminate the integration when a steady state is found 
(currently judged by very low values of the ODEs). The new option -p will 
result in a file called "yourmodel.xml.soslib.xml" which has all values 
(including assigned parameters, compartments etc.) updated to the last 
time-point of integration, in this case (hopefully) a steady state.

If you use SOSlib as a library. It is fairly easy to do this using the 
existing API function Model_setValue(...);
See the new function printResultsToSBML(...) in odeSolver/printModel.c on 
how to use it. Although currently I am not sure whether 
amount/concentration things is done correctly.

The only problem currently is some strange binary stuff printed to stdout 
before the model itself is printed, and missing XML namespace declaration 
for other-then-sbml-XML in annotation elements (e.g. celldesigner). For 
now, the namespace declarataions have to be pasted manually afterwards. 
Maybe a newer version of libSBML handles this correctly.

Rainer

[SOSlib-discuss] SBML meeting, edinburgh

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

Hi,

I will most likely attend the SBML meeting before ICSB in Edinburgh, see
http://sbml.org/Events/Forums/COMBINE_2010

I hope to find time to do some programming there, e.g. update to newer
libSBML and Sundials versions. If anybody wants to meet, pls let me know.


Rainer

Re: [SOSlib-discuss] sourceforge email list admin?

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

Hi,

On Mon, 26 Apr 2010 11:18:54 +0200, <ra...@tb...> wrote:
> does anyone happen to know how to retrieve a forgotten admin password
> for sourceforge email lists (like this one :p ) ?
This one may be helpful:
https://sourceforge.net/apps/trac/sourceforge/ticket/3593

Cheers,
-- Takeshi Abe

[SOSlib-discuss] sourceforge email list admin?

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

Hi,

does anyone happen to know how to retrieve a forgotten admin password
for sourceforge email lists (like this one :p ) ?

Rainer

Re: [SOSlib-discuss] Providing event accessors on odeModel

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

Hi,

On Fri, 16 Apr 2010 10:35:07 -0600, <ba...@sa...> wrote:
> I think it's probably best if I don't have commit access for now. 
> If I get a patch clearly worth having, I'll send it along. Part of my
> difficulty is in understanding the project policy with
> regard to libsbml/SBML specification version.  Is brilliant support
> of legacy versions required, do we live on the bleeding edge of SBML
> spec changes/libsbml development, or do how do you define the
> balance in between? I imagine the answers would depend on the
> downstream users to some degree.
Agreed. Some discussion with clear motivation should precede any feature
development.
BTW my current interest is rather simple; to catch trivial bugs in terms
of almost all versions of SBML, and to improve portability.
E.g., yesterday I got stumble to build HEAD with the MinGW toolchain,
and see small fix needed.

> on version control:
> I find CVS fairly brittle/klunky for managing multiplayer projects conveniently--
> would you have any interest in migrating to something at least
> as semimodern and well documented as svn (or some other version system)?
+1. Subversion's revision-based diff is more useful than CVS's file-based one
for followers. Git is also sweet for multi-developer environment.
Both are available on sourceforge.net.

Cheers,
-- Takeshi Abe

Re: [SOSlib-discuss] Providing event accessors on odeModel

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

I think it's probably best if I don't have commit access for now. 
If I get a patch clearly worth having, I'll send it along. Part of my
difficulty is in understanding the project policy with
regard to libsbml/SBML specification version.  Is brilliant support
of legacy versions required, do we live on the bleeding edge of SBML
spec changes/libsbml development, or do how do you define the
balance in between? I imagine the answers would depend on the
downstream users to some degree.

There's been fairly significant changes to SBML 
that impact the ode model generated; e.g. if you tag a file as sbml 2.1
you get a small ode model and if you tag the same file sbml 2.3/4 you get a much more
accurate/larger rendering of your model into odes because libsbml behaves differently.

on version control:
I find CVS fairly brittle/klunky for managing multiplayer projects conveniently--
would you have any interest in migrating to something at least
as semimodern and well documented as svn (or some other version system)?

Ben
________________________________________
From: Rainer Machne [ra...@tb...]
Sent: Friday, April 16, 2010 9:10 AM
To: sbm...@li...
Subject: Re: [SOSlib-discuss] Providing event accessors on odeModel

Thanks! I will integrate it into CVS code. Would you want to have
developer access to our sourceforge CVS? Please send me your CVS account
name (in a private email!).

Ben, would you want a developer access? If yes, please also send me your
CVS account (private email).

Before submitting major changes, they should be discussed on this list.

Of course we can also integrate changes you send to this list ourselves,
if you prefer.

Rainer

Re: [SOSlib-discuss] Providing event accessors on odeModel

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

Thanks! I will integrate it into CVS code. Would you want to have
developer access to our sourceforge CVS? Please send me your CVS account
name (in a private email!).

Ben, would you want a developer access? If yes, please also send me your
CVS account (private email).

Before submitting major changes, they should be discussed on this list.

Of course we can also integrate changes you send to this list ourselves,
if you prefer.

Rainer

On 04/15/2010 12:39 PM, Takeshi Abe wrote:
> Hi all,
> 
> After reading SBML's specification, I have realized that events
> are significant as much as ODEs/assginments in its simulation
> semantics.
> Thanks to SOSlib, odeModel.h exposes some API to access the parsed
> discontinuity objects, but they seem to be not yet implemented:
> SBML_ODESOLVER_API int ODEModel_getNumPiecewise(odeModel_t *);
> SBML_ODESOLVER_API int ODEModel_getNumEvents(odeModel_t *);
> SBML_ODESOLVER_API const ASTNode_t *ODEModel_getEventTrigger(odeModel_t *, int);
> SBML_ODESOLVER_API const ASTNode_t *ODEModel_getEventAssignment(odeModel_t *, int, int);
> 
> The below patch may provide them plus 2 more utils.
> If no problem it would be nice applying this to HEAD.
> 
> ---
> Index: src/odeModel.c
> ===================================================================
> RCS file: /cvsroot/sbmlsolver/SBML_odeSolver/src/odeModel.c,v
> retrieving revision 1.130
> diff -u -r1.130 odeModel.c
> --- src/odeModel.c      12 Apr 2010 08:29:38 -0000      1.130
> +++ src/odeModel.c      15 Apr 2010 10:32:18 -0000
> @@ -1738,6 +1738,44 @@
>  
>  /** @} */
>  
> +SBML_ODESOLVER_API int ODEModel_getNumPiecewise(odeModel_t *om)
> +{
> +  return om->npiecewise;
> +}
> +
> +SBML_ODESOLVER_API int ODEModel_getNumEvents(odeModel_t *om)
> +{
> +  return om->nevents;
> +}
> +
> +SBML_ODESOLVER_API int ODEModel_getNumEventAssignments(odeModel_t *om, int i)
> +{
> +  if (i < om->nevents) return om->neventAss[i];
> +  else return -1;
> +}
> +
> +SBML_ODESOLVER_API const ASTNode_t *ODEModel_getEventTrigger(odeModel_t *om, int i)
> +{
> +  if (i < om->nevents) return (const ASTNode_t *) om->event[i];
> +  else return NULL;
> +}
> +
> +SBML_ODESOLVER_API const ASTNode_t *ODEModel_getEventAssignment(odeModel_t *om, int i, int j)
> +{
> +  if ( i < om->nevents && j < om->neventAss[i] )
> +  return (const ASTNode_t *) om->eventAssignment[i][j];
> +  else return NULL;
> +}
> +
> +SBML_ODESOLVER_API const char *ODEModel_getEventAssignmentName(odeModel_t *om, int i, int j)
> +{
> +  if ( i < om->nevents && j < om->neventAss[i] ) {
> +  int k = om->eventIndex[i][j];
> +  if ( 0 <= k && k < (om->neq+om->nass+om->nconst+om->nalg) )
> +    return (const char *)om->names[k];
> +  }
> +  return NULL;
> +}
>  
>  /*! \defgroup jacobian Jacobian Matrix: J = df(x)/dx
>    \ingroup odeModel
> Index: src/sbmlsolver/odeModel.h
> ===================================================================
> RCS file: /cvsroot/sbmlsolver/SBML_odeSolver/src/sbmlsolver/odeModel.h,v
> retrieving revision 1.55
> diff -u -r1.55 odeModel.h
> --- src/sbmlsolver/odeModel.h   27 Mar 2009 15:55:03 -0000      1.55
> +++ src/sbmlsolver/odeModel.h   15 Apr 2010 10:32:18 -0000
> @@ -356,8 +356,10 @@
>    /* Discontinuities */
>    SBML_ODESOLVER_API int ODEModel_getNumPiecewise(odeModel_t *);
>    SBML_ODESOLVER_API int ODEModel_getNumEvents(odeModel_t *);
> +  SBML_ODESOLVER_API int ODEModel_getNumEventAssignments(odeModel_t *, int);
>    SBML_ODESOLVER_API const ASTNode_t *ODEModel_getEventTrigger(odeModel_t *, int);
>    SBML_ODESOLVER_API const ASTNode_t *ODEModel_getEventAssignment(odeModel_t *, int, int);
> +  SBML_ODESOLVER_API const char *ODEModel_getEventAssignmentName(odeModel_t *, int, int);
>    
>  
>    /* ODE Jacobi matrix */
> ---
> 
> Cheers,
> -- Takeshi Abe
> 
> ------------------------------------------------------------------------------
> Download Intel&#174; 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] Providing event accessors on odeModel

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

Hi all,

After reading SBML's specification, I have realized that events
are significant as much as ODEs/assginments in its simulation
semantics.
Thanks to SOSlib, odeModel.h exposes some API to access the parsed
discontinuity objects, but they seem to be not yet implemented:
SBML_ODESOLVER_API int ODEModel_getNumPiecewise(odeModel_t *);
SBML_ODESOLVER_API int ODEModel_getNumEvents(odeModel_t *);
SBML_ODESOLVER_API const ASTNode_t *ODEModel_getEventTrigger(odeModel_t *, int);
SBML_ODESOLVER_API const ASTNode_t *ODEModel_getEventAssignment(odeModel_t *, int, int);

The below patch may provide them plus 2 more utils.
If no problem it would be nice applying this to HEAD.

---
Index: src/odeModel.c
===================================================================
RCS file: /cvsroot/sbmlsolver/SBML_odeSolver/src/odeModel.c,v
retrieving revision 1.130
diff -u -r1.130 odeModel.c
--- src/odeModel.c      12 Apr 2010 08:29:38 -0000      1.130
+++ src/odeModel.c      15 Apr 2010 10:32:18 -0000
@@ -1738,6 +1738,44 @@
 
 /** @} */
 
+SBML_ODESOLVER_API int ODEModel_getNumPiecewise(odeModel_t *om)
+{
+  return om->npiecewise;
+}
+
+SBML_ODESOLVER_API int ODEModel_getNumEvents(odeModel_t *om)
+{
+  return om->nevents;
+}
+
+SBML_ODESOLVER_API int ODEModel_getNumEventAssignments(odeModel_t *om, int i)
+{
+  if (i < om->nevents) return om->neventAss[i];
+  else return -1;
+}
+
+SBML_ODESOLVER_API const ASTNode_t *ODEModel_getEventTrigger(odeModel_t *om, int i)
+{
+  if (i < om->nevents) return (const ASTNode_t *) om->event[i];
+  else return NULL;
+}
+
+SBML_ODESOLVER_API const ASTNode_t *ODEModel_getEventAssignment(odeModel_t *om, int i, int j)
+{
+  if ( i < om->nevents && j < om->neventAss[i] )
+  return (const ASTNode_t *) om->eventAssignment[i][j];
+  else return NULL;
+}
+
+SBML_ODESOLVER_API const char *ODEModel_getEventAssignmentName(odeModel_t *om, int i, int j)
+{
+  if ( i < om->nevents && j < om->neventAss[i] ) {
+  int k = om->eventIndex[i][j];
+  if ( 0 <= k && k < (om->neq+om->nass+om->nconst+om->nalg) )
+    return (const char *)om->names[k];
+  }
+  return NULL;
+}
 
 /*! \defgroup jacobian Jacobian Matrix: J = df(x)/dx
   \ingroup odeModel
Index: src/sbmlsolver/odeModel.h
===================================================================
RCS file: /cvsroot/sbmlsolver/SBML_odeSolver/src/sbmlsolver/odeModel.h,v
retrieving revision 1.55
diff -u -r1.55 odeModel.h
--- src/sbmlsolver/odeModel.h   27 Mar 2009 15:55:03 -0000      1.55
+++ src/sbmlsolver/odeModel.h   15 Apr 2010 10:32:18 -0000
@@ -356,8 +356,10 @@
   /* Discontinuities */
   SBML_ODESOLVER_API int ODEModel_getNumPiecewise(odeModel_t *);
   SBML_ODESOLVER_API int ODEModel_getNumEvents(odeModel_t *);
+  SBML_ODESOLVER_API int ODEModel_getNumEventAssignments(odeModel_t *, int);
   SBML_ODESOLVER_API const ASTNode_t *ODEModel_getEventTrigger(odeModel_t *, int);
   SBML_ODESOLVER_API const ASTNode_t *ODEModel_getEventAssignment(odeModel_t *, int, int);
+  SBML_ODESOLVER_API const char *ODEModel_getEventAssignmentName(odeModel_t *, int, int);
   
 
   /* ODE Jacobi matrix */
---

Cheers,
-- Takeshi Abe

Re: [SOSlib-discuss] long pause in sosLib

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

That sounds interesting! Maybe we can try that next year.

Rainer

On Mon, 12 Apr 2010, Allan, Benjamin wrote:

> It's too late to bring it up for this year (my apologies), but
> google summer of code might be a good way to move soslib forward
> more regularly and without much budget.
>
> Ben
>
>

Re: [SOSlib-discuss] long pause in sosLib

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

It's too late to bring it up for this year (my apologies), but 
google summer of code might be a good way to move soslib forward
more regularly and without much budget.

Ben

Re: [SOSlib-discuss] long pause in sosLib

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

Yes, we will switch to the latest versions of libSBML - Ben Allen has
already worked on that - and we will also have a look at new Sundials.

Rainer

On 04/12/2010 11:06 AM, Takeshi Abe wrote:
> Hi,
> 
> On Mon, 12 Apr 2010 10:23:18 +0200, Rainer Machne <ra...@tb...> wrote:
>> As soon as our current project is finished (this summer), we hope to
>> find time for an official sosLib v2 release of the CVS. There are a
>> couple of important TODOs though, e.g. "localizing" error handling to
>> ensure true thread-safety, further modularizing code (Ben, sorry for
>> still not replying to your previous email), fully integrating our
>> internal equation compiler, but also e.g. moving the code to SVN or even
>> something like github.
> Glad to hear that, I also wonder if it would rock working with the latest
> version of libSBML and/or SUNDIALS.
> 
> Cheers,
> -- Takeshi Abe
> 
> ------------------------------------------------------------------------------
> Download Intel&#174; 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

Re: [SOSlib-discuss] long pause in sosLib

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

Hi,

On Mon, 12 Apr 2010 10:23:18 +0200, Rainer Machne <ra...@tb...> wrote:
> As soon as our current project is finished (this summer), we hope to
> find time for an official sosLib v2 release of the CVS. There are a
> couple of important TODOs though, e.g. "localizing" error handling to
> ensure true thread-safety, further modularizing code (Ben, sorry for
> still not replying to your previous email), fully integrating our
> internal equation compiler, but also e.g. moving the code to SVN or even
> something like github.
Glad to hear that, I also wonder if it would rock working with the latest
version of libSBML and/or SUNDIALS.

Cheers,
-- Takeshi Abe

[SOSlib-discuss] long pause in sosLib

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

Hi All,

FYI, the SOSlib project is not dead just sleeping, currently :) As some
of you know the current CVS stage is rather useful, very few bugs (if
any at all ;p ) and fast.

As soon as our current project is finished (this summer), we hope to
find time for an official sosLib v2 release of the CVS. There are a
couple of important TODOs though, e.g. "localizing" error handling to
ensure true thread-safety, further modularizing code (Ben, sorry for
still not replying to your previous email), fully integrating our
internal equation compiler, but also e.g. moving the code to SVN or even
something like github.

This hopefully happens some time in fall, but I currently can't make any
promises.

Rainer