Menu
▾
▴
sed-ml-discuss
|
From: Frank B. <fbergman@u.washington.edu> - 2010-03-03 20:16:31
|
Hello all, First of all thank you so much Dagmar for reviving this list. It is good to see the ball moving again. I've been working with SED-ML extensively over the last months. The biggest concern of mine has always been the way that SED-ML is structured. Currently, whenever we want to exchange a new simulation experiment, we need to add a new class to SED-ML. (And no, the AnySimulation class will not be exchangeable, so it should be dropped as soon as possible). That also means that each time a class is added to SED-ML everyone else has to start implementing support for it. This is a sure way for SED-ML to fail as standard! Back in Waiheke last year we tried to resolve that issue by adding the Range classes to the existing simulation experiments like TimeCourse. And it did sound good back then. However, thinking on how to implement it and, perhaps more importantly, how to apply it to other simulation experiments, it proved hard to do. This concept only translates into a triple amount of work for the implementers of the SED-ML format. And so here my proposal. Let us go back to the roots. By defining simple primitives, for a simulation step, bringing the model to steady state, and changing values, we can finally arrive at a truly extendable standard that is also easy to implement. I've placed my thoughts online: http://precedings.nature.com/documents/4257/version/1 Bergmann, Frank. A Simple Nested Simulation for SED-ML. Available from Nature Precedings <http://dx.doi.org/10.1038/npre.2010.4257.1> (2010) Let me know what you think, Best Frank |
|
From: Andrew M. <ak....@au...> - 2010-03-03 21:38:46
|
Frank Bergmann wrote: > Hello all, > > First of all thank you so much Dagmar for reviving this list. It is good to > see the ball moving again. > > I've been working with SED-ML extensively over the last months. The biggest > concern of mine has always been the way that SED-ML is structured. > Currently, whenever we want to exchange a new simulation experiment, we need > to add a new class to SED-ML. (And no, the AnySimulation class will not be > exchangeable, so it should be dropped as soon as possible). That also means > that each time a class is added to SED-ML everyone else has to start > implementing support for it. This is a sure way for SED-ML to fail as > standard! > > Back in Waiheke last year we tried to resolve that issue by adding the Range > classes to the existing simulation experiments like TimeCourse. And it did > sound good back then. However, thinking on how to implement it and, perhaps > more importantly, how to apply it to other simulation experiments, it proved > hard to do. This concept only translates into a triple amount of work for > the implementers of the SED-ML format. > > And so here my proposal. Let us go back to the roots. By defining simple > primitives, for a simulation step, bringing the model to steady state, and > changing values, we can finally arrive at a truly extendable standard that > is also easy to implement. I've placed my thoughts online: > > http://precedings.nature.com/documents/4257/version/1 Hi Frank, A few comments. I think that dealing with 'time' is probably one of the biggest weaknesses in this approach. You wrote: "We could make it convention, that if this is not defined, then the models time parameter is changed". Firstly, as soon as we talk about time, we lose generality; I suggest 'independent variable of integration' or a similar term. I'll refer to it as 'IVOI' here. Secondly, modern DAE / IDA solvers take adaptive steps in their IVOI, rather than fixed steps. Your proposal seems to not allow adaptive step-sizes - rather, it forces the user to specify the step size on 'OneStep'. I think a successful simulation description needs to describe two separate things with regards to 'step size' like parameters of output across IVOIs: => Parameters controlling the internal stepping. For example, allowing for an optional maximum step size to control errors and ensure that the solver finds features like stimulation pulses. => Parameters controlling which data is reported. Some simulations will want to report every internal step, while in others, reporting this data will produce more data than is required. Some times, users don't care exactly which point is reported, but they want one at an approximate interval. For example, if the IVOI is time, a user might want a point approximately every 10 s - i.e. the logic needs to be something like 'do whatever internal stepping, with a maximum internal step of 10s, and report points as long as there has been no report in the last 10s of simulation time'. Other times, users want to compare two models point-by-point, and need a simulation experiment which produces grid aligned values. In this case, the logic is that the simulator can take whatever internal time-steps it wants, but the maximum time-step is the time until the next multiple of 10s, and only multiples of 10s are reported. The above is implemented in CellML Simulation Metadata and the CellML API and OpenCell extensions to it (this metadata focuses entirely on 'time' course experiments at present, but does that one task better than anything proposed for SEDML to date). Best wishes, Andrew > > Bergmann, Frank. A Simple Nested Simulation for SED-ML. Available from > Nature Precedings <http://dx.doi.org/10.1038/npre.2010.4257.1> (2010) > > > Let me know what you think, > Best > Frank > > > ------------------------------------------------------------------------------ > 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 > _______________________________________________ > SED-ML-discuss mailing list > SED...@li... > https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss |
|
From: Frank B. <fbergman@u.washington.edu> - 2010-03-03 21:57:45
|
Hello Andrew: > > A few comments. I think that dealing with 'time' is probably one of the > biggest weaknesses in this approach. You wrote: > "We could make it convention, that if this is not defined, then the > models time parameter is changed". > Firstly, as soon as we talk about time, we lose generality; I suggest > 'independent variable of integration' or a similar term. I'll refer to > it as 'IVOI' here. > Given the frequent use of integration over time, I think we can justify having this class. But I'm open to introduce your IVOI as a more general case. Though I'm afraid many tools will not be able to handle IVOI. > Secondly, modern DAE / IDA solvers take adaptive steps in their IVOI, > rather than fixed steps. Your proposal seems to not allow adaptive > step-sizes - rather, it forces the user to specify the step size on > 'OneStep'. > Definitely, what the oneStep is meant to describe is how far you would like to simulate until your next output point. How many steps the integrator internally takes would be independent of this. > => Parameters controlling the internal stepping. For example, allowing > for an optional maximum step size to control errors and ensure that the > solver finds features like stimulation pulses. Again, the one step approach only tells you when you want your next output point, this can be controlled through the range element on the nested simulation experiment. > => Parameters controlling which data is reported. Some simulations will > want to report every internal step, while in others, reporting this data > will produce more data than is required. This will be defined through the data generators that are defined, just as in the current approach. > The above is implemented in CellML Simulation Metadata and the CellML > API and OpenCell extensions to it (this metadata focuses entirely on > 'time' course experiments at present, but does that one task better than > anything proposed for SEDML to date). > Great! ... so which tools can i download to experiment with it? it would be good to test exchange of simulation experiments that way. best Frank > Best wishes, > Andrew > >> >> Bergmann, Frank. A Simple Nested Simulation for SED-ML. Available from >> Nature Precedings <http://dx.doi.org/10.1038/npre.2010.4257.1> (2010) >> >> >> Let me know what you think, >> Best >> Frank >> >> >> ------------------------------------------------------------------------------ >> 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 >> _______________________________________________ >> SED-ML-discuss mailing list >> SED...@li... >> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss > > > ------------------------------------------------------------------------------ > 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 > _______________________________________________ > SED-ML-discuss mailing list > SED...@li... > https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss |
|
From: Dagmar W. <dag...@un...> - 2010-03-08 16:17:17
|
Hej Frank, I think... I need some sample code to see what you're doing :-) Would you mind posting an example (if you have any available)? Thanks a lot, Dagmar Frank Bergmann wrote: > Hello all, > > First of all thank you so much Dagmar for reviving this list. It is good to > see the ball moving again. > > I've been working with SED-ML extensively over the last months. The biggest > concern of mine has always been the way that SED-ML is structured. > Currently, whenever we want to exchange a new simulation experiment, we need > to add a new class to SED-ML. (And no, the AnySimulation class will not be > exchangeable, so it should be dropped as soon as possible). That also means > that each time a class is added to SED-ML everyone else has to start > implementing support for it. This is a sure way for SED-ML to fail as > standard! > > Back in Waiheke last year we tried to resolve that issue by adding the Range > classes to the existing simulation experiments like TimeCourse. And it did > sound good back then. However, thinking on how to implement it and, perhaps > more importantly, how to apply it to other simulation experiments, it proved > hard to do. This concept only translates into a triple amount of work for > the implementers of the SED-ML format. > > And so here my proposal. Let us go back to the roots. By defining simple > primitives, for a simulation step, bringing the model to steady state, and > changing values, we can finally arrive at a truly extendable standard that > is also easy to implement. I've placed my thoughts online: > > http://precedings.nature.com/documents/4257/version/1 > > Bergmann, Frank. A Simple Nested Simulation for SED-ML. Available from > Nature Precedings <http://dx.doi.org/10.1038/npre.2010.4257.1> (2010) > > > Let me know what you think, > Best > Frank > > > ------------------------------------------------------------------------------ > 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 > _______________________________________________ > SED-ML-discuss mailing list > SED...@li... > https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss > |
|
From: Frank B. <fbergman@u.washington.edu> - 2010-03-08 19:37:32
|
Hello > I think... I need some sample code to see what you're doing :-) Would you > mind posting an example (if you have any available)? > What I posted before was the basic idea I had. I did not yet implement this approach, but it will be in LibSedML by the time of the hackathon, if more people find it of interest. (Otherwise I just have to hide it in the annotation section). After your mail I went ahead and posted more detail here: http://frank-fbergmann.blogspot.com/2010/03/nested-simulation-experiments.ht ml I hope this helps, Best Frank > Thanks a lot, > Dagmar > > > Frank Bergmann wrote: > > Hello all, > > > > First of all thank you so much Dagmar for reviving this list. It is > > good to see the ball moving again. > > > > I've been working with SED-ML extensively over the last months. The > > biggest concern of mine has always been the way that SED-ML is > structured. > > Currently, whenever we want to exchange a new simulation experiment, > > we need to add a new class to SED-ML. (And no, the AnySimulation class > > will not be exchangeable, so it should be dropped as soon as > > possible). That also means that each time a class is added to SED-ML > > everyone else has to start implementing support for it. This is a sure > > way for SED-ML to fail as standard! > > > > Back in Waiheke last year we tried to resolve that issue by adding the > > Range classes to the existing simulation experiments like TimeCourse. > > And it did sound good back then. However, thinking on how to implement > > it and, perhaps more importantly, how to apply it to other simulation > > experiments, it proved hard to do. This concept only translates into a > > triple amount of work for the implementers of the SED-ML format. > > > > And so here my proposal. Let us go back to the roots. By defining > > simple primitives, for a simulation step, bringing the model to steady > > state, and changing values, we can finally arrive at a truly > > extendable standard that is also easy to implement. I've placed my > thoughts online: > > > > http://precedings.nature.com/documents/4257/version/1 > > > > Bergmann, Frank. A Simple Nested Simulation for SED-ML. Available from > > Nature Precedings <http://dx.doi.org/10.1038/npre.2010.4257.1> (2010) > > > > > > Let me know what you think, > > Best > > Frank > > > > > > ---------------------------------------------------------------------- > > -------- 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 > > _______________________________________________ > > SED-ML-discuss mailing list > > SED...@li... > > https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss > > > > > ---------------------------------------------------------------------------- -- > 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 > _______________________________________________ > SED-ML-discuss mailing list > SED...@li... > https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss |
|
From: Jonathan C. <jon...@co...> - 2010-04-30 16:08:48
|
Dear all,
I'm still figuring out the details of my thoughts on SED-ML
developments; we have a particular use-case we're working on. But given
that I can't attend the SED-ML session next week, I thought it'd be
worth sending some initial thoughts to contribute to the discussion.
Firstly, I really like the concept of Frank's nested simulation
experiment. I think defining composable primitives is definitely the way
to go to achieve an expressive yet implementable language.
I think it would definitely be worth allowing multiple setValue and
range constructs within a nested simulation definition. It doesn't
strike me as any more difficult to implement, and it would be useful for
our work. I'd actually recommend requiring ranges to have an id for
referencing within setValue anyway - the use of #current feels too much
like magic to me.
As Andrew Miller has mentioned before, it could be necessary for some
simulations to provide some additional parameters to the integrator.
Relative and absolute tolerance settings can make a significant
difference to the results obtained, and a maximum internal time step is
often essential to avoid missing a stimulus for cardiac models.
I haven't thought about the next point at all really, but Andrew's IVOI
(Independent Variable of Integration) could possibly be done using the
nested simulation proposal. Since setValue can change any model
variable, you could adapt Frank's example implementing a uniform time
course with nestedSimulation to vary whatever variable happened to be
the IVOI.
It is my impression that the intended semantics of setValue is to
perform an immediate change of the referenced variable, and allow it to
vary if simulation of the model under the originalTask causes this. Is
this correct? For my application, I will require to be able to impose
boundary conditions, e.g. by clamping certain state variables to
different values for different periods of simulation. I think this would
be best achieved by a model change, supplying new MathML etc. with a
parameter which can be set in a setValue.
The main limitation in SED-ML currently for my work is the support for
post-processing. As I understand it, the data generators implicitly act
on an array of values (or multiple arrays of the same length if they
take multiple inputs), applying the same operation to each element of
the array and producing an output array of the same length. However, I
want to be able to specify post-processing such as:
* gradient of one variable with respect to another (not necessarily
time)
* take the value of a variable at a specific time (optionally with
interpolation if this wasn't an output point)
* return the peak value of a variable (optionally after a specified
time)
* calculate action potential duration and restitution relations
(which link the action potential duration to the previous
diastolic interval)
I haven't yet figured out an elegant way of specifying these however
(except as Matlab code...). I will also need to be able to use the
output of one post-processing step as the input to another, which I
believe bears some relation to chaining simulations. So this whole topic
can probably wait for a future version of SED-ML!
As always, I'd be very interested to hear people's opinions on these ideas.
Best wishes,
Jonathan
Frank Bergmann wrote:
> Hello
>
>
>> I think... I need some sample code to see what you're doing :-) Would you
>> mind posting an example (if you have any available)?
>>
>>
>
> What I posted before was the basic idea I had. I did not yet implement this
> approach, but it will be in LibSedML by the time of the hackathon, if more
> people find it of interest. (Otherwise I just have to hide it in the
> annotation section). After your mail I went ahead and posted more detail
> here:
>
> http://frank-fbergmann.blogspot.com/2010/03/nested-simulation-experiments.ht
> ml
>
> I hope this helps,
> Best
> Frank
>
>
>> Thanks a lot,
>> Dagmar
>>
>>
>> Frank Bergmann wrote:
>>
>>> Hello all,
>>>
>>> First of all thank you so much Dagmar for reviving this list. It is
>>> good to see the ball moving again.
>>>
>>> I've been working with SED-ML extensively over the last months. The
>>> biggest concern of mine has always been the way that SED-ML is
>>>
>> structured.
>>
>>> Currently, whenever we want to exchange a new simulation experiment,
>>> we need to add a new class to SED-ML. (And no, the AnySimulation class
>>> will not be exchangeable, so it should be dropped as soon as
>>> possible). That also means that each time a class is added to SED-ML
>>> everyone else has to start implementing support for it. This is a sure
>>> way for SED-ML to fail as standard!
>>>
>>> Back in Waiheke last year we tried to resolve that issue by adding the
>>> Range classes to the existing simulation experiments like TimeCourse.
>>> And it did sound good back then. However, thinking on how to implement
>>> it and, perhaps more importantly, how to apply it to other simulation
>>> experiments, it proved hard to do. This concept only translates into a
>>> triple amount of work for the implementers of the SED-ML format.
>>>
>>> And so here my proposal. Let us go back to the roots. By defining
>>> simple primitives, for a simulation step, bringing the model to steady
>>> state, and changing values, we can finally arrive at a truly
>>> extendable standard that is also easy to implement. I've placed my
>>>
>> thoughts online:
>>
>>> http://precedings.nature.com/documents/4257/version/1
>>>
>>> Bergmann, Frank. A Simple Nested Simulation for SED-ML. Available from
>>> Nature Precedings <http://dx.doi.org/10.1038/npre.2010.4257.1> (2010)
>>>
>>>
>>> Let me know what you think,
>>> Best
>>> Frank
>>>
>>>
>>> ----------------------------------------------------------------------
>>> -------- 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
>>> _______________________________________________
>>> SED-ML-discuss mailing list
>>> SED...@li...
>>> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss
>>>
>>>
>>
>>
> ----------------------------------------------------------------------------
> --
>
>> 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
>> _______________________________________________
>> SED-ML-discuss mailing list
>> SED...@li...
>> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss
>>
>
>
> ------------------------------------------------------------------------------
> 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
> _______________________________________________
> SED-ML-discuss mailing list
> SED...@li...
> https://lists.sourceforge.net/lists/listinfo/sed-
>
|
|
From: Richard A. <ra...@st...> - 2010-03-30 14:32:56
|
Frank, I read your proposal on your blog - with the 'setValue' function, are you thinking that is a way of manipulating the model without constraining it to be XML based? So long as a parameter /variable is identifiable, tools capable of accepting a model in a particular format would still be able to manipulate it. I guess this would preclude sweeping structural changes applied to an XML model that can be done with Xpath (removing a reaction, for example) but is the increase in generality for simple cases of value manipulation worth considering? Best wishes Richard > Hello Andrew: > >> >> A few comments. I think that dealing with 'time' is probably one of the >> biggest weaknesses in this approach. You wrote: >> "We could make it convention, that if this is not defined, then the >> models time parameter is changed". >> Firstly, as soon as we talk about time, we lose generality; I suggest >> 'independent variable of integration' or a similar term. I'll refer to >> it as 'IVOI' here. >> > > Given the frequent use of integration over time, I think we can > justify having this class. But I'm open to introduce your IVOI as a > more general case. Though I'm afraid many tools will not be able to > handle IVOI. > >> Secondly, modern DAE / IDA solvers take adaptive steps in their IVOI, >> rather than fixed steps. Your proposal seems to not allow adaptive >> step-sizes - rather, it forces the user to specify the step size on >> 'OneStep'. >> > > Definitely, what the oneStep is meant to describe is how far you > would like to simulate until your next output point. How many steps > the integrator internally takes would be independent of this. > >> => Parameters controlling the internal stepping. For example, allowing >> for an optional maximum step size to control errors and ensure that the >> solver finds features like stimulation pulses. > > Again, the one step approach only tells you when you want your next > output point, this can be controlled through the range element on > the nested simulation experiment. > >> => Parameters controlling which data is reported. Some simulations will >> want to report every internal step, while in others, reporting this data >> will produce more data than is required. > > This will be defined through the data generators that are defined, > just as in the current approach. > >> The above is implemented in CellML Simulation Metadata and the CellML >> API and OpenCell extensions to it (this metadata focuses entirely on >> 'time' course experiments at present, but does that one task better than >> anything proposed for SEDML to date). >> > > Great! ... so which tools can i download to experiment with it? it > would be good to test exchange of simulation experiments that way. > > best > Frank > >> Best wishes, >> Andrew >> >>> >>> Bergmann, Frank. A Simple Nested Simulation for SED-ML. Available from >>> Nature Precedings <http://dx.doi.org/10.1038/npre.2010.4257.1> (2010) >>> >>> >>> Let me know what you think, >>> Best >>> Frank >>> >>> >>> ------------------------------------------------------------------------------ >>> 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 >>> _______________________________________________ >>> SED-ML-discuss mailing list >>> SED...@li... >>> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss >> >> >> ------------------------------------------------------------------------------ >> 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 >> _______________________________________________ >> SED-ML-discuss mailing list >> SED...@li... >> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss > > > ------------------------------------------------------------------------------ > 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 > _______________________________________________ > SED-ML-discuss mailing list > SED...@li... > https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss > > -- Dr Richard Adams Software Development Team Leader, Centre For Systems Biology Edinburgh University of Edinburgh Tel: 0131 650 8285 email : ric...@ed... -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. |
|
From: Frank B. <fbergman@u.washington.edu> - 2010-04-02 17:52:23
|
Hello All, sorry I have been away for the last couple of days. the motivation with the proposal for the setValue function was made so that different changes could be applied for each iteration of the nested experiment. This basically allows us to perform loop operations (such as in 'for' or 'while' loops). I'm perfectly fine with determining the target of the setValue by an XPath expression, I was just worried that really for many cases we won't have one, such as for time in the case of SBML models, that is why I think it is fine to extend it by additional keywords. So with the nested task + setValue + oneStep + steadyState the aim was to broaden the range of Simulation Experiments that can be encoded with SED-ML. This already allows for any time course simulation, (1-D, 2-D..., N-D) (steady state) parameter scans. And any kinds of pulse experiments. And that without having to define a new simulation class each time. But we don't have to stop here ... we could have a more general function like the one you are suggesting as subclass for the setValue one. I'm just not sure how you would parameterize it. ... The setValue class would take the value of the current range and through that either apply or calculate a change for a value. I'm not sure how you would parameterize your example of removing reactions ... If I were to remove a reaction I would probably do that as before by creating a changed model with the reaction removed, and then apply the nested simulation to it. But maybe I'm misunderstanding your intentions cheers Frank On Mar 30, 2010, at 7:32 AM, Richard Adams wrote: > > Frank, > I read your proposal on your blog - with the 'setValue' function, > are you thinking that is a way of manipulating the model without > constraining it to be XML based? So long as a parameter /variable is > identifiable, tools capable of accepting a model in a particular > format would still be able to manipulate it. > > I guess this would preclude sweeping structural changes applied to an > XML model that can be done with Xpath (removing a reaction, for > example) but is the increase in generality for simple cases of value > manipulation worth considering? > > Best wishes > > Richard > > > > > >> Hello Andrew: >> >>> >>> A few comments. I think that dealing with 'time' is probably one of the >>> biggest weaknesses in this approach. You wrote: >>> "We could make it convention, that if this is not defined, then the >>> models time parameter is changed". >>> Firstly, as soon as we talk about time, we lose generality; I suggest >>> 'independent variable of integration' or a similar term. I'll refer to >>> it as 'IVOI' here. >>> >> >> Given the frequent use of integration over time, I think we can >> justify having this class. But I'm open to introduce your IVOI as a >> more general case. Though I'm afraid many tools will not be able to >> handle IVOI. >> >>> Secondly, modern DAE / IDA solvers take adaptive steps in their IVOI, >>> rather than fixed steps. Your proposal seems to not allow adaptive >>> step-sizes - rather, it forces the user to specify the step size on >>> 'OneStep'. >>> >> >> Definitely, what the oneStep is meant to describe is how far you >> would like to simulate until your next output point. How many steps >> the integrator internally takes would be independent of this. >> >>> => Parameters controlling the internal stepping. For example, allowing >>> for an optional maximum step size to control errors and ensure that the >>> solver finds features like stimulation pulses. >> >> Again, the one step approach only tells you when you want your next >> output point, this can be controlled through the range element on >> the nested simulation experiment. >> >>> => Parameters controlling which data is reported. Some simulations will >>> want to report every internal step, while in others, reporting this data >>> will produce more data than is required. >> >> This will be defined through the data generators that are defined, >> just as in the current approach. >> >>> The above is implemented in CellML Simulation Metadata and the CellML >>> API and OpenCell extensions to it (this metadata focuses entirely on >>> 'time' course experiments at present, but does that one task better than >>> anything proposed for SEDML to date). >>> >> >> Great! ... so which tools can i download to experiment with it? it >> would be good to test exchange of simulation experiments that way. >> >> best >> Frank >> >>> Best wishes, >>> Andrew >>> >>>> >>>> Bergmann, Frank. A Simple Nested Simulation for SED-ML. Available from >>>> Nature Precedings <http://dx.doi.org/10.1038/npre.2010.4257.1> (2010) >>>> >>>> >>>> Let me know what you think, >>>> Best >>>> Frank >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> 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 >>>> _______________________________________________ >>>> SED-ML-discuss mailing list >>>> SED...@li... >>>> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss >>> >>> >>> ------------------------------------------------------------------------------ >>> 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 >>> _______________________________________________ >>> SED-ML-discuss mailing list >>> SED...@li... >>> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss >> >> >> ------------------------------------------------------------------------------ >> 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 >> _______________________________________________ >> SED-ML-discuss mailing list >> SED...@li... >> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss >> >> > > > > -- > Dr Richard Adams > Software Development Team Leader, > Centre For Systems Biology Edinburgh > University of Edinburgh > Tel: 0131 650 8285 > email : ric...@ed... > > -- > The University of Edinburgh is a charitable body, registered in > Scotland, with registration number SC005336. > > > > ------------------------------------------------------------------------------ > 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 > _______________________________________________ > SED-ML-discuss mailing list > SED...@li... > https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss |
|
From: Richard A. <ra...@st...> - 2010-04-02 21:43:27
|
Maybe to explain better - I was recently at a talk from our Biopepa (www.biopepa.org) colleagues who have recently implemented various sorts of 'experiment' functionality to alter models in various ways and compare the results, but use a non-XML based model representation. So I was thinking that setting values based on an 'identifiable element' rather than XPath would extend the range of models whose experiments could be described in SED-ML to include all models that have identifiers (although at the expense of the complete flexibility Xpath gives you to alter a model in any way) Richard > Hello All, > > sorry I have been away for the last couple of days. > > the motivation with the proposal for the setValue function was made > so that different changes could be applied for each iteration of the > nested experiment. This basically allows us to perform loop > operations (such as in 'for' or 'while' loops). I'm perfectly fine > with determining the target of the setValue by an XPath expression, > I was just worried that really for many cases we won't have one, > such as for time in the case of SBML models, that is why I think it > is fine to extend it by additional keywords. > > So with the nested task + setValue + oneStep + steadyState the aim > was to broaden the range of Simulation Experiments that can be > encoded with SED-ML. This already allows for any time course > simulation, (1-D, 2-D..., N-D) (steady state) parameter scans. And > any kinds of pulse experiments. And that without having to define a > new simulation class each time. > > But we don't have to stop here ... we could have a more general > function like the one you are suggesting as subclass for the > setValue one. I'm just not sure how you would parameterize it. ... > The setValue class would take the value of the current range and > through that either apply or calculate a change for a value. I'm not > sure how you would parameterize your example of removing reactions > ... If I were to remove a reaction I would probably do that as > before by creating a changed model with the reaction removed, and > then apply the nested simulation to it. > > But maybe I'm misunderstanding your intentions > > cheers > Frank > > > On Mar 30, 2010, at 7:32 AM, Richard Adams wrote: > >> >> Frank, >> I read your proposal on your blog - with the 'setValue' function, >> are you thinking that is a way of manipulating the model without >> constraining it to be XML based? So long as a parameter /variable is >> identifiable, tools capable of accepting a model in a particular >> format would still be able to manipulate it. >> >> I guess this would preclude sweeping structural changes applied to an >> XML model that can be done with Xpath (removing a reaction, for >> example) but is the increase in generality for simple cases of value >> manipulation worth considering? >> >> Best wishes >> >> Richard >> >> >> >> >> >>> Hello Andrew: >>> >>>> >>>> A few comments. I think that dealing with 'time' is probably one of the >>>> biggest weaknesses in this approach. You wrote: >>>> "We could make it convention, that if this is not defined, then the >>>> models time parameter is changed". >>>> Firstly, as soon as we talk about time, we lose generality; I suggest >>>> 'independent variable of integration' or a similar term. I'll refer to >>>> it as 'IVOI' here. >>>> >>> >>> Given the frequent use of integration over time, I think we can >>> justify having this class. But I'm open to introduce your IVOI as a >>> more general case. Though I'm afraid many tools will not be able to >>> handle IVOI. >>> >>>> Secondly, modern DAE / IDA solvers take adaptive steps in their IVOI, >>>> rather than fixed steps. Your proposal seems to not allow adaptive >>>> step-sizes - rather, it forces the user to specify the step size on >>>> 'OneStep'. >>>> >>> >>> Definitely, what the oneStep is meant to describe is how far you >>> would like to simulate until your next output point. How many steps >>> the integrator internally takes would be independent of this. >>> >>>> => Parameters controlling the internal stepping. For example, allowing >>>> for an optional maximum step size to control errors and ensure that the >>>> solver finds features like stimulation pulses. >>> >>> Again, the one step approach only tells you when you want your next >>> output point, this can be controlled through the range element on >>> the nested simulation experiment. >>> >>>> => Parameters controlling which data is reported. Some simulations will >>>> want to report every internal step, while in others, reporting this data >>>> will produce more data than is required. >>> >>> This will be defined through the data generators that are defined, >>> just as in the current approach. >>> >>>> The above is implemented in CellML Simulation Metadata and the CellML >>>> API and OpenCell extensions to it (this metadata focuses entirely on >>>> 'time' course experiments at present, but does that one task better than >>>> anything proposed for SEDML to date). >>>> >>> >>> Great! ... so which tools can i download to experiment with it? it >>> would be good to test exchange of simulation experiments that way. >>> >>> best >>> Frank >>> >>>> Best wishes, >>>> Andrew >>>> >>>>> >>>>> Bergmann, Frank. A Simple Nested Simulation for SED-ML. Available from >>>>> Nature Precedings <http://dx.doi.org/10.1038/npre.2010.4257.1> (2010) >>>>> >>>>> >>>>> Let me know what you think, >>>>> Best >>>>> Frank >>>>> >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> 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 >>>>> _______________________________________________ >>>>> SED-ML-discuss mailing list >>>>> SED...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> 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 >>>> _______________________________________________ >>>> SED-ML-discuss mailing list >>>> SED...@li... >>>> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss >>> >>> >>> ------------------------------------------------------------------------------ >>> 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 >>> _______________________________________________ >>> SED-ML-discuss mailing list >>> SED...@li... >>> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss >>> >>> >> >> >> >> -- >> Dr Richard Adams >> Software Development Team Leader, >> Centre For Systems Biology Edinburgh >> University of Edinburgh >> Tel: 0131 650 8285 >> email : ric...@ed... >> >> -- >> The University of Edinburgh is a charitable body, registered in >> Scotland, with registration number SC005336. >> >> >> >> ------------------------------------------------------------------------------ >> 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 >> _______________________________________________ >> SED-ML-discuss mailing list >> SED...@li... >> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss > > > ------------------------------------------------------------------------------ > 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 > _______________________________________________ > SED-ML-discuss mailing list > SED...@li... > https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss > > -- Dr Richard Adams Software Development Team Leader, Centre For Systems Biology Edinburgh University of Edinburgh Tel: 0131 650 8285 email : ric...@ed... -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X