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

Re: [SOSlib-discuss] SOSlib, libSBML and libxml2[Scanned]

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

 Hi,

I finally solved the problem. I realised that an older libxml2 was
already installed on the server, and by default this one was the one
detected by the ./configure (and does not work with libsbml-3.2). Using
the explicit pathway for my libxml2, everything works now.

Eric

> -----Original Message-----
> From: Rainer Machne [mailto:ra...@tb...] 
> Sent: 09 September 2008 16:27
> To: Eric Fernandez
> Subject: Re: [SOSlib-discuss] SOSlib, libSBML and libxml2[Scanned]
> 
> 
> Hmm, sounds strange.
> 
> It seems to correctly search for the .a extension:
> 
>  > /hpc/work/fernandz/local/lib/libsbml.a.
>  >         0509-150   Dependent module
>  > /hpc/work/fernandz/local/lib/libxml2.a(libxml2.shr.o) could not be
> 
> Should libxml2.a exist at this location? Does libSBML (and 
> some example/test programs) work with libxml2?
> 
> Maybe a good old version problem, and you need to do `make 
> clean'/`make install' at some steps, or even remove header 
> files manually?
> 
> Rainer

Re: [SOSlib-discuss] sparse Jacobi matrix, DENSE_ELEM, removing 0s

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

Current CVS now makes use of the sparse Jacobi matrix list (was really 
simple to implement using libSBML's generic list functions), as well as 
the new arithmetic compiler for all r.h.s. functions where applicable.

Currently you need to activate these via defines e.g. during `make' on 
command-line, as follows:

make clean
make DEFS="-DSPARSE -DARITHMETIC_TEST"
make install

Maybe some you want to try and benchmark these new features.


Rainer


Rainer Machne wrote:
> Hi there,
> 
> For large models with a very sparse Jacobi matrix, it is much more 
> efficient to NOT print out all the DENSE_ELEM[] = 0 commands for the gcc 
> compiler.
> 
> So I have added this to construction of the forward and adjoint Jacobi 
> evaluation function. From looking at the results and the CVODES examples 
> I think that it is OK, to just not initialize or set the DENSE_ELEM 
> things for the 0 entries.
> 
> 
> However, I guess that could also be very useful for the hard-coded 
> R.H.S. functions (used by both evaluateAST and the arithmeticCompiler).
> 
> So instead of looping through the neq*neq matrix, we could generate some 
> sort of list, which contains the correct Jacobi matrix equation (only 
> for non-0 entris) and the indices i,j to which Jacobi element it refers 
> to. Then just loop through this list instead of through neq*neq.
> 
> 
> What do you think? Worth a try?
> 
> Rainer
> 
> 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> sbmlsolver-discuss mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbmlsolver-discuss

Re: [SOSlib-discuss] SOSlib, libSBML and libxml2[Scanned]

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

Hi,

I have just tried to recompile the tryptic libxml2/libsbml/SOSlib and
compilation went through.

However, when I try to run odeSolver, I get this error:

bash-2.05a$ time ./odeSolver --time=48 --printstep=480 -fnz
../../../models/CC.xml
exec(): 0509-036 Cannot load program ./odeSolver because of the
following errors:
        0509-022 Cannot load module
/hpc/work/fernandz/local/lib/libsbml.a.
        0509-150   Dependent module
/hpc/work/fernandz/local/lib/libxml2.a(libxml2.shr.o) could not be
loaded.
        0509-152   Member libxml2.shr.o is not found in archive 
        0509-022 Cannot load module odeSolver.
        0509-150   Dependent module
/hpc/work/fernandz/local/lib/libsbml.a could not be loaded.
        0509-022 Cannot load module . 

I wonder if this is because under AIX, libraries (shared or not) have
the .a extension, and not .so ?
I recompiled using expat and everything works again. Not a big deal,
since your changes did not break the Expat-based SOSlib.


Regarding the compilation command, I have tried your changes, and the
compilation works very well with the new options. Some CFLAGS are
specific with xlc but the ones you use did not affect the correct
compilation.

So apart from the libxml2 problem, which I am going to check, there is
no problem, as long as I still use expat as the XML parser.

Eric

> -----Original Message-----
> From: Rainer Machne [mailto:ra...@tb...] 
> Sent: 09 September 2008 13:57
> To: Eric Fernandez
> Cc: sbm...@li...
> Subject: Re: [SOSlib-discuss] SOSlib, libSBML and libxml2[Scanned]
> 
> Hi Eric,
> 
> Great, thanks! We are just now starting to prepair for the 
> release. this time for real :)
> 
> I have changed the default in config/sbml.m4 to libxml2. 
> Maybe you can try if it works for you.
> 
> 
>  > BTW, I have committed the AIX patchs and the library now does work
>  > nicely on that Unix. Model now compiles using IBM native 
> compiler (xlc)
>  > and its compilation time is low.
> 
> Ok, great. I took a short look at the code, and have just now 
> included 
> full CFLAGS and LDFLAGS for sundials and libsbml in the "command" 
> construction. Is this OK for AIX?
> 
> Are there any differences except for the different "command"? 
> I haven't 
> noticed any, and if not, we could probably move it into the existing 
> compile_with_gcc function and just construct a different "command" 
> system call, just as done for APPLE currently.
> 
> Rainer
> 

[SOSlib-discuss] sparse Jacobi matrix, DENSE_ELEM, removing 0s

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

Hi there,

For large models with a very sparse Jacobi matrix, it is much more 
efficient to NOT print out all the DENSE_ELEM[] = 0 commands for the gcc 
compiler.

So I have added this to construction of the forward and adjoint Jacobi 
evaluation function. From looking at the results and the CVODES examples 
I think that it is OK, to just not initialize or set the DENSE_ELEM 
things for the 0 entries.


However, I guess that could also be very useful for the hard-coded 
R.H.S. functions (used by both evaluateAST and the arithmeticCompiler).

So instead of looping through the neq*neq matrix, we could generate some 
sort of list, which contains the correct Jacobi matrix equation (only 
for non-0 entris) and the indices i,j to which Jacobi element it refers 
to. Then just loop through this list instead of through neq*neq.


What do you think? Worth a try?

Rainer

Re: [SOSlib-discuss] SOSlib, libSBML and libxml2

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

Hi Eric,

Great, thanks! We are just now starting to prepair for the release. this 
time for real :)

I have changed the default in config/sbml.m4 to libxml2. Maybe you can 
try if it works for you.


 > BTW, I have committed the AIX patchs and the library now does work
 > nicely on that Unix. Model now compiles using IBM native compiler (xlc)
 > and its compilation time is low.

Ok, great. I took a short look at the code, and have just now included 
full CFLAGS and LDFLAGS for sundials and libsbml in the "command" 
construction. Is this OK for AIX?

Are there any differences except for the different "command"? I haven't 
noticed any, and if not, we could probably move it into the existing 
compile_with_gcc function and just construct a different "command" 
system call, just as done for APPLE currently.

Rainer


Eric Fernandez wrote:
> Hi,
> 
> I have seen that libSBML now uses libxml2 as their default XML C parser.
> They still support Expat and Xerces though, but that would be nice to
> make SOS consistent with libSBML and make it support the three XML
> parsers. However, I have been unable to compile SOS with libxml2. I
> guess the issue here is with the configure switches for linking libSBML
> to SOSlib ? Has anyone an idea of what to change (I guess: configure.in
> and config/sbml.m4 ?).
> 
> BTW, I have committed the AIX patchs and the library now does work
> nicely on that Unix. Model now compiles using IBM native compiler (xlc)
> and its compilation time is low. I don't know if there are other AIX
> users there, but please let me know if you see any issue.
> 
> Thanks,
> Eric
> 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> sbmlsolver-discuss mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbmlsolver-discuss

[SOSlib-discuss] SOSlib, libSBML and libxml2

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

Hi,

I have seen that libSBML now uses libxml2 as their default XML C parser.
They still support Expat and Xerces though, but that would be nice to
make SOS consistent with libSBML and make it support the three XML
parsers. However, I have been unable to compile SOS with libxml2. I
guess the issue here is with the configure switches for linking libSBML
to SOSlib ? Has anyone an idea of what to change (I guess: configure.in
and config/sbml.m4 ?).

BTW, I have committed the AIX patchs and the library now does work
nicely on that Unix. Model now compiles using IBM native compiler (xlc)
and its compilation time is low. I don't know if there are other AIX
users there, but please let me know if you see any issue.

Thanks,
Eric

[SOSlib-discuss] Identifying algebraic parts of DAE system

[Randall B. <r.b...@au...>]

Hi

 

Andrew Miller has created code for decomposing a system of DAE's into
possibly many algebraic subsystems and one differential system, which can
then be solved in a decoupled manner.

 

This code is part of the open source CellML api, I'm not sure if it would be
useful to you, but it seems related to a comment on
http://www.tbi.univie.ac.at/~raim/odeSolver/doc/api/group__ida.html: "This
code is not working yet. It is not compiled with the current package. It is
included in the documentation merely to motivate people to help us implement
this functionality. The main problem is that ODE construction currently
can't decide which variables are to be defined via algebraic constraints.
Contact us, if you want to help!"

 

The code is available from
https://svn.physiomeproject.org/svn/physiome/CellML_DOM_API/

 

A visual diff showing the relevant code is visible at
http://svnviewer.bioeng.auckland.ac.nz/projects/physiome/changeset/2344,
though there have been minor changes to it since.

 

Regards,

 

Randall Britten

___________________________

Software Development Leader

Bioengineering Institute

Auckland University

 

 

 

Re: [SOSlib-discuss] AIX patch for compiler.c[Scanned]

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

> -----Original Message-----
> From: Rainer Machne [mailto:ra...@tb...] 
> Sent: 10 July 2008 16:24
> To: Eric Fernandez
> Cc: sbm...@li...
> Subject: Re: [SOSlib-discuss] AIX patch for compiler.c[Scanned]
> 
> Hi Eric,
> 
> great, thanks!
> 
> sorry for the still missing replies to your previous emails, 
> we are quite in some stress here.
> 
> Would you want a CVS developer access? You could directly 
> submit such AIX-related changes.
> 
> Rainer

Hi Rainer,

Thanks, no problem. 

I would be pleased - and honoured - to get a dev access. I'll try not to
commit too dirty code though ;)

Regards,
Eric 

Re: [SOSlib-discuss] AIX patch for compiler.c

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

Hi Eric,

great, thanks!

sorry for the still missing replies to your previous emails, we are 
quite in some stress here.

Would you want a CVS developer access? You could directly submit such 
AIX-related changes.

Rainer

Eric Fernandez wrote:
> Hi,
> 
> As promised in my previous email, please find the patch for compiler.c
> that adds compilation on AIX using xlc_r (the IBM compiler).
> 
> Regards,
> Eric
> 
> 
> --- SBML_odeSolver.orig/src/compiler.c  2008-03-11 18:21:26.000000000
> +0000
> +++ SBML_odeSolver/src/compiler.c       2008-07-10 16:05:10.000000000
> +0100
> @@ -54,6 +54,8 @@
>  
>  #endif /* end WIN32 */
>  
> +#define _DEBUG 1
> +#define AIX 1
>  
>  #ifdef WIN32
>  
> @@ -172,6 +174,123 @@
>    return (code);
>  }
>  
> +#elif defined AIX /* AIX use xlc_r */
> +
> +/**
> +   Returns a pointer to code that is compiled from the given source
> code
> +*/
> +compiled_code_t *Compiler_compile_with_xlc(const char *sourceCode)
> +{
> +  compiled_code_t *code = NULL;
> +  char gccFileName[MAX_PATH+1] = "xlc_r"; 
> +  int result;
> +  char *tmpFileName = NULL;
> +  char *cFileName   = NULL;
> +  char *dllFileName = NULL;
> +  char *oFileName   = NULL;
> +  FILE *cFile;
> +  char command[4*MAX_PATH];
> +  void *dllHandle;
> +
> +  /* generate a unique temprorary filename template */
> +  ASSIGN_NEW_MEMORY_BLOCK(tmpFileName, (MAX_PATH+1), char, NULL);
> +  tmpFileName = tmpnam(tmpFileName);
> +  
> +#ifdef _DEBUG
> +  Warn(NULL,"Temporary File Name is %s\n", tmpFileName);
> +#endif
> +  
> +  /* generate needed file names from the template*/
> +  ASSIGN_NEW_MEMORY_BLOCK(cFileName, (strlen(tmpFileName)+3), char,
> NULL);
> +  strcpy(cFileName, tmpFileName);
> +  strcat(cFileName, ".c");
> +  ASSIGN_NEW_MEMORY_BLOCK(oFileName, (strlen(tmpFileName)+3), char,
> NULL);
> +  strcpy(oFileName, tmpFileName);
> +  strcat(oFileName, ".o");  
> +  ASSIGN_NEW_MEMORY_BLOCK(dllFileName,
> +                         (strlen(tmpFileName)+strlen(SHAREDLIBEXT)+1),
> +                         char, NULL);
> +  strcpy(dllFileName, tmpFileName);
> +  strcat(dllFileName, SHAREDLIBEXT);
> +
> +  /* open file and dump source code to it */
> +  cFile = fopen(cFileName, "w");
> +  
> +  if (!cFile)
> +  {
> +    SolverError_error(WARNING_ERROR_TYPE, SOLVER_ERROR_OPEN_FILE,
> +                     "Could not open file %s - %s!",
> +                     cFileName, strerror(errno));  
> +    return NULL;
> +  }
> +
> +  fprintf(cFile, sourceCode);
> +  fclose(cFile);
> +
> +  /* construct command for compiling */
> +  sprintf(command, "%s -I%s -I%s -I../src -G -O1 -o %s %s -L../src -L%s
> -lODES -lsbml -lm",
> +         gccFileName,
> +         SUNDIALS_CFLAGS,
> +         SOSLIB_CFLAGS,
> +         dllFileName,
> +         cFileName,
> +         SOSLIB_LDFLAGS);
> +
> +#ifdef _DEBUG
> +  Warn(NULL, "Command: %s\n", command);
> +  Warn(NULL,
> +       "%s -I%s -I%s -I../src -G -O1 -o %s %s -L../src -L%s -lODES
> -lsbml -lm",
> +       gccFileName,
> +       SUNDIALS_CFLAGS,
> +       SOSLIB_CFLAGS,
> +       dllFileName,
> +       cFileName,
> +       SOSLIB_LDFLAGS);
> +#endif
> +  
> +  /* compile source to shared library */
> +  result = system(command);
> +
> +  /* handle possible errors */
> +  if (result == -1)
> +  {
> +    SolverError_error(WARNING_ERROR_TYPE, SOLVER_ERROR_GCC_FORK_FAILED,
> +                     "forking gcc compiler subprocess failed!");
> +    return (NULL);
> +  }
> +  else if (result != 0)
> +  {
> +    SolverError_error(WARNING_ERROR_TYPE,
> SOLVER_ERROR_COMPILATION_FAILED,
> +                     "compiling failed with errno %d - %s!",
> +                     result, strerror(result));    
> +    return (NULL);
> +  }
> +
> +  /* clean up compilation intermediates */
> +  free(tmpFileName);
> +  remove(cFileName);
> +  free(cFileName);
> +  remove(oFileName);
> +  free(oFileName);
> 
> +
> +  /* load shared library */
> +  dllHandle = dlopen(dllFileName, RTLD_LAZY);
> +  if (dllHandle == NULL)
> +  {
> +    SolverError_error(WARNING_ERROR_TYPE, SOLVER_ERROR_DL_LOAD_FAILED,
> +                     "loading shared library %s failed %d - %s!",
> +                     dllFileName, errno, strerror(errno));
> +    SolverError_dumpAndClearErrors();
> +    return (NULL);
> +  }
> +
> +  ASSIGN_NEW_MEMORY(code, compiled_code_t, NULL);
> +  code->dllHandle   = dllHandle;
> +  code->dllFileName = dllFileName;
> +
> +  return (code);
> +}
> +
>  #else /* default case is compile with gcc */
>  
>  /**
> @@ -237,7 +356,7 @@
>        SBML_LDFLAGS,
>           SOSLIB_LDFLAGS);
>  #else
> -  sprintf(command, "%s -I%s -I%s -I../src -pipe -O -shared -fPIC -o %s
> %s -L../src -L%s -lODES -lm",
> +  sprintf(command, "%s -I%s -I%s -I../src -pipe -O -shared -fPIC -o %s
> %s -L../src -L%s -lODES -lsbml -lm -lstdc++",
>           gccFileName,
>           SUNDIALS_CFLAGS,
>           SOSLIB_CFLAGS,
> @@ -261,7 +380,7 @@
>         SOSLIB_LDFLAGS);
>  #else
>    Warn(NULL,
> -       "%s -I%s -I%s -I../src -pipe -O -shared -fPIC -o %s %s -L../src
> -L%s -lODES -lm",
> +       "%s -I%s -I%s -I../src -pipe -O -shared -fPIC -o %s %s -L../src
> -L%s -lODES -lsbml -lm -lstdc++",
>         gccFileName,
>         SUNDIALS_CFLAGS,
>         SOSLIB_CFLAGS,
> @@ -314,6 +433,8 @@
>    return (code);
>  }
>  
> +
> +
>  #endif /* end WIN32 */
>  
>  /**
> @@ -326,6 +447,10 @@
>  #ifdef WIN32
>  
>    code = Compiler_compile_with_tcc(sourceCode);
> +
> +#elif defined AIX
> +
> +  code = Compiler_compile_with_xlc(sourceCode);
>    
>  #else
> 
> -------------------------------------------------------------------------
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> _______________________________________________
> sbmlsolver-discuss mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbmlsolver-discuss

[SOSlib-discuss] AIX patch for compiler.c

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

Hi,

As promised in my previous email, please find the patch for compiler.c
that adds compilation on AIX using xlc_r (the IBM compiler).

Regards,
Eric


--- SBML_odeSolver.orig/src/compiler.c  2008-03-11 18:21:26.000000000
+0000
+++ SBML_odeSolver/src/compiler.c       2008-07-10 16:05:10.000000000
+0100
@@ -54,6 +54,8 @@
 
 #endif /* end WIN32 */
 
+#define _DEBUG 1
+#define AIX 1
 
 #ifdef WIN32
 
@@ -172,6 +174,123 @@
   return (code);
 }
 
+#elif defined AIX /* AIX use xlc_r */
+
+/**
+   Returns a pointer to code that is compiled from the given source
code
+*/
+compiled_code_t *Compiler_compile_with_xlc(const char *sourceCode)
+{
+  compiled_code_t *code = NULL;
+  char gccFileName[MAX_PATH+1] = "xlc_r"; 
+  int result;
+  char *tmpFileName = NULL;
+  char *cFileName   = NULL;
+  char *dllFileName = NULL;
+  char *oFileName   = NULL;
+  FILE *cFile;
+  char command[4*MAX_PATH];
+  void *dllHandle;
+
+  /* generate a unique temprorary filename template */
+  ASSIGN_NEW_MEMORY_BLOCK(tmpFileName, (MAX_PATH+1), char, NULL);
+  tmpFileName = tmpnam(tmpFileName);
+  
+#ifdef _DEBUG
+  Warn(NULL,"Temporary File Name is %s\n", tmpFileName);
+#endif
+  
+  /* generate needed file names from the template*/
+  ASSIGN_NEW_MEMORY_BLOCK(cFileName, (strlen(tmpFileName)+3), char,
NULL);
+  strcpy(cFileName, tmpFileName);
+  strcat(cFileName, ".c");
+  ASSIGN_NEW_MEMORY_BLOCK(oFileName, (strlen(tmpFileName)+3), char,
NULL);
+  strcpy(oFileName, tmpFileName);
+  strcat(oFileName, ".o");  
+  ASSIGN_NEW_MEMORY_BLOCK(dllFileName,
+                         (strlen(tmpFileName)+strlen(SHAREDLIBEXT)+1),
+                         char, NULL);
+  strcpy(dllFileName, tmpFileName);
+  strcat(dllFileName, SHAREDLIBEXT);
+
+  /* open file and dump source code to it */
+  cFile = fopen(cFileName, "w");
+  
+  if (!cFile)
+  {
+    SolverError_error(WARNING_ERROR_TYPE, SOLVER_ERROR_OPEN_FILE,
+                     "Could not open file %s - %s!",
+                     cFileName, strerror(errno));  
+    return NULL;
+  }
+
+  fprintf(cFile, sourceCode);
+  fclose(cFile);
+
+  /* construct command for compiling */
+  sprintf(command, "%s -I%s -I%s -I../src -G -O1 -o %s %s -L../src -L%s
-lODES -lsbml -lm",
+         gccFileName,
+         SUNDIALS_CFLAGS,
+         SOSLIB_CFLAGS,
+         dllFileName,
+         cFileName,
+         SOSLIB_LDFLAGS);
+
+#ifdef _DEBUG
+  Warn(NULL, "Command: %s\n", command);
+  Warn(NULL,
+       "%s -I%s -I%s -I../src -G -O1 -o %s %s -L../src -L%s -lODES
-lsbml -lm",
+       gccFileName,
+       SUNDIALS_CFLAGS,
+       SOSLIB_CFLAGS,
+       dllFileName,
+       cFileName,
+       SOSLIB_LDFLAGS);
+#endif
+  
+  /* compile source to shared library */
+  result = system(command);
+
+  /* handle possible errors */
+  if (result == -1)
+  {
+    SolverError_error(WARNING_ERROR_TYPE, SOLVER_ERROR_GCC_FORK_FAILED,
+                     "forking gcc compiler subprocess failed!");
+    return (NULL);
+  }
+  else if (result != 0)
+  {
+    SolverError_error(WARNING_ERROR_TYPE,
SOLVER_ERROR_COMPILATION_FAILED,
+                     "compiling failed with errno %d - %s!",
+                     result, strerror(result));    
+    return (NULL);
+  }
+
+  /* clean up compilation intermediates */
+  free(tmpFileName);
+  remove(cFileName);
+  free(cFileName);
+  remove(oFileName);
+  free(oFileName);

+
+  /* load shared library */
+  dllHandle = dlopen(dllFileName, RTLD_LAZY);
+  if (dllHandle == NULL)
+  {
+    SolverError_error(WARNING_ERROR_TYPE, SOLVER_ERROR_DL_LOAD_FAILED,
+                     "loading shared library %s failed %d - %s!",
+                     dllFileName, errno, strerror(errno));
+    SolverError_dumpAndClearErrors();
+    return (NULL);
+  }
+
+  ASSIGN_NEW_MEMORY(code, compiled_code_t, NULL);
+  code->dllHandle   = dllHandle;
+  code->dllFileName = dllFileName;
+
+  return (code);
+}
+
 #else /* default case is compile with gcc */
 
 /**
@@ -237,7 +356,7 @@
       SBML_LDFLAGS,
          SOSLIB_LDFLAGS);
 #else
-  sprintf(command, "%s -I%s -I%s -I../src -pipe -O -shared -fPIC -o %s
%s -L../src -L%s -lODES -lm",
+  sprintf(command, "%s -I%s -I%s -I../src -pipe -O -shared -fPIC -o %s
%s -L../src -L%s -lODES -lsbml -lm -lstdc++",
          gccFileName,
          SUNDIALS_CFLAGS,
          SOSLIB_CFLAGS,
@@ -261,7 +380,7 @@
        SOSLIB_LDFLAGS);
 #else
   Warn(NULL,
-       "%s -I%s -I%s -I../src -pipe -O -shared -fPIC -o %s %s -L../src
-L%s -lODES -lm",
+       "%s -I%s -I%s -I../src -pipe -O -shared -fPIC -o %s %s -L../src
-L%s -lODES -lsbml -lm -lstdc++",
        gccFileName,
        SUNDIALS_CFLAGS,
        SOSLIB_CFLAGS,
@@ -314,6 +433,8 @@
   return (code);
 }
 
+
+
 #endif /* end WIN32 */
 
 /**
@@ -326,6 +447,10 @@
 #ifdef WIN32
 
   code = Compiler_compile_with_tcc(sourceCode);
+
+#elif defined AIX
+
+  code = Compiler_compile_with_xlc(sourceCode);
   
 #else

Re: [SOSlib-discuss] [sbml-interoperability] libSBML 3.1.1 and SOSLib CVS version

[Chang, C. <Chr...@nr...>]

Rainer,

   Thanks for the info. We'll see what we can do until the next release.

Best wishes,

Chris 

> -----Original Message-----
> From: Rainer Machne [mailto:ra...@tb...] 
> Sent: Wednesday, July 09, 2008 6:37 AM
> To: Chang, Christopher
> Cc: SBML Software Interoperability Discussion List; 
> sbm...@li...
> Subject: Re: [sbml-interoperability] libSBML 3.1.1 and SOSLib 
> CVS version
> 
> Hi Chris,
> 
> Chris wrote:
> > Sorry for the indirect post, I realize this is more of an 
> SOSLib issue, but I thought I'd ask here in case anyone 
> knows. We're posting to the SOSLib site separately...
> > 
> > We have a model consistent with SBML level 2, version 3, 
> rev 2, and libSBML 3.1.1 installed. We use SOSLib for 
> translation of our SBML model to C code; however, the last 
> release of SOSLib depends on an older SBML library and 
> language that is inconsistent with our model. The CVS version 
> of SOSLib should work with libSBML 3.
> > 
> 
> 
> FYI, SOSlib  internally also generates C-code (with option -c 
> SUNDIALS-specific
> functions are generated and compiled using GCC, instead of 
> using libSBML 
> AST evaluation),
> and the current CVS version can actually translate libSBML 
> ASTs directly 
> to machine code
> (windows and linux, 32bit and 64bit architectures).
> 
> > Questions:
> > - Are there other tools people use for SBML-to-C translation?
> > - Has anyone managed to build the CVS version of SOSLib 
> successfully? The autoconf/automake input and configure.txt 
> seem to be broken.
> 
> Sorry, the configure.txt was outdated. I have updated it for 
> now, but in 
> general when using the CVS version, you should generate your own 
> configure by using ./autogen.sh.
> 
> 
> > - Will there be a future release of SOSLib? CVS commitments 
> seems to be sporadic, so perhaps soon?
> 
> Yes, but unfortunately we are all snowed under work on other 
> projects. 
> We hope to release this summer though.
> 
> Rainer
> 
> > 
> > Anyway, thanks for any advice,
> > 
> > Chris
> > --
> > Christopher H. Chang, Ph.D.
> > Scientist II
> > National Renewable Energy Laboratory
> > 1617 Cole Blvd., MS 1608
> > Golden, CO  80401
> > ____________________________________________________________
> > To manage your sbml-interoperability list subscription, visit 
> > https://utils.its.caltech.edu/mailman/listinfo/sbml-interoperability
> > 
> > For a web interface to the sbml-interoperability mailing list, visit
> > http://sbml.org/Forums/
> > 
> > For questions or feedback about the sbml-interoperability list,
> > contact sbm...@ca...
> 
> 

Re: [SOSlib-discuss] [sbml-interoperability] libSBML 3.1.1 and SOSLib CVS version

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

Hi Chris,

Chris wrote:
> Sorry for the indirect post, I realize this is more of an SOSLib issue, but I thought I'd ask here in case anyone knows. We're posting to the SOSLib site separately...
> 
> We have a model consistent with SBML level 2, version 3, rev 2, and libSBML 3.1.1 installed. We use SOSLib for translation of our SBML model to C code; however, the last release of SOSLib depends on an older SBML library and language that is inconsistent with our model. The CVS version of SOSLib should work with libSBML 3.
> 


FYI, SOSlib  internally also generates C-code (with option -c 
SUNDIALS-specific
functions are generated and compiled using GCC, instead of using libSBML 
AST evaluation),
and the current CVS version can actually translate libSBML ASTs directly 
to machine code
(windows and linux, 32bit and 64bit architectures).

> Questions:
> - Are there other tools people use for SBML-to-C translation?
> - Has anyone managed to build the CVS version of SOSLib successfully? The autoconf/automake input and configure.txt seem to be broken.

Sorry, the configure.txt was outdated. I have updated it for now, but in 
general when using the CVS version, you should generate your own 
configure by using ./autogen.sh.


> - Will there be a future release of SOSLib? CVS commitments seems to be sporadic, so perhaps soon?

Yes, but unfortunately we are all snowed under work on other projects. 
We hope to release this summer though.

Rainer

> 
> Anyway, thanks for any advice,
> 
> Chris
> --
> Christopher H. Chang, Ph.D.
> Scientist II
> National Renewable Energy Laboratory
> 1617 Cole Blvd., MS 1608
> Golden, CO  80401
> ____________________________________________________________
> To manage your sbml-interoperability list subscription, visit 
> https://utils.its.caltech.edu/mailman/listinfo/sbml-interoperability
> 
> For a web interface to the sbml-interoperability mailing list, visit
> http://sbml.org/Forums/
> 
> For questions or feedback about the sbml-interoperability list,
> contact sbm...@ca...

[SOSlib-discuss] function name strangeness in compiler.c ?

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

Hi,

I was studying the code of compiler.c and saw something weird.

The Win32 compilation function is called (line 61):

compiled_code_t *Compiler_compile_win32_tcc(const char *sourceCode)

but it is called there (line 277):

#ifdef WIN32

  code = Compiler_compile_with_tcc(sourceCode);

#else


Since I do not compile under Windows, I do not get compilation error,
but isn't there a function name discrepancy here?

Eric

[SOSlib-discuss] FW: AIX, Re: SOSlib: arithmetic compiler issues

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

> > Rainer Machne wrote:
> > this might be a general problem with current gcc
> compilation. For some
> > other reason I have just integrated a quite large model and can 
> > confirm that gcc compilation also on my machine takes surprisingly 
> > long. We should investigate this problem, but currently we
> don't have
> > much time unfortunately.
> 
> Ok, I have just analyzed this a bit. Most time is indeed spent by the 
> compiler, and not e.g. in loading the .so/library file.
> 
> This model has 93 ODEs, and the resulting c file is 1.2 MB big! Is 
> this file size a bottle-neck for gcc file parsing?
> 
> Some ways to decrease file size:
> The majority of this file are 0 entries of the Jacobian. If CVODE 
> initializes these correctly (DENSE_ELEM makro), then we could just 
> skip all these equations. Also the whole adjoint stuff is co-compiled,

> even if not requested. This is another big part of the file, and the 
> according functions could be compiled separately, on request.
> 
> what do you think?

Hi,

I am coming back to you regarding the issues I get using model
compilation on AIX (old method, using gcc) and would like to share my
findings.

I previously reported how slow gcc was to compile models, taking
sometime almost 2 minutes. This time was proportional to the size of the
value array in the c file, and not the overall "complexity" of the model
(nb of species and events for instance). Also, it is very dependent on
the level of optimization the compiler is set.

I tried compiling bhalla_02.xml MAPK model with gcc and xlc_r (IBM
compiler on AIX) and got those results (in seconds):

For gcc I used something like:
time gcc -I/hpc/work/fernandz/local/include
-I/hpc/work/fernandz/local/include -I../src -pipe -shared -fPIC -o ./out
./model.c -L../src -L/hpc/work/fernandz/local/lib -lODES -lsbml -lm
-lstdc++ -O0

For xlc_r I used something like:
time xlc_r -I/hpc/work/fernandz/local/include
-I/hpc/work/fernandz/local/include -I../src -G -o out ./model.c -L../src
-L/hpc/work/fernandz/local/lib -lODES -lsbml -lm

gcc
-O0 15.4
-O1 108
-O3 334

xlc_r
-O0 1.7
-O1 1.7
-O2 20
-O3 21
-O5 fails with unresolved references

I share your opinion Rainer: if we can drop the 0 entries it might
significantly accelerate the compilation time. Obviously gcc has some
issues on AIX to compile such kind of code, but xlc_r does not shine
either at higher optimization levels.
Also, I replaced gcc with xlc_r in compiler.c (and replaced -shared with
-G, removed other options like -pipe, -fPIC, -lstdc++), set -O0 and it
works very well. Maybe that would be nice to have a compile_with_xlc_r
function for AIX users. I'll try to send a patch when I do it cleanly.

Eric

Re: [SOSlib-discuss] sink reactions

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

Michael Lawrence wrote:

> Looks like I've figured this one out. I had passed the XML through 
> libsbml and its MathML to formula routines. Apparently, it got confused 
> between the constant pi and the symbol for inorganic phosphate Pi. 
> That's kind of funny.

Hehe, I had the same problem once. So, I guess it is not on libSBML's 
side? Otherwise it would also be in SOSlib and it should be fixed of 
course.

Also it would be interesting to learn why BioUML apparently had the same 
effect only for their SBWOdeSolver wrapper. Do they also pre-process the 
SBML?

> 
> Sorry for taking up so much of your time.

No problem!

Check out the new online compiler :) It is supposed to work on 32 and 64 
bit under Windows and Unix.

Rainer

Re: [SOSlib-discuss] sink reactions

[Michael L. <mfl...@fh...>]

On Fri, May 30, 2008 at 11:14 AM, Rainer Machne <ra...@tb...>
wrote:

> Michael Lawrence wrote:
>
>  I stated above:
>>
>> I am using the CVS as of about a week ago. Don't think it's changed since
>> then. And I believe those BioUML test results (for what they call
>> SBWODESolver) are from the CVS back in December.
>>
>>
> Oh I am sorry! I have overread that!
>
> In that case, the only thing i can think of is that the model is outdated.
> Could that be? I have tried before to get the model they used at BioUML, but
> it is not online anymore. Also they don't have a model version history at
> biomodels, or at least i couldn't find any.
> Could you send me your version, or try to get the current from Biomodels?
>
> I have just removed all changes I had towards the CVS and I don't get this
> behaviour but the apparently correct results, see values below.
>
> It would be strange if it was somehow platform-dependent. What are you
> using?
>
> Also, while we did commit changes during the last week, I can't imagine
> that they should have this effect. But to make sure, could you update the
> CVS, please?
>
> (also, while you are on it and if you are using SOSlib for long and heavy
> runs, you might be interested in testing the new compiler ;) just comment in
> #define ARITHMETIC_TEST in src/sbmlsolver/arithmeticCompiler.h which gives
> can give you a 3-4x speedup ;) )
>
> Rainer
>
>
> odeSolver --time 70 BIOMD0000000015.xml
>
> #t      HX
> ##CONCENTRATIONS
> 0       9.51785
> 1.4     9.51785
> 2.8     9.51786
> 4.2     9.51786
> 5.6     9.51786
> 7       9.51786
> 8.4     9.51786
> 9.8     9.51786
> 11.2    9.51786
> 12.6    9.51786
> 14      9.51786
> 15.4    9.51786
> 16.8    9.51786
> 18.2    9.51786
> 19.6    9.51786
> 21      9.51786
> 22.4    9.51786
> 23.8    9.51786
> 25.2    9.51786
> 26.6    9.51786
> 28      9.51786
> 29.4    9.51786
> 30.8    9.51786
> 32.2    9.51786
> 33.6    9.51786
> 35      9.51786
> 36.4    9.51786
> 37.8    9.51786
> 39.2    9.51786
> 40.6    9.51786
> 42      9.51786
> 43.4    9.51786
> 44.8    9.51786
> 46.2    9.51786
> 47.6    9.51786
> 49      9.51786
> 50.4    9.51786
> 51.8    9.51786
> 53.2    9.51786
> 54.6    9.51786
> 56      9.51786
> 57.4    9.51786
> 58.8    9.51786
> 60.2    9.51786
> 61.6    9.51786
> 63      9.51786
> 64.4    9.51786
> 65.8    9.51786
> 67.2    9.51786
> 68.6    9.51787
> 70      9.51787
> ##CONCENTRATIONS
> #t      HX
>
> ... and the same with the corrected initialAmount:
>
> odeSolver --time 70 BIOMD0000000015.xml.corrected.xml
>
> #t      HX
> ##CONCENTRATIONS
> 0       9.51785
> 1.4     7.29934
> 2.8     8.75094
> 4.2     9.76402
> 5.6     10.4581
> 7       10.9211
> 8.4     11.2168
> 9.8     11.3914
> 11.2    11.4791
> 12.6    11.505
> 14      11.4878
> 15.4    11.4411
> 16.8    11.3749
> 18.2    11.2966
> 19.6    11.2116
> 21      11.123
> 22.4    11.0339
> 23.8    10.9458
> 25.2    10.8604
> 26.6    10.7786
> 28      10.7008
> 29.4    10.6274
> 30.8    10.5582
> 32.2    10.4931
> 33.6    10.4319
> 35      10.3744
> 36.4    10.3207
> 37.8    10.2706
> 39.2    10.2242
> 40.6    10.1811
> 42      10.1408
> 43.4    10.103
> 44.8    10.0674
> 46.2    10.0343
> 47.6    10.0038
> 49      9.97568
> 50.4    9.94967
> 51.8    9.92517
> 53.2    9.90191
> 54.6    9.87989
> 56      9.85958
> 57.4    9.84113
> 58.8    9.82448
> 60.2    9.80886
> 61.6    9.79395
> 63      9.77958
> 64.4    9.76607
> 65.8    9.75357
> 67.2    9.74221
> 68.6    9.73176
> 70      9.72204
> ##CONCENTRATIONS
> #t      HX
>
> ... which corresponds to the published figure 2.
>


Looks like I've figured this one out. I had passed the XML through libsbml
and its MathML to formula routines. Apparently, it got confused between the
constant pi and the symbol for inorganic phosphate Pi. That's kind of funny.


Sorry for taking up so much of your time.

Michael

Re: [SOSlib-discuss] sink reactions

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

Michael Lawrence wrote:

> I stated above:
> 
> I am using the CVS as of about a week ago. Don't think it's changed 
> since then. And I believe those BioUML test results (for what they call 
> SBWODESolver) are from the CVS back in December.
>

Oh I am sorry! I have overread that!

In that case, the only thing i can think of is that the model is 
outdated. Could that be? I have tried before to get the model they used 
at BioUML, but it is not online anymore. Also they don't have a model 
version history at biomodels, or at least i couldn't find any.
Could you send me your version, or try to get the current from Biomodels?

I have just removed all changes I had towards the CVS and I don't get 
this behaviour but the apparently correct results, see values below.

It would be strange if it was somehow platform-dependent. What are you 
using?

Also, while we did commit changes during the last week, I can't imagine 
that they should have this effect. But to make sure, could you update 
the CVS, please?

(also, while you are on it and if you are using SOSlib for long and 
heavy runs, you might be interested in testing the new compiler ;) just 
comment in #define ARITHMETIC_TEST in 
src/sbmlsolver/arithmeticCompiler.h which gives can give you a 3-4x 
speedup ;) )

Rainer


odeSolver --time 70 BIOMD0000000015.xml

#t      HX
##CONCENTRATIONS
0       9.51785
1.4     9.51785
2.8     9.51786
4.2     9.51786
5.6     9.51786
7       9.51786
8.4     9.51786
9.8     9.51786
11.2    9.51786
12.6    9.51786
14      9.51786
15.4    9.51786
16.8    9.51786
18.2    9.51786
19.6    9.51786
21      9.51786
22.4    9.51786
23.8    9.51786
25.2    9.51786
26.6    9.51786
28      9.51786
29.4    9.51786
30.8    9.51786
32.2    9.51786
33.6    9.51786
35      9.51786
36.4    9.51786
37.8    9.51786
39.2    9.51786
40.6    9.51786
42      9.51786
43.4    9.51786
44.8    9.51786
46.2    9.51786
47.6    9.51786
49      9.51786
50.4    9.51786
51.8    9.51786
53.2    9.51786
54.6    9.51786
56      9.51786
57.4    9.51786
58.8    9.51786
60.2    9.51786
61.6    9.51786
63      9.51786
64.4    9.51786
65.8    9.51786
67.2    9.51786
68.6    9.51787
70      9.51787
##CONCENTRATIONS
#t      HX

... and the same with the corrected initialAmount:

odeSolver --time 70 BIOMD0000000015.xml.corrected.xml

#t      HX
##CONCENTRATIONS
0       9.51785
1.4     7.29934
2.8     8.75094
4.2     9.76402
5.6     10.4581
7       10.9211
8.4     11.2168
9.8     11.3914
11.2    11.4791
12.6    11.505
14      11.4878
15.4    11.4411
16.8    11.3749
18.2    11.2966
19.6    11.2116
21      11.123
22.4    11.0339
23.8    10.9458
25.2    10.8604
26.6    10.7786
28      10.7008
29.4    10.6274
30.8    10.5582
32.2    10.4931
33.6    10.4319
35      10.3744
36.4    10.3207
37.8    10.2706
39.2    10.2242
40.6    10.1811
42      10.1408
43.4    10.103
44.8    10.0674
46.2    10.0343
47.6    10.0038
49      9.97568
50.4    9.94967
51.8    9.92517
53.2    9.90191
54.6    9.87989
56      9.85958
57.4    9.84113
58.8    9.82448
60.2    9.80886
61.6    9.79395
63      9.77958
64.4    9.76607
65.8    9.75357
67.2    9.74221
68.6    9.73176
70      9.72204
##CONCENTRATIONS
#t      HX

... which corresponds to the published figure 2.

Re: [SOSlib-discuss] sink reactions

[Michael L. <mfl...@fh...>]

On Fri, May 30, 2008 at 10:42 AM, Rainer Machne <ra...@tb...>
wrote:

> Michael Lawrence wrote:
>
>
>>
>> On Fri, May 30, 2008 at 10:00 AM, Rainer Machne <ra...@tb...<mailto:
>> ra...@tb...>> wrote:
>>
>>    Michael Lawrence wrote:
>>
>>           When I run odeSolver --time 70 on the model, I get the following
>>           results for HX:
>>
>>            9.51785  37.57650  57.50690  71.10390  80.45370  87.07900
>>         92.03690
>>
>>    ...
>>
>>
>>        Also, my results seem similar to what is happening here:
>>
>>
>> http://www.biouml.org/_biomodels/relativeErrors/BIOMD0000000015.xml.html
>>
>>
>>    Strange!
>>
>>    Which version of the odeSolver are you using?
>>
>>
>> I am using the CVS as of about a week ago. Don't think it's changed since
>> then. And I believe those BioUML test results (for what they call
>> SBWODESolver) are from the CVS back in December.
>>
>>
>>    Are you using other options additionally to --time 70
>>
>>
>> Nope, just --time and the filename.
>>
>>
>>    I have just freshly recompiled 1.6.0 and don't get these results.
>>
>>
>> I haven't tried 1.6.0, yet. Perhaps I should though.
>>
>
> Which version are you using?


I stated above:

I am using the CVS as of about a week ago. Don't think it's changed since
then. And I believe those BioUML test results (for what they call
SBWODESolver) are from the CVS back in December.



> I don't have the old libSBML versions, and currently sbml.org is down, so
> i can't test 1.5.0pre, but it is easily possible that this bug existed back
> then, or even still in 1.6.0pre.
>
> Please check the correct libSBML and SUNDIALS (not Scott Cohen's CVODE
> anymore) libraries for 1.6.0 at
> http://www.tbi.univie.ac.at/~raim/odeSolver/doc/<http://www.tbi.univie.ac.at/%7Eraim/odeSolver/doc/>
>
> I am using the latest of both libraries, but not CVS.


> If you want to go for the CVS version use the latest versions of both
> libSBML and SUNDIALS (CVS has several bugs fixed, and is much faster, with a
> on-line compiler which should already work, but needs to be activated by
> commenting in some line).
>
> Rainer
>
>
>
>>
>>    Rainer
>>
>>
>>
>

Re: [SOSlib-discuss] sink reactions

[Akira F. <fu...@bi...>]

Hi,

On Sat, May 31, 2008 at 2:42 AM, Rainer Machne <ra...@tb...> wrote:
> Which version are you using? I don't have the old libSBML versions, and
> currently sbml.org is down, so i can't test 1.5.0pre, but it is easily
> possible that this bug existed back then, or even still in 1.6.0pre.

Sorry about the down on sbml.org right now. We are now fixing... ;-)
Just in case if you want to download libsbml, please use the following URL:
http://sourceforge.net/projects/sbml

Thanks,
-- 
Akira

Re: [SOSlib-discuss] sink reactions

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

Michael Lawrence wrote:
> 
> 
> On Fri, May 30, 2008 at 10:00 AM, Rainer Machne <ra...@tb... 
> <mailto:ra...@tb...>> wrote:
> 
>     Michael Lawrence wrote:
> 
>            When I run odeSolver --time 70 on the model, I get the following
>            results for HX:
> 
>             9.51785  37.57650  57.50690  71.10390  80.45370  87.07900
>          92.03690
> 
>     ...
> 
> 
>         Also, my results seem similar to what is happening here:
> 
>         http://www.biouml.org/_biomodels/relativeErrors/BIOMD0000000015.xml.html
> 
> 
>     Strange!
> 
>     Which version of the odeSolver are you using?
> 
> 
> I am using the CVS as of about a week ago. Don't think it's changed 
> since then. And I believe those BioUML test results (for what they call 
> SBWODESolver) are from the CVS back in December.
>  
> 
> 
>     Are you using other options additionally to --time 70
> 
> 
> Nope, just --time and the filename.
> 
> 
>     I have just freshly recompiled 1.6.0 and don't get these results.
> 
> 
> I haven't tried 1.6.0, yet. Perhaps I should though.

Which version are you using? I don't have the old libSBML versions, and 
currently sbml.org is down, so i can't test 1.5.0pre, but it is easily 
possible that this bug existed back then, or even still in 1.6.0pre.

Please check the correct libSBML and SUNDIALS (not Scott Cohen's CVODE 
anymore) libraries for 1.6.0 at
http://www.tbi.univie.ac.at/~raim/odeSolver/doc/

If you want to go for the CVS version use the latest versions of both 
libSBML and SUNDIALS (CVS has several bugs fixed, and is much faster, 
with a on-line compiler which should already work, but needs to be 
activated by commenting in some line).

Rainer


>  
> 
> 
>     Rainer
> 
> 

Re: [SOSlib-discuss] sink reactions

[Michael L. <mfl...@fh...>]

On Fri, May 30, 2008 at 10:00 AM, Rainer Machne <ra...@tb...>
wrote:

> Michael Lawrence wrote:
>
>>    When I run odeSolver --time 70 on the model, I get the following
>>    results for HX:
>>
>>     9.51785  37.57650  57.50690  71.10390  80.45370  87.07900  92.03690
>>
> ...
>
>
>> Also, my results seem similar to what is happening here:
>>
>> http://www.biouml.org/_biomodels/relativeErrors/BIOMD0000000015.xml.html
>>
>>
> Strange!
>
> Which version of the odeSolver are you using?


I am using the CVS as of about a week ago. Don't think it's changed since
then. And I believe those BioUML test results (for what they call
SBWODESolver) are from the CVS back in December.


>
> Are you using other options additionally to --time 70
>

Nope, just --time and the filename.


> I have just freshly recompiled 1.6.0 and don't get these results.
>

I haven't tried 1.6.0, yet. Perhaps I should though.


>
> Rainer
>

Re: [SOSlib-discuss] sink reactions

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

Michael Lawrence wrote:
>     When I run odeSolver --time 70 on the model, I get the following
>     results for HX:
> 
>      9.51785  37.57650  57.50690  71.10390  80.45370  87.07900  92.03690
...

> 
> Also, my results seem similar to what is happening here:
> 
> http://www.biouml.org/_biomodels/relativeErrors/BIOMD0000000015.xml.html
> 

Strange!

Which version of the odeSolver are you using?
Are you using other options additionally to --time 70

I have just freshly recompiled 1.6.0 and don't get these results.

Rainer

Re: [SOSlib-discuss] sink reactions

[Michael L. <mfl...@fh...>]

On Fri, May 30, 2008 at 9:25 AM, Michael Lawrence <mfl...@fh...>
wrote:

>
>
> On Fri, May 30, 2008 at 8:11 AM, Rainer Machne <ra...@tb...>
> wrote:
>
>> Michael Lawrence wrote:
>>
>>> I just posted a bug to the tracker about apparent lack of support for
>>> sink reactions (those with only reactants). See e.g. the behavior of HG in
>>> BIOMD0000000015. Does not match up with the expected.
>>>
>>
>> Hi Michael,
>>
>> SOSlib should actually handle sink (and creation) reactions correctly.
>>
>> Do you mean HX? I can't find HG in the model.
>>
>
> Yes sorry HX.
>
>
>>
>> You are right, that the default version of BioModels #15 simulated in
>> SOSlib (both version 1.6.0 and current CVS) does not reproduce e.g. figure 2
>> in the publication or the online simulation results at biomodels database
>> showing species HX.
>>
>> However, for figure 2 the initial concentration of PRPP has been increased
>> from 5 to 50 uM.
>>
>> If I increase PRPP accordingly in the SBML from 5.01742 to 50.1742, I can
>> reproduce the published results (dashed line for GMA version), both with
>> SOSlib v1.6.0 and current CVS.
>>
>> Can you confirm this or did you mean another error?
>>
>
> When I run odeSolver --time 70 on the model, I get the following results
> for HX:
>
>  9.51785  37.57650  57.50690  71.10390  80.45370  87.07900  92.03690
>  96.01670  99.44160 102.55900 105.51100 108.37200 111.18700 113.97600
> 116.75000 119.51500 122.27100 125.01900 127.75700 130.48400 133.19800
> 135.89700 138.57900 141.24200 143.88600 146.50800 149.10600 151.68100
> 154.22900 156.75100 159.24500 161.71000 164.14600 166.55000 168.92400
> 171.26500 173.57500 175.85000 178.09300 180.30100 182.47500 184.61400
> 186.71800 188.78700 190.82000 192.81800 194.78000 196.70600 198.59500
> 200.44900 202.26700
>
> As you can see just by eye, those numbers are monotonically increasing.
> So what is going on here? I must not know what I am doing...
>

Also, my results seem similar to what is happening here:

http://www.biouml.org/_biomodels/relativeErrors/BIOMD0000000015.xml.html



>
> And sorry for presuming there was a bug in the reaction handling.
>
> Michael
>
>
>> Thanks,
>> Rainer
>>
>>
>>> Thanks,
>>> Michael
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> -------------------------------------------------------------------------
>>> This SF.net email is sponsored by: Microsoft
>>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> sbmlsolver-discuss mailing list
>>> sbm...@li...
>>> https://lists.sourceforge.net/lists/listinfo/sbmlsolver-discuss
>>>
>>
>>
>

Re: [SOSlib-discuss] sink reactions

[Michael L. <mfl...@fh...>]

On Fri, May 30, 2008 at 8:11 AM, Rainer Machne <ra...@tb...>
wrote:

> Michael Lawrence wrote:
>
>> I just posted a bug to the tracker about apparent lack of support for sink
>> reactions (those with only reactants). See e.g. the behavior of HG in
>> BIOMD0000000015. Does not match up with the expected.
>>
>
> Hi Michael,
>
> SOSlib should actually handle sink (and creation) reactions correctly.
>
> Do you mean HX? I can't find HG in the model.
>

Yes sorry HX.


>
> You are right, that the default version of BioModels #15 simulated in
> SOSlib (both version 1.6.0 and current CVS) does not reproduce e.g. figure 2
> in the publication or the online simulation results at biomodels database
> showing species HX.
>
> However, for figure 2 the initial concentration of PRPP has been increased
> from 5 to 50 uM.
>
> If I increase PRPP accordingly in the SBML from 5.01742 to 50.1742, I can
> reproduce the published results (dashed line for GMA version), both with
> SOSlib v1.6.0 and current CVS.
>
> Can you confirm this or did you mean another error?
>

When I run odeSolver --time 70 on the model, I get the following results for
HX:

 9.51785  37.57650  57.50690  71.10390  80.45370  87.07900  92.03690
 96.01670  99.44160 102.55900 105.51100 108.37200 111.18700 113.97600
116.75000 119.51500 122.27100 125.01900 127.75700 130.48400 133.19800
135.89700 138.57900 141.24200 143.88600 146.50800 149.10600 151.68100
154.22900 156.75100 159.24500 161.71000 164.14600 166.55000 168.92400
171.26500 173.57500 175.85000 178.09300 180.30100 182.47500 184.61400
186.71800 188.78700 190.82000 192.81800 194.78000 196.70600 198.59500
200.44900 202.26700

As you can see just by eye, those numbers are monotonically increasing.
So what is going on here? I must not know what I am doing...

And sorry for presuming there was a bug in the reaction handling.

Michael


> Thanks,
> Rainer
>
>
>> Thanks,
>> Michael
>>
>>
>> ------------------------------------------------------------------------
>>
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by: Microsoft
>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> sbmlsolver-discuss mailing list
>> sbm...@li...
>> https://lists.sourceforge.net/lists/listinfo/sbmlsolver-discuss
>>
>
>

Re: [SOSlib-discuss] sink reactions

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

Rainer Machne wrote:
> Michael Lawrence wrote:
>> I just posted a bug to the tracker about apparent lack of support for 
>> sink reactions (those with only reactants). See e.g. the behavior of 
>> HG in BIOMD0000000015. Does not match up with the expected.
> 
> Hi Michael,
> 
> SOSlib should actually handle sink (and creation) reactions correctly.
> 
> Do you mean HX? I can't find HG in the model.
> 
> You are right, that the default version of BioModels #15 simulated in 
> SOSlib (both version 1.6.0 and current CVS) does not reproduce e.g. 
> figure 2 in the publication or the online simulation results at 
> biomodels database showing species HX.
> 
> However, for figure 2 the initial concentration of PRPP has been 
> increased from 5 to 50 uM.

I just realized that the figure caption states that this change was 
introduced at t=10. However, I think this is a typo, as I get exactly 
the published results for this change at t=0, also for values between 
t=0 and t=10. I am just writing a comment to biomodels about this.

r


> 
> If I increase PRPP accordingly in the SBML from 5.01742 to 50.1742, I 
> can reproduce the published results (dashed line for GMA version), both 
> with SOSlib v1.6.0 and current CVS.
> 
> Can you confirm this or did you mean another error?
> 
> Thanks,
> Rainer
> 
>>
>> Thanks,
>> Michael
>>
>>
>> ------------------------------------------------------------------------
>>
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by: Microsoft
>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> sbmlsolver-discuss mailing list
>> sbm...@li...
>> https://lists.sourceforge.net/lists/listinfo/sbmlsolver-discuss
> 
>