sed-ml-discuss — Migrating to google groups: https://groups.google.com/d/forum/sed-ml-discuss

Re: [SED-ML-discuss] How to resolve models

[Nicolas Le n. <le...@eb...>]

Frank Bergmann wrote:

> But we are not forcing users at all. The users are free to choose the format
> that they want. They can go for the plain SED-ML description ... and
> manually manage all their models and other references ... or they can go for
> the archive and be ready to exchange their information. All we ensure by
> describing the archive format in the specification is that those archives
> will be interoperable. 

Fine, but I still do not understand why we need to specify anything. If you 
provide an archive that contains the SED-ML description and the models 
needed, you can call the models in the SED-ML file using the URIs 
"model1.xml", "model2.xml" etc.

>> We do not know what the future will look like, and what kind of
> standardised
>> data sources we will have, do we? So, why not keep it flexible?
>>
> 
> Please let me know how the archive format is not flexible? I don't see any
> limitations imposed with an archive format. 

Exactly. Cf. above. File addresses on a file system are valid URIs. 
Therefore an archive, which is just a portion of a filesystem can be 
described using URIs.

I am sure I am missing something here.


-- 
Nicolas LE NOVERE, Computational Neurobiology, EMBL-EBI, Wellcome-Trust
Genome Campus, Hinxton CB101SD UK, Mob:+447833147074, Tel:+441223494521
Fax:468,Skype:n.lenovere,AIM:nlenovere,MSN:nle...@ho...(NOT email)
http://www.ebi.ac.uk/~lenov/, http://www.ebi.ac.uk/compneur/, @lenovere

Re: [SED-ML-discuss] Proposing a Nested Simulation Experiment

[Frank B. <fbergman@u.washington.edu>]

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&#174; Parallel Studio Eval Try the new
> > software tools for yourself. Speed compiling, find bugs proactively,
> > and fine-tune applications for parallel performance.
> > See why Intel Parallel Studio got high marks during beta.
> > http://p.sf.net/sfu/intel-sw-dev
> > _______________________________________________
> > SED-ML-discuss mailing list
> > SED...@li...
> > https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss
> >
> 
> 
>
----------------------------------------------------------------------------
--
> Download Intel&#174; Parallel Studio Eval Try the new software tools for
> yourself. Speed compiling, find bugs proactively, and fine-tune
applications
> for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> SED-ML-discuss mailing list
> SED...@li...
> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss

Re: [SED-ML-discuss] How to resolve models

[Dagmar W. <dag...@un...>]

Hej Frank,

OK, then it was probably just me to misunderstand the discussion,
among several options to also advocate for a standardised archive,
that is fine with me as well (I thought from the discussions that was not what was argued about,
sorry),

Dagmar


________________________________________
From: Frank Bergmann [fbergman@u.washington.edu]
Sent: 08 March 2010 18:20
To: sed...@li...
Subject: Re: [SED-ML-discuss] How to resolve models

Hello ...

> My personal opinion is that we should not /force/ users (spec-wise) to
create
> a sed-ml.archive whenever they want to exchange a simulation experiment.

But we are not forcing users at all. The users are free to choose the format
that they want. They can go for the plain SED-ML description ... and
manually manage all their models and other references ... or they can go for
the archive and be ready to exchange their information. All we ensure by
describing the archive format in the specification is that those archives
will be interoperable.

> But that we rather should let SED-ML be independent, offer different ways
> of building a simulation description. We could well /advise/ users to use
the
> proposed archive format, if multiple files are needed for the experiment.
>

Don't you think in order to make such an advise, you would have to refer to
the specification of the archive format. So in order to do that it needs to
be described in the spec, which is all I was arguing for.

> We do not know what the future will look like, and what kind of
standardised
> data sources we will have, do we? So, why not keep it flexible?
>

Please let me know how the archive format is not flexible? I don't see any
limitations imposed with an archive format.

> And I agree completely with what Nicolas said: The missing
> versioning/change track for existing models is not the problem of SED-ML.
So
> for me "changing files" is no argument that would completely forbid to
have
> SED-ML files with links to standardised model URNs.
>

What about wanting to open a simulation experiment description, while
without internet connection? What about being able open it instantly, rather
than resolving the model first and downloading it later? Even if you argue
for big models, that are referred to by URN, I at least much rather have
that 20+MB model included in an archive format, rather than having to
download it *each time* I execute the SED-ML experiment from the web.

Cheers
Frank

> Dagmar
>
>
> Richard Adams wrote:
> > OK, but the existence of   large datasets   doesn't negate the utility
> > of the possibility of including small, processed datasets in a SED-ML
> > archive.
> >
> >
> >
> >> Richard Adams wrote:
> >>
> >>
> >>>   If the idea is to access datasets as well in future, then that
> >>> would be even more of a reason to be able to bundle files together,
> >>> as there are ( afaik )no nice, official, communal dataset
> >>> repositories as there are for SBML and CellML models.
> >>>
> >> There are, albeit often unprocessed. Think about gene expression
> >> timeseries. And you do not want to attach the result of an Illumina
> >> run to a SED-ML file.
> >>
> >>
> >> --
> >> Nicolas LE NOVERE, Computational Neurobiology, EMBL-EBI,
> >> Wellcome-Trust Genome Campus, Hinxton CB101SD UK,
> Mob:+447833147074,
> >> Tel:+441223494521
> >>
> Fax:468,Skype:n.lenovere,AIM:nlenovere,MSN:nle...@ho...(NO
> T
> >> email) http://www.ebi.ac.uk/~lenov/, http://www.ebi.ac.uk/compneur/,
> >> @lenovere
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> --------- 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

Re: [SED-ML-discuss] How to resolve models

[Frank B. <fbergman@u.washington.edu>]

Hello ... 

> My personal opinion is that we should not /force/ users (spec-wise) to
create
> a sed-ml.archive whenever they want to exchange a simulation experiment.

But we are not forcing users at all. The users are free to choose the format
that they want. They can go for the plain SED-ML description ... and
manually manage all their models and other references ... or they can go for
the archive and be ready to exchange their information. All we ensure by
describing the archive format in the specification is that those archives
will be interoperable. 

> But that we rather should let SED-ML be independent, offer different ways
> of building a simulation description. We could well /advise/ users to use
the
> proposed archive format, if multiple files are needed for the experiment.
> 

Don't you think in order to make such an advise, you would have to refer to
the specification of the archive format. So in order to do that it needs to
be described in the spec, which is all I was arguing for. 

> We do not know what the future will look like, and what kind of
standardised
> data sources we will have, do we? So, why not keep it flexible?
> 

Please let me know how the archive format is not flexible? I don't see any
limitations imposed with an archive format. 

> And I agree completely with what Nicolas said: The missing
> versioning/change track for existing models is not the problem of SED-ML.
So
> for me "changing files" is no argument that would completely forbid to
have
> SED-ML files with links to standardised model URNs.
> 

What about wanting to open a simulation experiment description, while
without internet connection? What about being able open it instantly, rather
than resolving the model first and downloading it later? Even if you argue
for big models, that are referred to by URN, I at least much rather have
that 20+MB model included in an archive format, rather than having to
download it *each time* I execute the SED-ML experiment from the web. 

Cheers
Frank

> Dagmar
> 
> 
> Richard Adams wrote:
> > OK, but the existence of   large datasets   doesn't negate the utility
> > of the possibility of including small, processed datasets in a SED-ML
> > archive.
> >
> >
> >
> >> Richard Adams wrote:
> >>
> >>
> >>>   If the idea is to access datasets as well in future, then that
> >>> would be even more of a reason to be able to bundle files together,
> >>> as there are ( afaik )no nice, official, communal dataset
> >>> repositories as there are for SBML and CellML models.
> >>>
> >> There are, albeit often unprocessed. Think about gene expression
> >> timeseries. And you do not want to attach the result of an Illumina
> >> run to a SED-ML file.
> >>
> >>
> >> --
> >> Nicolas LE NOVERE, Computational Neurobiology, EMBL-EBI,
> >> Wellcome-Trust Genome Campus, Hinxton CB101SD UK,
> Mob:+447833147074,
> >> Tel:+441223494521
> >>
> Fax:468,Skype:n.lenovere,AIM:nlenovere,MSN:nle...@ho...(NO
> T
> >> email) http://www.ebi.ac.uk/~lenov/, http://www.ebi.ac.uk/compneur/,
> >> @lenovere
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> --------- 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

Re: [SED-ML-discuss] Proposing a Nested Simulation Experiment

[Dagmar W. <dag...@un...>]

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&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> SED-ML-discuss mailing list
> SED...@li...
> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss
>   

Re: [SED-ML-discuss] How to resolve models

[Dagmar W. <dag...@un...>]

Hej,

I think there are two things here: One is what we demand in the SED-ML 
spec. Another thing is how we would like to advise people to use SED-ML.

My personal opinion is that we should not /force/ users (spec-wise) to 
create a sed-ml.archive whenever they want to exchange a simulation 
experiment. But that we rather should let SED-ML be independent, offer 
different ways of building a simulation description. We could well 
/advise/ users to use the proposed archive format, if multiple files are 
needed for the experiment.

We do not know what the future will look like, and what kind of 
standardised data sources we will have, do we? So, why not keep it 
flexible?

And I agree completely with what Nicolas said: The missing 
versioning/change track for existing models is not the problem of 
SED-ML. So for me "changing files" is no argument that would completely 
forbid to have SED-ML files with links to standardised model URNs.

Dagmar


Richard Adams wrote:
> OK, but the existence of   large datasets   doesn't negate the utility  
> of the possibility of including small, processed datasets in a SED-ML  
> archive.
>
>
>   
>> Richard Adams wrote:
>>
>>     
>>>   If the idea is to access datasets as well in future, then that would
>>> be even more of a reason to be able to bundle files together, as there
>>> are ( afaik )no nice, official, communal dataset repositories as there
>>> are for SBML and CellML models.
>>>       
>> There are, albeit often unprocessed. Think about gene expression
>> timeseries. And you do not want to attach the result of an Illumina run to
>> a SED-ML file.
>>
>>
>> --
>> Nicolas LE NOVERE, Computational Neurobiology, EMBL-EBI, Wellcome-Trust
>> Genome Campus, Hinxton CB101SD UK, Mob:+447833147074, Tel:+441223494521
>> Fax:468,Skype:n.lenovere,AIM:nlenovere,MSN:nle...@ho...(NOT email)
>> http://www.ebi.ac.uk/~lenov/, http://www.ebi.ac.uk/compneur/, @lenovere
>>
>>
>>
>> ------------------------------------------------------------------------------
>> 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
>>
>>
>>     
>
>
>
>   

Re: [SED-ML-discuss] How to resolve models

[Richard A. <ra...@st...>]

OK, but the existence of   large datasets   doesn't negate the utility  
of the possibility of including small, processed datasets in a SED-ML  
archive.


> Richard Adams wrote:
>
>>   If the idea is to access datasets as well in future, then that would
>> be even more of a reason to be able to bundle files together, as there
>> are ( afaik )no nice, official, communal dataset repositories as there
>> are for SBML and CellML models.
>
> There are, albeit often unprocessed. Think about gene expression
> timeseries. And you do not want to attach the result of an Illumina run to
> a SED-ML file.
>
>
> --
> Nicolas LE NOVERE, Computational Neurobiology, EMBL-EBI, Wellcome-Trust
> Genome Campus, Hinxton CB101SD UK, Mob:+447833147074, Tel:+441223494521
> Fax:468,Skype:n.lenovere,AIM:nlenovere,MSN:nle...@ho...(NOT email)
> http://www.ebi.ac.uk/~lenov/, http://www.ebi.ac.uk/compneur/, @lenovere
>
>
>
> ------------------------------------------------------------------------------
> 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.

Re: [SED-ML-discuss] SED-ML roadmap

[Frank B. <fbergman@u.washington.edu>]

> I don't have a particular road-map for SED-ML, except that the first
version
> was meant to encode the simple time-course. And in several of the past
> meetings, there was a relative consensus that the next important step was
> to tackle procedures such as parameter scans. A roadmap is indeed a good
> idea. We should put something like that on the website. Let's tentatively
> start:
> 
> Level 1: Single simulation procedures
>      Version 1: Single timecourse
>      Version 2: add ? [steady-state ...]
> 

What about something like the nested simulation approach I hinted at before?
It would be an easy extension, and would allow for many different kinds of
simulation experiments. I would like to be able to express different
simulation experiments, without having to redefine a new simulation class
each time. 


> Level 2: Multiple independent simulations
>      Version 1: Parameter scan
>      Version 2: add ?
> 
> Level 3: Multiple linked simulations
>     By that I mean simulation systems where a simulation depends, at run-
> time, on another simulation running concurrently.
> 

That could also be achieved with nesting the nested simulation experiments!
Well or at least partly. Personally, I think adding primitive operations is
the way to go forward. 

> The Version would supersede previous versions. The Levels would develop
> independently. We coul  But a Level N would be built on the Level N-1. The
> particular Version of Level N-1 to be used in a Version of Level N would
be
> specified in its specification.
> 

Maybe we can also get the organization of SED-ML sorted out soon. I'm sure
having editors for the spec and an better way to submit proposals would help
this format to develop faster.

Cheers
Frank

Re: [SED-ML-discuss] Subset of MathML to use in SED-ML

[Frank B. <fbergman@u.washington.edu>]

 
> > - In SBML we only deal with singular values, however in order for us
> > to calculate aggregates such as the minimum or maximum of a value we
> > need access to more. The specification needs to tell us how to do it
> > ... it could be as simple as referring to the id of a datagenerator
> > and saying this means all values currently computed of the
> > datagenerator. Alternatively, it could also be meant to be calculated
> > only once at the end of all scheduled simulations.
> 
> That is an important point, that we discuss in Bangalore when talking
about
> gluing different representations for multi-scale models (and we talked
about
> SED-ML allowing an integration at the simulation level). One of the
original
> wishes for SED-ML was the ability to re-use simulation descriptions with
> different models. The variables are determined by the model. I would be in
> favor of a variable overload. A symbol can represent a scalar, an array (a
set)
> or a distribution (a function). It depends on the model used by the
simulation
> description.
> 

I'd like to hear a bit more as to what exactly was discussed about this. The
variable overloading sounds a bit scary at first. For me all model variables
represent scalar values.  That's why I suggested to use the data-generators
as the place holders for the only variables to be involved in aggregate
expressions, (like min, max, sum ... ). Implementers of SED-ML will have to
write additional logic for the calculation of data-generators anyway and
thus it would not be a burden on them and we could expect a swift adoption. 

But I'm definitely eager to hear more ... 

Frank

> 
> --
> Nicolas LE NOVERE, Computational Neurobiology, EMBL-EBI, Wellcome-Trust
> Genome Campus, Hinxton CB101SD UK, Mob:+447833147074,
> Tel:+441223494521
> Fax:468,Skype:n.lenovere,AIM:nlenovere,MSN:nle...@ho...(NO
> T email) http://www.ebi.ac.uk/~lenov/, http://www.ebi.ac.uk/compneur/,
> @lenovere
> 
> 
> 
>
----------------------------------------------------------------------------
--
> 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

Re: [SED-ML-discuss] How to resolve models

[Nicolas Le n. <le...@eb...>]

Richard Adams wrote:

>   If the idea is to access datasets as well in future, then that would  
> be even more of a reason to be able to bundle files together, as there  
> are ( afaik )no nice, official, communal dataset repositories as there  
> are for SBML and CellML models.

There are, albeit often unprocessed. Think about gene expression 
timeseries. And you do not want to attach the result of an Illumina run to 
a SED-ML file.


-- 
Nicolas LE NOVERE, Computational Neurobiology, EMBL-EBI, Wellcome-Trust
Genome Campus, Hinxton CB101SD UK, Mob:+447833147074, Tel:+441223494521
Fax:468,Skype:n.lenovere,AIM:nlenovere,MSN:nle...@ho...(NOT email)
http://www.ebi.ac.uk/~lenov/, http://www.ebi.ac.uk/compneur/, @lenovere

Re: [SED-ML-discuss] How to resolve models

[Richard A. <ra...@st...>]

 From our point of view, the 'archive' has the advantage of all  
resources needed to run the simulation being together. Our users would  
like to exchange simulations are in some cases working on new models -  
so passing them round as files is what they expect to be able to do.   
As Frank says a library can provide support for an archive 'on top' of  
basic SED-ML support - a developer building a SED-Ml compliant tool  
can decide whether to use this or not.
  In our experience we've found dealing with multiple connected files  
really troublesome - our first stab at an experimental data format was  
to have separate 'header' files describing the data, with the idea  
that header files could be reused. This has turned out to be a real  
headache, writing to code to keep track of these pairs of files - a  
single file or archive file would actually be much easier to handle!
  If the idea is to access datasets as well in future, then that would  
be even more of a reason to be able to bundle files together, as there  
are ( afaik )no nice, official, communal dataset repositories as there  
are for SBML and CellML models.

Richard

>
> On Mar 7, 2010, at 10:48 AM, Nicolas Le novère wrote:
>
>> Surely you must be able to support all those. The only exception is indeed
>> the URN. But you would only have to support MIRIAM's ones. And MIRIAM
>> resolvers would turn them into URLs.
>
> great ... that was all i wanted to know ... until now it was not   
> clear that only MIRIAM URNs were to be used.
>
>>
>>
>> But all that is fine for small simulations. When the models are very large,
>> and in the future makes use of experimental data (cf the other thread), it
>> is not practical. Furthermore, you may want to re-use a SED-ML description
>> with different models and/or measurements.
>
> The archive format is meant for the exchange only ... it does not   
> add any magic to it. When libraries would like to re-use the SED-ML   
> description of one archive they can easily recover it. The space   
> needed is also not an issue IMHO.
>
>>
>>> And I really don't see your problem in this. Given that there seem  
>>>  to be two
>>> implementations so far of this Richards and mine, and both accept this
>>> archive format, then where is the harm in having it? It is   
>>> extremely useful,
>>> will solve versioning issues and communication issues with users. And it is
>>> entirely optional, the user chooses whether to save an archive or not.
>>
>> As far as it is optional, this is fine with me. But I do not think the
>> usage of such an archive should not be required for SED-ML compliance.
>>
>
> Well, my hope was for an easy exchange of the files. As I will not   
> be dealing with remote files except for rare cases I needed the   
> archive format for exchange between machines. I think it is a vital   
> issue and it should be interoperable. If that is not written in the   
> specification, then this is a missed chance. Tool 1, will implement   
> it in one way, and tool 2 in another. I do not see why we have to go  
>  that way when we have the chance, right now to specify the way to go.
>
> Frank
>
>
>
>



-- 
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.

Re: [SED-ML-discuss] How to resolve models

[David N. <dav...@gm...>]

just as another option, as you may know the CellML model repository is
based on mercurial and we are using embedded mercurial repositories to
provide a way to manage CellML 1.1 model hierarchies that takes care
of versioning, exchange, archiving, etc. We are finding that this is a
great way to allow collections of CellML models to be pulled together
as well letting model authors use relative links between models that
are then managed via the model repository/mercurial.

For example, a SED-ML document to be used with multiple models would
sit in its own mercurial repository. You would then embed each of the
model repositories into that repository to end up with a single
"directory" structure that contains everything you need to define the
simulation experiment. In the top level SED-ML document's repository
you control which version (in a mercurial sense) of each CellML model
you want to embed, which can easily be changed if and as required.

On Mon, Mar 8, 2010 at 8:18 AM, Frank Bergmann
<fbergman@u.washington.edu> wrote:
> Well, my hope was for an easy exchange of the files. As I will not be
> dealing with remote files except for rare cases I needed the archive format
> for exchange between machines. I think it is a vital issue and it should be
> interoperable. If that is not written in the specification, then this is a
> missed chance. Tool 1, will implement it in one way, and tool 2 in another.
> I do not see why we have to go that way when we have the chance, right now
> to specify the way to go.

The archive format is just one way to achieve this. Personally, I
don't think that is something that belongs in the specification for
SED-ML. But if it is something that people want to exchange it should
be specified somewhere I guess. Standardizing on the use of
URL/URI/URN's to link to resources seems like enough for the SED-ML
specification without needing to specify how individual tools or users
manage these resources.


Cheers,
Andre.

Re: [SED-ML-discuss] How to resolve models

[Frank B. <fbergman@u.washington.edu>]

On Mar 7, 2010, at 10:48 AM, Nicolas Le novère wrote:

> Surely you must be able to support all those. The only exception is indeed 
> the URN. But you would only have to support MIRIAM's ones. And MIRIAM 
> resolvers would turn them into URLs.

great ... that was all i wanted to know ... until now it was not clear that only MIRIAM URNs were to be used. 

> 
> 
> But all that is fine for small simulations. When the models are very large, 
> and in the future makes use of experimental data (cf the other thread), it 
> is not practical. Furthermore, you may want to re-use a SED-ML description 
> with different models and/or measurements.

The archive format is meant for the exchange only ... it does not add any magic to it. When libraries would like to re-use the SED-ML description of one archive they can easily recover it. The space needed is also not an issue IMHO. 

> 
>> And I really don't see your problem in this. Given that there seem to be two
>> implementations so far of this Richards and mine, and both accept this
>> archive format, then where is the harm in having it? It is extremely useful,
>> will solve versioning issues and communication issues with users. And it is
>> entirely optional, the user chooses whether to save an archive or not. 
> 
> As far as it is optional, this is fine with me. But I do not think the 
> usage of such an archive should not be required for SED-ML compliance.
> 

Well, my hope was for an easy exchange of the files. As I will not be dealing with remote files except for rare cases I needed the archive format for exchange between machines. I think it is a vital issue and it should be interoperable. If that is not written in the specification, then this is a missed chance. Tool 1, will implement it in one way, and tool 2 in another. I do not see why we have to go that way when we have the chance, right now to specify the way to go. 

Frank

[SED-ML-discuss] How to resolve models

[Nicolas Le n. <le...@eb...>]

[I forward this discussion on the list with Frank's consent]

 >> Frank Bergmann wrote:
>>> - The specification should define how to resolve models, and
>>> referenced data. Just saying that models can be taken from the
>>> BioModels database or cellml repository is not enough. There has to be
>>> a precise way of resolving the model! Examples should be given for
>> resolving:
>>>   - local files
>>>   - web resources
>>>   - the databases you mentioned

 > Nicolas Le Novere wrote:
>> Which can be summarised as "a valid URI". We should nevertheless provide
>> examples. I thought we started to draft those in Rostock last month.

Frank Bergmann wrote:
> I don't think that is sufficient ... for URLs I would agree, but not URNs,
> if I don't know beforehand what to expect I will not be able to support it
> in software.  

But controlled URIs are as robust as URLs. From Wikipedia:
     * http://example.org/absolute/URI/with/absolute/path/to/resource.txt
     * ftp://example.org/resource.txt
     * urn:issn:1535-3613
     * ../../../resource.txt
     * ./resource.txt
     * resource.txt

Surely you must be able to support all those. The only exception is indeed 
the URN. But you would only have to support MIRIAM's ones. And MIRIAM 
resolvers would turn them into URLs.

>>> - describe the proposed archive format, that lets models be encoded
>>> along with the SED-ML file, this is the only truly portable way of
>>> exchanging SED-ML files!.

>> Not if we use correct URIs. If a SED-ML model mentions the model
>> "foobar.xml", it means the file "foobar.xml" in the same directory than
> the
>> file containing the SED-ML description.
>> I see your archive as one possibility to implement SED-ML. And it may be
> that
>> everyone starts using it. But let's not commit to such a scheme straight
> from
>> the beginning.

> I disagree, if the models (and referenced data) are not included with the
> simulation description, but rather picked up from locations on ones users
> hard drive, exchange of them will frequently fail. Sending multiple files is
> far inferior and error prone! Just think about me uploading my description
> to a website ... to be carried out, after this I don't want to manually hunt
> down all the individual models and upload them too. 

But all that is fine for small simulations. When the models are very large, 
and in the future makes use of experimental data (cf the other thread), it 
is not practical. Furthermore, you may want to re-use a SED-ML description 
with different models and/or measurements.

> Not to speak of problems
> with multiple model variants and versions. (Remember that suddenly for the
> SED-ML poster we could no longer reproduce the simulation results from
> before, because the underlying BioModel had changed fundamentally?)

IMHO, that was a problem of BioModels Database, not a problem of SED-ML. If 
you type http://foo.bar in firefox and receive a 404, is-it a bug of the 
http protocol? We have indeed to address the versioning of models more 
seriously. And we are working on it.

> And I really don't see your problem in this. Given that there seem to be two
> implementations so far of this Richards and mine, and both accept this
> archive format, then where is the harm in having it? It is extremely useful,
> will solve versioning issues and communication issues with users. And it is
> entirely optional, the user chooses whether to save an archive or not. 

As far as it is optional, this is fine with me. But I do not think the 
usage of such an archive should not be required for SED-ML compliance.

-- 
Nicolas LE NOVERE, Computational Neurobiology, EMBL-EBI, Wellcome-Trust
Genome Campus, Hinxton CB101SD UK, Mob:+447833147074, Tel:+441223494521
Fax:468,Skype:n.lenovere,AIM:nlenovere,MSN:nle...@ho...(NOT email)
http://www.ebi.ac.uk/~lenov/, http://www.ebi.ac.uk/compneur/, @lenovere

[SED-ML-discuss] SED-ML roadmap

[Nicolas Le n. <le...@eb...>]

[I forward this discussion on the list with Frank's consent]

 >> Frank Bergmann wrote:
>>> - of special importance for many will be the interaction with external
>>> data sets. The SED-ML specification needs to specify how this
>>> interaction takes place. It should at least say the formats expected,
>>> probably SBRML and CSV for now. Right now the schema depicted in Fig
>>> 28, only lists measurement data linked to the Output class. This would
>>> be wasted potential. Think of parameter fitting experiments ... or
>>> think of time course simulation experiment defined over the same time
>>> range as given in the referenced data set. That is why the list of
>>> MeasurementData was described at the SED-ML level from the beginning.

 > Nicolas Le Novere wrote:
>> I entirely agree that the interaction with measurement data is missing.
>> And
>> that is why I was against it straight for the beginning. But now, 2 years
> after, I
>> even think this is not part of SED-ML at all. The parametrisation of a
> model is
>> not part of the simulation description. In certain case, simulations may
> take
>> part of some parametrisation determination procedures.
>> But describing those in SED-ML is a daunting challenge. In any case, it is
> not
>> part of v1. Again version 1, as agreed from day 1, will describe only the
> single
>> timecourse. Start small, get support, extend. That's the SBML philosophy.
>> And that works. We just have to be sure to have faster iteration than SBML
> :-
>> )
> 
> You've hinted at this many times now, also with your references to SBML L4.
> It would really be great to see your road map. 

I don't have a particular road-map for SED-ML, except that the first 
version was meant to encode the simple time-course. And in several of the 
past meetings, there was a relative consensus that the next important step 
was to tackle procedures such as parameter scans. A roadmap is indeed a 
good idea. We should put something like that on the website. Let's 
tentatively start:

Level 1: Single simulation procedures
     Version 1: Single timecourse
     Version 2: add ? [steady-state ...]

Level 2: Multiple independent simulations
     Version 1: Parameter scan
     Version 2: add ?

Level 3: Multiple linked simulations
    By that I mean simulation systems where a simulation depends, at 
run-time, on another simulation running concurrently.

The Version would supersede previous versions. The Levels would develop 
independently. We coul  But a Level N would be built on the Level N-1. The 
particular Version of Level N-1 to be used in a Version of Level N would be 
specified in its specification.

>>> -  AnySimulation: This type will never be exchangeable ... since the
>>> simulation experiment is not defined, it cannot be exchanged! The
>>> SED-ML standard already allows the specification of ANY, that is,
>>> PROPRIETARY simulation experiments through custom annotations. We
>>> should aim for people to use the standard classes, otherwise this
>>> project is doomed from the start ...
>> I totally agree.


-- 
Nicolas LE NOVERE, Computational Neurobiology, EMBL-EBI, Wellcome-Trust
Genome Campus, Hinxton CB101SD UK, Mob:+447833147074, Tel:+441223494521
Fax:468,Skype:n.lenovere,AIM:nlenovere,MSN:nle...@ho...(NOT email)
http://www.ebi.ac.uk/~lenov/, http://www.ebi.ac.uk/compneur/, @lenovere

[SED-ML-discuss] Subset of MathML to use in SED-ML

[Nicolas Le n. <le...@eb...>]

[I forward this discussion on the list with Frank's consent]

 >> Frank Bergmann wrote:
[Frank speaks of the draft specification of SED-ML Level 1 Version 1]
>>> - it needs to specify precisely what sort of MathML is allowed where.
>>> Especially the aggregation functions you mentioned at the beginning
>>> for the post processing bit with min / max ... so far it is not
>>> mentioned anywhere

 > Nicolas Le Novere wrote:
>> Good comment. That is something to think about. SBML has a restricted set
>> of MathML, and that has bothered me since the beginning. For instance the
>> lack of product, sum, vector and matrix is still a pain in the back and
> make
>> SBML and SBO incompatible without an extra software layer. Can't we say,
> at
>> least in the beginning, that we allow all MathML content? The alternative
> is
>> to choose the SBML subset (as a start). We should move that to the list.
>>
> 
> You definitely want to choose a subset. Otherwise it will take years to
> approach this, as it will take a lot of effort to implement support for the
> whole of MathML. The whole of MathML would allow for the definition of
> matrices, sets and operations on them ... that is not going to help ... not
> to speak of differential operators, integrals and quantifiers (forall,
> exists) ... IMHO we should keep it as close to the SBML mathml, which is
> what people will have implemented, as possible. 

If nobody disagree, we can start this way. And the implementers will tell 
us if something else is needed (I am fairly certain that matrices and sets 
will be needed, but maybe not for Level 1 Version 1).

> But what I'm talking about here is also, how would we use it :
> 
> - everywhere where the SED-ML specification allows for mathml, it should be
> stated what the expression should evaluate to (i.e: for a parameter change,
> it should hopefully evaluate to a double number)

Yes.

> - In SBML we only deal with singular values, however in order for us to
> calculate aggregates such as the minimum or maximum of a value we need
> access to more. The specification needs to tell us how to do it ... it could
> be as simple as referring to the id of a datagenerator and saying this means
> all values currently computed of the datagenerator. Alternatively, it could
> also be meant to be calculated only once at the end of all scheduled
> simulations. 

That is an important point, that we discuss in Bangalore when talking about 
gluing different representations for multi-scale models (and we talked 
about SED-ML allowing an integration at the simulation level). One of the 
original wishes for SED-ML was the ability to re-use simulation 
descriptions with different models. The variables are determined by the 
model. I would be in favor of a variable overload. A symbol can represent a 
scalar, an array (a set) or a distribution (a function). It depends on the 
model used by the simulation description.


-- 
Nicolas LE NOVERE, Computational Neurobiology, EMBL-EBI, Wellcome-Trust
Genome Campus, Hinxton CB101SD UK, Mob:+447833147074, Tel:+441223494521
Fax:468,Skype:n.lenovere,AIM:nlenovere,MSN:nle...@ho...(NOT email)
http://www.ebi.ac.uk/~lenov/, http://www.ebi.ac.uk/compneur/, @lenovere

Re: [SED-ML-discuss] SED-ML support

[Frank B. <fbergman@u.washington.edu>]

>  But perhaps a common set of services could be useful. Although, how
> common is it for a developer to use different language versions of a
> particular library? Would a Java programmer care if the Python API was
> different? But I agree that a set of libraries for each version of SEDML
would
> be necessary.

I agree, a common set of services would be helpful, the basic services my
library provides are: 

- obviously reading / writing SED-ML
- supporting reading / writing the archive format (i.e.: SED-ML + model
files)
- resolving external models (i.e.: from web locations or BioModels so far)
- applying the changes described in SED-ML to a model, and making the
changed model available

However, the libraries need help from a SED-ML specification as well, it
should state explicitly:
- how to resolve URIs to models (including how to deal with local files)
- how precisely the archive format should be constructed. 
- be precise about the mathematical operations allowed
	- including a strategy of how to address implicit model variables: 
		- time

And for a later stage additional implicit values like

		- species' amount / concentration / particle numbers / rate
of change
		- the model's Jacobian
		- eigenvalues of the model's Jacobian
		- (later we probably would also want to address control
coefficients and elasticities for MCA)

Cheers
Frank

Re: [SED-ML-discuss] SED-ML support

[Richard A. <ra...@st...>]

Yes I think that with language style variations  it would be difficult  
if not impossible to get  an absolute  standard API that would be  
intuitive to a programmer in that language. E.g., a Java programmer  
would expect getXXX(),  setXXX() methods, etc and the 'ListOf'  
structures are not intuitive.
  But perhaps a common set of services could be useful. Although, how  
common is it for a developer to use different language versions of a  
particular library? Would a Java programmer care if the Python API was  
different? But I agree that a set of libraries for each version of  
SEDML would be necessary.

  I was thinking the scope of jlibsedml would be just to represent,  
manipulate and persist SEDML, but not actually to run simulations -  
with the idea being a tool would use the library to configure its  
simulator according to the SEDML directives. Also the concept of a  
SED-ML archive file was discussed a while back - e.g., the bundling of  
SED-ML document and model file(s). I imagine it would be helpful for  
libraries in different languages to produce the same archive.

  Regarding the JAXB bindings, the API produced is so clunky I was  
thinking of binning it and starting again with hand-made classes, esp  
with regard to the MathML processing.

  Cheers
     Richard



> [I move this to sed-ml discuss for reasons that I hope are obvious]
>
> Frank Bergmann wrote:
>  > Nicolas Le Novere wrote:
>  >> As you know there is another library developed by Richard, jlibsedml.
>  >> I suspect users will expect the same kinds of services from the two
>  >> libraries. Would-there be possibities for you guys to discuss and
>  >> document an API that would be common, and re-usable by anyone wanting
>  >> to develop support for SED-ML in another language. This API would be
>  >> libsedml, and the other libraries would be instances, like jlibsedml,
>  >> nlibsedml, plibsedml etc. Whether this should be hosted via sed-ml or
>  >> via libsedml on sourceforge, would be left to be discussed by you
>  >> developers.
>  >
>  > This does sound interesting and I'm definitely open for discussions
>  > about a generic API. Though I'm not sure yet how much implementing the
>  > API in one language would help in the implementation for another. Just
>  > take the two examples we have here: In my implementation I took the
>  > object model as guideline in order to implement the library I needed, I
>  > made use of other libraries I wrote before to allow for the mathematical
>  > transformations. The approach for jlibsedml, and please correct me if
>  > I'm wrong here Richard, was to use JAXB, that is code generation out of
>  > a schema. While the two API's will be similar, as the Schema and the
>  > object model hopefully agree with each other, the actual programming
>  > code will be different.
>
> This discussion is probably too technical for me. What I meant was that:
>
> 1) The libraries should be developed in sync, to cover the same versions
>
> 2) A user expects to find the same services offered by the different
> libraries. One way could be to move in the same direction than libSBML and
> JSBML, with the API defined by a list of tests.
>
> --
> Nicolas LE NOVERE, Computational Neurobiology, EMBL-EBI, Wellcome-Trust
> Genome Campus, Hinxton CB101SD UK, Mob:+447833147074, Tel:+441223494521
> Fax:468,Skype:n.lenovere,AIM:nlenovere,MSN:nle...@ho...(NOT email)
> http://www.ebi.ac.uk/~lenov/, http://www.ebi.ac.uk/compneur/, @lenovere
>
>
>
> ------------------------------------------------------------------------------
> 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.

Re: [SED-ML-discuss] Announcing libSedML

[David N. <dav...@gm...>]

thanks, good to know I wasn't running off in the wrong direction!

On Thu, Mar 4, 2010 at 4:11 PM, Frank Bergmann
<fbergman@u.washington.edu> wrote:
> I used .NET of course because the language is still changing. WIth .NET I'm able to change the libraries and test them in projects across operating systems quickly. You are perfectly correct, Mono Embedding would probably be the way to go, I just tried it recently with RoadRunner and found no problems at all:
>
> http://frank-fbergmann.blogspot.com/2010/02/roadrunner-ccli-vs-embedding-mono.html
>
> Cheers
> Frank
>

Re: [SED-ML-discuss] Announcing libSedML

[Frank B. <fbergman@u.washington.edu>]

I used .NET of course because the language is still changing. WIth .NET I'm able to change the libraries and test them in projects across operating systems quickly. You are perfectly correct, Mono Embedding would probably be the way to go, I just tried it recently with RoadRunner and found no problems at all: 

http://frank-fbergmann.blogspot.com/2010/02/roadrunner-ccli-vs-embedding-mono.html

Cheers
Frank


On Mar 3, 2010, at 6:51 PM, David Nickerson wrote:

> Hi Frank,
> 
> This is good news, great work! As someone that knows next to nothing
> about .NET and C#, any suggestions on how I could go about utilizing
> LibSedML in a C++ application? From a quick look around, its looks
> like embedding mono (http://mono-project.com/Embedding_Mono) might be
> the way to go... I'm assuming here that linking against LibSedML might
> be easier than trying to use Richard's Java SED-ML library?
> 
> I ask since the best way to use the CellML API implementation is from
> C++, at least for me :)
> 
> 
> Cheers,
> Andre.
> 
> On Thu, Mar 4, 2010 at 9:48 AM, Frank Bergmann
> <fbergman@u.washington.edu> wrote:
>> Hello all,
>> 
>> As you know I have been working on supporting SED-ML since the beginning. In
>> the meantime three libraries are available:
>> 
>> - LibSedML: a library for reading and writing SED-ML
>> - LibSedMLRunner: a library running SED-ML files (currently using
>> RoadRunner)
>> - LibSedMLScript: a library that turns a human readable script into SED-ML.
>> 
>> More information here:
>> 
>> http://libsedml.sf.net/
>> http://frank-fbergmann.blogspot.com/2010/03/supporting-sed-ml.html
>> 
>> best
>> Frank
>> 
>> 
>> ------------------------------------------------------------------------------
>> Download Intel&#174; Parallel Studio Eval
>> Try the new software tools for yourself. Speed compiling, find bugs
>> proactively, and fine-tune applications for parallel performance.
>> See why Intel Parallel Studio got high marks during beta.
>> http://p.sf.net/sfu/intel-sw-dev
>> _______________________________________________
>> SED-ML-discuss mailing list
>> SED...@li...
>> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss
>> 
> 
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> SED-ML-discuss mailing list
> SED...@li...
> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss

Re: [SED-ML-discuss] Announcing libSedML

[David N. <dav...@gm...>]

Hi Frank,

This is good news, great work! As someone that knows next to nothing
about .NET and C#, any suggestions on how I could go about utilizing
LibSedML in a C++ application? From a quick look around, its looks
like embedding mono (http://mono-project.com/Embedding_Mono) might be
the way to go... I'm assuming here that linking against LibSedML might
be easier than trying to use Richard's Java SED-ML library?

I ask since the best way to use the CellML API implementation is from
C++, at least for me :)


Cheers,
Andre.

On Thu, Mar 4, 2010 at 9:48 AM, Frank Bergmann
<fbergman@u.washington.edu> wrote:
> Hello all,
>
> As you know I have been working on supporting SED-ML since the beginning. In
> the meantime three libraries are available:
>
> - LibSedML: a library for reading and writing SED-ML
> - LibSedMLRunner: a library running SED-ML files (currently using
> RoadRunner)
> - LibSedMLScript: a library that turns a human readable script into SED-ML.
>
> More information here:
>
> http://libsedml.sf.net/
> http://frank-fbergmann.blogspot.com/2010/03/supporting-sed-ml.html
>
> best
> Frank
>
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> SED-ML-discuss mailing list
> SED...@li...
> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss
>

Re: [SED-ML-discuss] Proposing a Nested Simulation Experiment

[Frank B. <fbergman@u.washington.edu>]

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&#174; Parallel Studio Eval
>> Try the new software tools for yourself. Speed compiling, find bugs
>> proactively, and fine-tune applications for parallel performance.
>> See why Intel Parallel Studio got high marks during beta.
>> http://p.sf.net/sfu/intel-sw-dev
>> _______________________________________________
>> SED-ML-discuss mailing list
>> SED...@li...
>> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss
> 
> 
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> SED-ML-discuss mailing list
> SED...@li...
> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss

Re: [SED-ML-discuss] Proposing a Nested Simulation Experiment

[Andrew M. <ak....@au...>]

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&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> SED-ML-discuss mailing list
> SED...@li...
> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss

[SED-ML-discuss] Announcing libSedML

[Frank B. <fbergman@u.washington.edu>]

Hello all, 

As you know I have been working on supporting SED-ML since the beginning. In
the meantime three libraries are available: 

- LibSedML: a library for reading and writing SED-ML
- LibSedMLRunner: a library running SED-ML files (currently using
RoadRunner)
- LibSedMLScript: a library that turns a human readable script into SED-ML. 

More information here: 

http://libsedml.sf.net/
http://frank-fbergmann.blogspot.com/2010/03/supporting-sed-ml.html

best
Frank

[SED-ML-discuss] Proposing a Nested Simulation Experiment

[Frank B. <fbergman@u.washington.edu>]

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