From dj.cowan at auckland.ac.nz Tue Oct 6 14:54:53 2009 From: dj.cowan at auckland.ac.nz (Dougal Cowan) Date: Tue, 06 Oct 2009 14:54:53 +1300 Subject: [cellml-discussion] ABI CellML meeting minutes 2009-09-30 Message-ID: <4ACAA36D.7000602@auckland.ac.nz> My apologies for the lateness of this announcement. I have put the minutes from last week's meeting up at: http://www.cellml.org/community/meeting/minutes/2009/09.30 Dougal From dj.cowan at auckland.ac.nz Thu Oct 8 15:08:54 2009 From: dj.cowan at auckland.ac.nz (Dougal Cowan) Date: Thu, 08 Oct 2009 15:08:54 +1300 Subject: [cellml-discussion] ABI CellML meeting minutes 2009-09-30 Message-ID: <4ACD49B6.4090300@auckland.ac.nz> 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 From dj.cowan at auckland.ac.nz Thu Oct 8 15:16:00 2009 From: dj.cowan at auckland.ac.nz (Dougal Cowan) Date: Thu, 08 Oct 2009 15:16:00 +1300 Subject: [cellml-discussion] ABI CellML meeting minutes 2009-10-07 Message-ID: <4ACD4B60.7020301@auckland.ac.nz> The subject was wrong, but the link was correct! Sorry. 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 From alan.garny at dpag.ox.ac.uk Thu Oct 8 22:15:35 2009 From: alan.garny at dpag.ox.ac.uk (Alan Garny) Date: Thu, 8 Oct 2009 10:15:35 +0100 Subject: [cellml-discussion] ABI CellML meeting minutes 2009-10-07 In-Reply-To: <4ACD49B6.4090300@auckland.ac.nz> References: <4ACD49B6.4090300@auckland.ac.nz> Message-ID: <001601ca47f7$e4f29dc0$aed7d940$@garny@dpag.ox.ac.uk> Just to clarify something: 6.3 - Peter mentioned Alan Garny's reports of discrepancies in some models. The report is not mine (though I do endorse it), but that of Penny Noble whom I asked to go through all the models that she/I encoded into CellML, and check them against PMR2. This was the result of a discussion Peter and I had when he was last in Oxford. Alan > -----Original Message----- > From: cellml-discussion-bounces at cellml.org [mailto:cellml-discussion- > bounces at cellml.org] On Behalf Of Dougal Cowan > Sent: 08 October 2009 03:09 > To: cellml-discussion at cellml.org > Subject: [cellml-discussion] ABI CellML meeting minutes 2009-09-30 > > 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 at cellml.org > http://www.cellml.org/mailman/listinfo/cellml-discussion From dagmar.koehn at uni-rostock.de Fri Oct 9 19:41:19 2009 From: dagmar.koehn at uni-rostock.de (Dagmar Koehn) Date: Fri, 09 Oct 2009 08:41:19 +0200 Subject: [cellml-discussion] ABI CellML meeting minutes 2009-09-30 In-Reply-To: <4ACD49B6.4090300@auckland.ac.nz> References: <4ACD49B6.4090300@auckland.ac.nz> Message-ID: <4ACEDB0F.5000002@uni-rostock.de> 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 at cellml.org > http://www.cellml.org/mailman/listinfo/cellml-discussion > > From p.hunter at auckland.ac.nz Fri Oct 9 19:52:35 2009 From: p.hunter at auckland.ac.nz (Peter Hunter) Date: Fri, 9 Oct 2009 19:52:35 +1300 Subject: [cellml-discussion] ABI CellML meeting minutes 2009-09-30 Message-ID: Thanks Dagmar. We are committed to SED-ML! Your comments are very helpful. Peter -------------------------- Sent using BlackBerry ----- Original Message ----- From: cellml-discussion-bounces at cellml.org To: CellML Discussion List 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 at cellml.org > http://www.cellml.org/mailman/listinfo/cellml-discussion > > _______________________________________________ cellml-discussion mailing list cellml-discussion at cellml.org http://www.cellml.org/mailman/listinfo/cellml-discussion From david.nickerson at gmail.com Tue Oct 13 13:27:27 2009 From: david.nickerson at gmail.com (David Nickerson) Date: Tue, 13 Oct 2009 13:27:27 +1300 Subject: [cellml-discussion] ABI CellML meeting minutes 2009-09-30 In-Reply-To: <4ACEDB0F.5000002@uni-rostock.de> References: <4ACD49B6.4090300@auckland.ac.nz> <4ACEDB0F.5000002@uni-rostock.de> Message-ID: 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 adoption of SED-ML for use with CellML models, more something that will come out of this work if required by the communities. And would most likely fit into the existing annotation framework. > ? * 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. yep, and progress this end is just as slow. I'm not sure if any of the core SED-ML group are planning to attend the CellML workshop in February next year, but it would be useful I think to get people together at some conference or other and see if we can work through some concrete examples. I'll be at the INCF workshop in Bangalore next month and I think Nicolas will also be there (along with Jim from the Virtual Cell?), so hopefully we'll get a brief chance to talk about SED-ML over those few days... Thanks again for your comments :) and to follow-up Peter's reply, we are certainly keen to start trying out SED-ML...just need to find the time... Cheers, Andre. From ak.miller at auckland.ac.nz Wed Oct 14 14:50:49 2009 From: ak.miller at auckland.ac.nz (Andrew Miller) Date: Wed, 14 Oct 2009 14:50:49 +1300 Subject: [cellml-discussion] Stochastic support / non-exclusion in CellML 1.2 In-Reply-To: <20091014144049.15664kspn3r7671d@webmail.bioeng.auckland.ac.nz> References: <00b201ca4868$a54b3ad0$efe1b070$@cooling@auckland.ac.nz> <20091014144049.15664kspn3r7671d@webmail.bioeng.auckland.ac.nz> Message-ID: <4AD52E79.6090409@auckland.ac.nz> Michael Cooling wrote: > Hi > > I'm still interested in the below. Does anyone have any information > beyond the comment I cite below? > > In particular, might I be able to read the document that Andrew wrote? Hi Mike, We don't have much in the way of a well-developed document; but a brief proposal was included in this message: http://www.cellml.org/pipermail/cellml-discussion/2008-April/001231.html This is something that we need to put more work into before we have anything generally useful, so please feel free to continue from where we are up to in that document. Also, you might want to listen to my conversation with Kevin Burrage; although most of the call is really about trying to explain to Kevin that we are interested in declarative representations, rather than a specific algorithm. Go to http://www.gcast.com/u/millerak/main for the audiocast. Best wishes, Andrew > > Cheers, > > > > Quoting Mike Cooling : > >> Hi >> >> >> >> I would like to get a rough idea of the possibility of stochastic >> modelling support by CellML in 'the future'. >> >> >> >> There is a reference to some work done by Andrew in this area in a >> meeting >> minute from mid 2008 (reproduced below). >> >> >> >> Is this the last time work was done in this area ( to the best of your >> knowledge ) and is there any way I can read a copy of some document >> outlining 'Andrew's proposal on how to represent stochastic systems...' ? >> >> >> >> Thanks for your time, >> >> >> >> Mike. >> >> >> >> >> >> "CellML 1.2 specification update >> >> * Andrew talked with Kevin Burrage last Friday about how stochastic >> systems might potentially be represented in CellML 1.2 >> * The audiocast of this conversation can be found at: >> http://www.gcast.com/u/millerak/main >> * The conversation was useful but Andrew's proposal on how to >> represent stochastic systems in CellML 1.2 still stands as it was. >> * Presently no further discussions with Kevin Burrage are scheduled. >> * There are a number of classes of stochastic systems we could >> represent. Andrew's proposed approach is to allow generic representation >> and then identify specific classes, such as systems described by the >> Gillespie algorithm. >> * Andrew noted that while we don't have to explicitly provide a >> representation of stochastic systems in CellML 1.2, we should be making >> 1.2 generic enough to allow for a secondary specification representing >> these systems." >> >> >> >> >> >> > > > > ---------------------------------------------------------------- > This message was sent using IMP, the Internet Messaging Program. > From dj.cowan at auckland.ac.nz Mon Oct 19 09:10:31 2009 From: dj.cowan at auckland.ac.nz (Dougal Cowan) Date: Mon, 19 Oct 2009 09:10:31 +1300 Subject: [cellml-discussion] ABI CellML meeting minutes 2009-10-14 Message-ID: <4ADB7637.4080100@auckland.ac.nz> I have put the minutes from Wednesday's meeting up at: http://www.cellml.org/community/meeting/minutes/2009/10.14 Dougal From dagmar.koehn at uni-rostock.de Mon Oct 26 23:44:08 2009 From: dagmar.koehn at uni-rostock.de (Dagmar Koehn) Date: Mon, 26 Oct 2009 11:44:08 +0100 Subject: [cellml-discussion] ABI CellML meeting minutes 2009-09-30 In-Reply-To: References: <4ACD49B6.4090300@auckland.ac.nz> <4ACEDB0F.5000002@uni-rostock.de> Message-ID: <4AE57D78.8010301@uni-rostock.de> 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 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. > 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 ... :-) Best, Dagmar From dj.cowan at auckland.ac.nz Tue Oct 27 09:13:11 2009 From: dj.cowan at auckland.ac.nz (Dougal Cowan) Date: Tue, 27 Oct 2009 09:13:11 +1300 Subject: [cellml-discussion] ABI CellML meeting minutes 2009-10-21 Message-ID: <4AE602D7.4060908@auckland.ac.nz> I have put the minutes from Wednesday's CellML meeting up at: http://www.cellml.org/community/meeting/minutes/2009/10.21 Dougal From radams at staffmail.ed.ac.uk Tue Oct 27 00:37:13 2009 From: radams at staffmail.ed.ac.uk (Richard Adams) Date: Mon, 26 Oct 2009 11:37:13 +0000 Subject: [cellml-discussion] ABI CellML meeting minutes 2009-09-30 In-Reply-To: <4AE57D78.8010301@uni-rostock.de> References: <4ACD49B6.4090300@auckland.ac.nz> <4ACEDB0F.5000002@uni-rostock.de> <4AE57D78.8010301@uni-rostock.de> Message-ID: <20091026113713.7tq7db4fkoc0g4ok@www.staffmail.ed.ac.uk> Hi Dagar, The validator link is actually: http://www.bioinformatics.ed.ac.uk:8080/SBSIWeb/html/sedml/ Best wishes Richard > 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 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. >> > > 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 ... :-) > > Best, > Dagmar -- Dr Richard Adams Senior Software Developer, Computational Systems Biology Group, University of Edinburgh Tel: 0131 650 8285 email : richard.adams at ed.ac.uk -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. From david.nickerson at gmail.com Tue Oct 27 11:23:17 2009 From: david.nickerson at gmail.com (David Nickerson) Date: Tue, 27 Oct 2009 11:23:17 +1300 Subject: [cellml-discussion] ABI CellML meeting minutes 2009-09-30 In-Reply-To: <4AE57D78.8010301@uni-rostock.de> References: <4ACD49B6.4090300@auckland.ac.nz> <4ACEDB0F.5000002@uni-rostock.de> <4AE57D78.8010301@uni-rostock.de> Message-ID: > 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. From Moraru at NEURON.UCHC.EDU Wed Oct 28 15:47:43 2009 From: Moraru at NEURON.UCHC.EDU (Moraru,Ion) Date: Tue, 27 Oct 2009 22:47:43 -0400 Subject: [cellml-discussion] ABI CellML meeting minutes 2009-09-30 In-Reply-To: <4AE57D78.8010301@uni-rostock.de> References: <4ACD49B6.4090300@auckland.ac.nz> <4ACEDB0F.5000002@uni-rostock.de> , <4AE57D78.8010301@uni-rostock.de> Message-ID: <24F586D996DC614BA8E19114DA4C28514FD6@nso-itexc-mb09.uchc.net> 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.koehn at 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 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. > 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 ... :-) Best, Dagmar From dj.cowan at auckland.ac.nz Fri Oct 30 14:40:27 2009 From: dj.cowan at auckland.ac.nz (Dougal Cowan) Date: Fri, 30 Oct 2009 14:40:27 +1300 Subject: [cellml-discussion] ABI CellML meeting minutes 2009-10-28 Message-ID: <4AEA440B.2010600@auckland.ac.nz> I have put the minutes from this week's meeting up at: http://www.cellml.org/community/meeting/minutes/2009/10.28 Dougal