Re: [cellml-discussion] ABI CellML meeting minutes 2009-09-30
Hi Dagmar, Andre, all:
On VCell side, there is nothing new since August, as we have been tied up with
a few major grant submissions (last one, and biggest one, went out the door
yesterday...)
We did complete in early summer the pure Java library to handle SED-ML
elements, as I mentioned in Auckland that we would... The link to the VCell
solver is also done, but has the obvious limitations of SBML/VCML
incompatibilities. (btw, a lot of these should go away soon due to a parallel
development effort)
I'm not sure whether the library has been updated to match the latest changes
in SED-ML over the summer, and whether it was posted to our Wiki or elsewhere.
I am cc'ing Dan, who is the main MIASE-related developer on our team, and
should be able to give more detailed answers.
Ion
From: Dagmar Koehn [dagmar.ko...@uni-rostock.de]
Sent: Monday, October 26, 2009 6:44 AM
To: CellML Discussion List
Cc: Moraru,Ion; Richard Adams
Subject: Re: [cellml-discussion] ABI CellML meeting minutes 2009-09-30
Hej Dandre :-),
some statements inline.
David Nickerson wrote:
Hi Dagmar,
Thanks for your comments! I'll just make a couple of notes inline below...
* Andre said that SED-ML does not yet support everything that we
need to do for simulation and graphing.
I agree that SED-ML still is at quite an early stage and might not cover
everything needed.
However, even if the structure of SED-ML does not offer particular
constructs for some of your needs, you are allowed (by definition of the
SED-ML schema) to attach annotations to *any* SED-ML element. Thus, you
could extend SED-ML towards supporting whatever additional needs you might
have for information to put in the simulation description file.
Do you think that would be sufficient? As Nicolas mentioned, that would
actually be a nice benchmark for us to see in what way SED-ML needs to be
extended (certainly by what you would put in the annotations often).
I agree. The way forward here is to start using SED-ML with CellML
models and see how things work out and what possible extensions are
required, and also whether these can be incorporated through the
existing annotation mechanism. I know that at least myself and maybe
others have volunteered to do this at some point, but I have yet to
sit down and do it :) We are also hoping that a core SED-ML supporting
library or tool might become available that we could work with in
order to implement support for CellML. From the Waiheke meeting, Ion
offered to make the VCell code available but I haven't had a chance to
follow up on this.
I cc:ed Ion as I must confess I didn't follow developments on VCell
neither. Maybe he could state on how things evolved.
Additionally, Richard Adams at Edinburgh University did some work on
Java library development for SED-ML.
It is all at:
http://miase.svn.sourceforge.net/viewvc/miase/sed-ml/jlibsedml/
There also is an online SED-ML file validator at:
http://www.bioinformatics.ed.ac.uk:8080/SBSVisualWebApp/html/sedml/
Richard said, it is all still preliminary, but we were discussing on
continuing the development,
so maybe it would be a good idea to get in contact with him - so as not
to do things twice...
I also cc:ed Richard :-)
* Andrew said that we are still trying to convince the SED-ML group
to separate out graphing and simulation.
I can say that SED-ML is *not* about graphing at all - in the sense that I
understand graphing. SED-ML should provide the description of the data that
is used to create the output, and also how these data relate, e.g. for a 2
dimensional plot you would have to specify what to plot against what (x and
y axes). Let me cite Nicolas again from an earlier mail: E.g. we can create
a report {time, var1, var2}, but some information will only emerge if we
plot var1 versus var2. In some sense the relationship between var1 and
var2 representation is part of the post-processing.
* Andre said that you might want to change some of the graphing
metadata to get different graphs from the same simulation, or vice
versa.
If we are talking about running one simulation and creating a number of
different graphs (say, many 2D plots) from that simulation, this is already
possible in SED-ML right now. All you have to do is to define a number of
(what we call) data generators, referring to the variables/parameters you
want to use for your output. Then you can define as many outputs as you
want, referring to the same or different data generators and to the same of
different simulation setups.
If you look at the example given in the publication of CMSB 2008, on page
9/10 (http://www.springerlink.com/content/n67n137071431xt7/), we defined a
data generator called time and we use it to create 2 different curves from
one single simulation (only the x axis is varying here, using 2 different
models).
If we, however, are talking about producing the same graph one
Re: [cellml-discussion] ABI CellML meeting minutes 2009-09-30
I cc:ed Ion as I must confess I didn't follow developments on VCell neither. Maybe he could state on how things evolved. Additionally, Richard Adams at Edinburgh University did some work on Java library development for SED-ML. It is all at: http://miase.svn.sourceforge.net/viewvc/miase/sed-ml/jlibsedml/ There also is an online SED-ML file validator at: http://www.bioinformatics.ed.ac.uk:8080/SBSVisualWebApp/html/sedml/ Richard said, it is all still preliminary, but we were discussing on continuing the development, so maybe it would be a good idea to get in contact with him - so as not to do things twice... I also cc:ed Richard :-) thanks Dagmar (and Richard for the correction), if I get a chance I'll be having a look - although my Java is not particularly strong. SED-ML would allow you [being in Auckland] to send me [being in Rostock] the *description* of what you did, so that I can launch a simulation tool and repeat the steps you did. If you want to reuse the simulation data (results), you probably want to use efforts such as SBRML from Pedro Mendes' group to do so (http://www.comp-sys-bio.org/tiki-index.php?page=SBRML). You could include a reference to a result data set encoded in SBRML in your SED-ML file (as a note only, currently) to refer to the result data from your simulation description. ... if that is what you want ... :-) yep. it will certainly be interesting to see how this evolves - whether people actually want to share results or if you always want to re-run the simulation in your own tool :) Cheers, Andre. ___ cellml-discussion mailing list cellml-discussion@cellml.org http://www.cellml.org/mailman/listinfo/cellml-discussion
Re: [cellml-discussion] ABI CellML meeting minutes 2009-09-30
Hi Dagmar,
Thanks for your comments! I'll just make a couple of notes inline below...
* Andre said that SED-ML does not yet support everything that we
need to do for simulation and graphing.
I agree that SED-ML still is at quite an early stage and might not cover
everything needed.
However, even if the structure of SED-ML does not offer particular
constructs for some of your needs, you are allowed (by definition of the
SED-ML schema) to attach annotations to *any* SED-ML element. Thus, you
could extend SED-ML towards supporting whatever additional needs you might
have for information to put in the simulation description file.
Do you think that would be sufficient? As Nicolas mentioned, that would
actually be a nice benchmark for us to see in what way SED-ML needs to be
extended (certainly by what you would put in the annotations often).
I agree. The way forward here is to start using SED-ML with CellML
models and see how things work out and what possible extensions are
required, and also whether these can be incorporated through the
existing annotation mechanism. I know that at least myself and maybe
others have volunteered to do this at some point, but I have yet to
sit down and do it :) We are also hoping that a core SED-ML supporting
library or tool might become available that we could work with in
order to implement support for CellML. From the Waiheke meeting, Ion
offered to make the VCell code available but I haven't had a chance to
follow up on this.
* Andrew said that we are still trying to convince the SED-ML group
to separate out graphing and simulation.
I can say that SED-ML is *not* about graphing at all - in the sense that I
understand graphing. SED-ML should provide the description of the data that
is used to create the output, and also how these data relate, e.g. for a 2
dimensional plot you would have to specify what to plot against what (x and
y axes). Let me cite Nicolas again from an earlier mail: E.g. we can create
a report {time, var1, var2}, but some information will only emerge if we
plot var1 versus var2. In some sense the relationship between var1 and
var2 representation is part of the post-processing.
related to the point below, but what I think this is hinting at is
that we prefer to see a distinction between describing and performing
a simulation and processing/extracting/manipulating/graphing the
resultant data. I don't see this as a major sticking point at present
but rather something that will evolve over time if we can get the SBML
and CellML communities using a common simulation experiment
description framework.
* Andre said that you might want to change some of the graphing
metadata to get different graphs from the same simulation, or vice
versa.
If we are talking about running one simulation and creating a number of
different graphs (say, many 2D plots) from that simulation, this is already
possible in SED-ML right now. All you have to do is to define a number of
(what we call) data generators, referring to the variables/parameters you
want to use for your output. Then you can define as many outputs as you
want, referring to the same or different data generators and to the same of
different simulation setups.
If you look at the example given in the publication of CMSB 2008, on page
9/10 (http://www.springerlink.com/content/n67n137071431xt7/), we defined a
data generator called time and we use it to create 2 different curves from
one single simulation (only the x axis is varying here, using 2 different
models).
If we, however, are talking about producing the same graph one time with a
red line, one time with a green line - those things are not part of SED-ML
core information, and they should go to the above mentioned annotations.
no, what this is addressing that modellers should be able to reuse
different parts of the simulation experiment description without
needing to redefine it. For example, here in Auckland I define an
experiment using the Hodgkin-Huxley model with a certain stimulus
protocol and produce some action potentials. Now you over in Rostock
want to use that data to produce some current-voltage data. It would
be great if you were able to make use of my simulation description and
its resultant data without having to redefine the simulation
description locally or perhaps even re-running the simulation. I'm not
sure if this is already something that SED-ML can include, but it is
certainly something that we'd be keen to see in the future.
In terms of actually defining the presentation of specific outputs
(lines on a graph, surfaces, points, etc), this again is something
that we are very keen on in order to be able to unambiguously and
completely describe outputs from a simulation experiment. This is not
a small problem, although the current CellML graphing metadata begins
to address this in regard to specific types of outputs. As above, we
don't see this as a major issue blocking the
Re: [cellml-discussion] ABI CellML meeting minutes 2009-09-30
Thanks Dagmar. We are committed to SED-ML! Your comments are very helpful. Peter
--
Sent using BlackBerry
- Original Message -
From: cellml-discussion-boun...@cellml.org
cellml-discussion-boun...@cellml.org
To: CellML Discussion List cellml-discussion@cellml.org
Sent: Fri Oct 09 19:41:19 2009
Subject: Re: [cellml-discussion] ABI CellML meeting minutes 2009-09-30
Dear all,
I'd like to comment on the last meeting minutes, particularly on the
metadata specification comments made by Andre:
* Andre said that SED-ML does not yet support everything that we
need to do for simulation and graphing.
I agree that SED-ML still is at quite an early stage and might not cover
everything needed.
However, even if the structure of SED-ML does not offer particular
constructs for some of your needs, you are allowed (by definition of the
SED-ML schema) to attach annotations to *any* SED-ML element. Thus, you
could extend SED-ML towards supporting whatever additional needs you
might have for information to put in the simulation description file.
Do you think that would be sufficient? As Nicolas mentioned, that would
actually be a nice benchmark for us to see in what way SED-ML needs to
be extended (certainly by what you would put in the annotations often).
* Andrew said that we are still trying to convince the SED-ML group
to separate out graphing and simulation.
I can say that SED-ML is *not* about graphing at all - in the sense that
I understand graphing. SED-ML should provide the description of the data
that is used to create the output, and also how these data relate, e.g.
for a 2 dimensional plot you would have to specify what to plot against
what (x and y axes). Let me cite Nicolas again from an earlier mail:
E.g. we can create a report {time, var1, var2}, but some information
will only emerge if we plot var1 versus var2. In some sense the
relationship between var1 and var2 representation is part of the
post-processing.
* Andre said that you might want to change some of the graphing
metadata to get different graphs from the same simulation, or vice
versa.
If we are talking about running one simulation and creating a number of
different graphs (say, many 2D plots) from that simulation, this is
already possible in SED-ML right now. All you have to do is to define a
number of (what we call) data generators, referring to the
variables/parameters you want to use for your output. Then you can
define as many outputs as you want, referring to the same or different
data generators and to the same of different simulation setups.
If you look at the example given in the publication of CMSB 2008, on
page 9/10 (http://www.springerlink.com/content/n67n137071431xt7/), we
defined a data generator called time and we use it to create 2
different curves from one single simulation (only the x axis is varying
here, using 2 different models).
If we, however, are talking about producing the same graph one time with
a red line, one time with a green line - those things are not part of
SED-ML core information, and they should go to the above mentioned
annotations.
* Peter said that we want to encourage cooperation, and use accepted
standards if they exist.
I cannot tell you how much we would like to see CellML using SED-ML :-)
I know that we do progress pretty slowly, and I am very sorry for that.
* Andre said that the minimal information standard should be out soon.
Maybe a word on that: We are currently (and have been for a while...
slow again, I know) working on writing up the MIASE guidelines. In my
opinion, we do make good progress and I think that we have come to quite
a good consensus already. So, there is hope that soon won't take too long.
I am happy to answer all the questions you might have!
Many greetings from Rostock,
Dagmar
Dougal Cowan wrote:
I have put the minutes from this Wednesday's meeting up at:
http://www.cellml.org/community/meeting/minutes/2009/10.07
Dougal
__ Information from ESET Smart Security, version of virus signature
database 4488 (20091007) __
The message was checked by ESET Smart Security.
http://www.eset.com
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion
