Re: [SOSlib-devel] Re: Parameter Scan functions in SOSlib

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

Hi Eryk,

> Yes, parameter scans are important and must be supported by Soslib at this
> stage.

As Akira already explained, we decided this at the hackathon 2005, and 
one main reason was that SOSlib wasn't a library back then, and it wasn't 
and still isn't simple to create bindings.

Also, at that time, the interfaces to the integrator itself were not as 
fine-grained and an external application couldn't do the scan as 
efficiently as an internal SOSlib function.

One important point of our current todo list is `C++ bindings' or actually 
C++ versions of all trivial structures, like cvodeResults, SBMLResults, 
and cvodeSettings and get/set methods. This will make it much easier to 
generate bindings via SWIG.

The SBML/Model_odeSolverBatch functions were supposed to be the most 
high-level interface to SOSlib. With the new interface and with bindings 
these functions might not be required anymore in SOSlib.

In the meantime, we should maybe repair the existing Batch functions in 
the way you originally suggested them. See below.

> A sufficient support for parameter scans would be if there are functions
> which enable to change a value of one or more variables and afterwards to
> evaluate (integrate) the model. I understand this can be accomplished by one
> or several calls to "IntegratorInstance_setVariableValue"?

Yes, this function is thought for such purposes. It works on the level of 
the integratorInstance, and thus you don't need to parse the SBML again, 
reconstruct the ODE model or allocate the integrator.

It can even safely set all values of a model DURING integration steps. If 
you change an ODE variable during the integration, then the integrator 
must be reinitialized.
This latter usage actually allows to have external events. 
It is useful for e.g. multi-scale models, but i could also imagine some 
sort of use in parameter testing routines ... Can anyone think of such 
applications?


> I have suggested a few months ago and submitted code which takes new values
> for one or more variables ( a so called design point), sets them and returns
> a SBMLResult.

> Furthermore I suggested to include and submitted code for a function which
> given a set of design points returns an array of SBMLResults. Given this
> function it is trivial to generate a 2D Cartesian design requested by
> Norhiko.
>
> However I can not find this functions which would enable me to interface
> easily with soslib.
>
> Instead, I find a lot of very specialized function which generate a concrete
> experimental design. In my opinion such functions  should not be included
> into soslib at least at this stage for the following reasons:
>
> First, given the functions suggested above it would be easily possible for a
> library user, the application developer, to implement any concrete design he
> needs. Norihiro, why do you think that the parameter scan should be
> implemented in Soslib and not in CellDesigner?

...
> Lets take a look at Model_odeSolverBatch.
> Rainer, what kind of design this function generates? I don't understand. What
> are the references? Why a 2D matrix representation of the results is
> generated? The same questions I have to ask regarding your question 1 and 2
> below.

... and in a later email:

> I do mind a bit, if generic functions, already written and submitted to
> soslib, which would enable to interface between existing libraries and
> soslib, are not supported.


The initial purpose of the current SBML/Model_odeSolverBatch functions was 
actually to realize your (Eryk's) ideas within SOSlib, and as a general
version of the old parameter scan interface function for CellDesigner!!

I didn't take your code directly, because it just called Model_odeSolver 
for each parameter value. This includes new construction of the ODE system 
and new allocation of the integrator. So the idea was to embed it in 
SOSlib in the most efficient way and with our internal error handling.

But I just messed up! As already stated in my first email. They really 
don't do what they are supposed to.

The problem was, that I merged your design function with the Batch 
function without using my brain. They actually do something different. So 
I ended up with functions that don't do either thing correctly. Shame on 
me.

And I strongly apologize, for not acknoweldging your contribution in the 
file headers, but with the last facts told, this was better anyways :-)
It all happened within a large-scale and high-speed programming session 
generating a large set of new API functions last autumn.

To make a new corrected version of all this I started this discussion.

So as a conclusion, I will take a look again at your functions, Eryk, and 
try to optimize them for SOSlib.

Alternatively, I could leave my hands off it and you can redo them, using 
our error handling and the finegrained interface to the integrator.

Rainer











On Thu, 13 Apr 2006, Witold Eryk Wolski wrote:

> Hi Rainer and all,
>
>
> Yes, parameter scans are important and must be supported by Soslib at this 
> stage. However, there are so many strategies to construct designs (parameter 
> scans) that I am not sure if they should be part of soslib at any stage.
>
> A sufficient support for parameter scans would be if there are functions 
> which enable to change a value of one or more variables and afterwards to 
> evaluate (integrate) the model. I understand this can be accomplished by one 
> or several calls to "IntegratorInstance_setVariableValue"?
>
> I have suggested a few months ago and submitted code which takes new values 
> for one or more variables ( a so called design point), sets them and returns 
> a SBMLResult.
>
> Furthermore I suggested to include and submitted code for a function which 
> given a set of design points returns an array of SBMLResults. Given this 
> function it is trivial to generate a 2D Cartesian design requested by 
> Norhiko.
>
> However I can not find this functions which would enable me to interface 
> easily with soslib.
>
> Instead, I find a lot of very specialized function which generate a concrete 
> experimental design. In my opinion such functions  should not be included 
> into soslib at least at this stage for the following reasons:
>
> First, given the functions suggested above it would be easily possible for a 
> library user, the application developer, to implement any concrete design he 
> needs. Norihiro, why do you think that the parameter scan should be 
> implemented in Soslib and not in CellDesigner?
>
> Secondly, adding functions to generate a concrete designs to soslib makes the 
> library unecessarily more complex. Lets take a look at Model_odeSolverBatch. 
> Rainer, what kind of design this function generates? I don't understand. What 
> are the references? Why a 2D matrix representation of the results is 
> generated? The same questions I have to ask regarding your question 1 and 2 
> below.
>
>
> Frohe Ostern
>
> Happy Eastern.
>
>
>
> Rainer Machne wrote:
>> Hi Akira, Eryk and Norihiro,
>> 
>> (CCed also to the SOSlib development list)
>> 
>> you are all using/interested in the high-level SOSlib interface 
>> SBML_odeSolverBatch for efficient parameter/initial condition scans.
>> 
>> Currently, it is implemented with a serious and stupid malfunction - i.e. n 
>> parameters can be varied over m arbitrary points (design points), but there 
>> are no combinations of parameter values.
>> 
>> CellDesigner needs results for each combination of parameter values, and 
>> this is the general requirement for such a batch function.
>> I want to correct this now.
>> 
>> There are two questions:
>> 
>> 1) Do you see a need for n parameters to be varied, and to get a result 
>> structures for each combination? This would result in a n*n*m*m matrix of 
>> SBMLResults. Or is it generally sufficient to provide this scan only for 2 
>> parameters?
>> 
>> 2) As we now want to vary over m arbitrary design points, m (the number of 
>> parameter values to be scanned for one parameter) could be different for 
>> each parameter. I.e. one parameter might be varied over 3 values, while the 
>> other parameter might be varied over 16 values.
>> 
>> Implementing 2, i.e. a different m for each parameter would be much easier 
>> if we restrict the batch function to 2 parameters!
>> 
>> What do you think? Or better asked: what are your requirements?
>> 
>> If you want you can add things to the respective section at
>> http://www.tbi.univie.ac.at/wiki/index.php/SOSlibDevel#Batch_Mode_for_Parameter_Scan 
>> (email ha...@tb... to get an account, mention that you want to 
>> contribute to SOSlibDevel Wiki).
>> 
>> Rainer
>> 
>> 
>
>