Re: [cellml-discussion] Auckland CellML Meeting planned for Wednesday July 4th from 9-10 AM (NZST)
I have one comment: * Andrew Miller [2012-07-03 00:07] writes: > 2. Should CellML 1.2 be an incremental change over CellML 1.1, with > another version planned shortly after, or should it try to incorporate a > wider set of changes? (target: 9:05 - 9:25) This strikes me as being the wrong question. Instead I would ask, "What do we want to accomplish with CellML that cannot be accomplished with 1.1?" Then you look at the list of things you came up with, and classify each into 'would be a small change' vs. 'would be a large change'. Then, finally, you look at the list of small changes and decide whether it's worth it to have a release with just those changes vs. the whole list. I would think the MathML 3.0 question would fall out of this discussion, too, rather than having to be a separate agenda item. -Lucian ___ cellml-discussion mailing list cellml-discussion@cellml.org http://lists.cellml.org/mailman/listinfo/cellml-discussion
Re: [cellml-discussion] [sbml-distrib] New draft secondary specification: Uncertainty
* Andrew Miller [2012-05-29 10:52] writes: > On 29/05/12 20:17, Michael Clerx wrote: > > Dear all, > > > > I'm glad to see uncertainty being taken into acount in cell models. > > Perhaps it would be worthwhile to add the scenario where no assumptions > > are made about the uncertainty and a parameter value is simply given by > > its upper and lower bounds. > > I agree that there needs to be some way to handle that scenario. > However, it might be that in most cases where people do that, a uniform > distribution with upper and lower bounds will suffice - it seems to me > that saying a random variable is distributed uniformly between an upper > and lower bound is an explicit statement that the modeller knows that > the value falls in certain bounds, but has no reason to believe it is > any more likely to fall in one place within those bounds than anywhere else. A uniform distribution is a huge assumption about a given range; I believe it would be not at all justified to make such an assumption by default. If the user knows that the value is distributed in a uniform linear fashion, they should be able to say that; likewise a uniform log or a normal or an Epanechnikov kernel. But telling them they have to pick, or, worse, assuming you know when they didn't tell you is dangerous. -Lucian ___ cellml-discussion mailing list cellml-discussion@cellml.org http://lists.cellml.org/mailman/listinfo/cellml-discussion
[cellml-discussion] (forw) JSim 2.06 released
Some of you might be interested in this--JSim now has CellML output as well as CellML input. Since JSim models themselves are not modular, everything gets put into a single component; there is hope that in the future when JSim itself is modular, it will be able to produce modular CellML output. A few more details at http://physiome.org/jsim/docs/MML_CellML.html#exporting -Lucian - Forwarded message from Erik Butterworth - From: Erik Butterworth Reply-To: Erik B To: JSim Development -- Adam Alessio , "Dr. James Caldwell" , Forbes Dewey , "Huhns, Michael" , Melissa Krueger , Max Neal , David Nickerson , Bart Jardine , Gary Raymond , "Dr. James Bassingthwaighte" , Lucian Smith , Rebecca Rowe , "Dash, Ranjan" , Richard Ward , Herb Sauro , Andreas Schwab , Shiva Ayyadurai , Gary Ynvge , Adam Alessio Subject: JSim 2.06 released Date: Thu, 2 Feb 2012 10:01:48 -0800 (PST) Message-ID: Highlights: o new Monte-Carlo analysis module; o CellML output is now available; o various bug fixes, including one in SBML import which previously mishandled time-varying compartment volumes. See the JSim home page for complete information on JSim, including documentation, downloads, documentation and model repositories: http://physiome.org/jsim/ For complete details on the latest release, click on "What's New?" Note to QPP users: JSim 2.06 should not be used with the previous QPP release (0.913). A new QPP release, 0.914, will be made later today that is compatible with JSim 2.06. Erik Butterworthbutt...@uw.edu206-685-2007 Software Engineer, University of Washington Bioengineering http://physiome.org/~butterw/ - End forwarded message - ___ cellml-discussion mailing list cellml-discussion@cellml.org http://lists.cellml.org/mailman/listinfo/cellml-discussion
Re: [cellml-discussion] Improved CellML support in latest version of JSim
Thanks for the notice, Andre! I want to note that if anyone finds some aspect of their favorite model doesn't survive the new translation, be sure to email me, and I'll see what I can do. I downloaded 1055 models from the repository as my test bed for this project, and got 884 of them working up to the point of making them simulatable. The one thing we don't do yet that prevented most of the remaining models from working in JSim is the feature that imports a component from another file. That feature is on the list of things we'd like to do at some point, but if it would be particularly helpful for your work, let us know and we'll bump it up the priority list. I found 141 models of this sort, leaving only 30 that failed for some other reason; mostly due to using some MathML construct JSim doesn't support (like 'partialdiff'). For CelML model developers and curators, I wrote a new section on using JSim to help curate the model: http://physiome.org/jsim/docs/MML_CellML.html#curation It explains how to take the JSim-translated version of your model and find potential sources of error in the model itself. In particular, JSim should now be a good tool for figuring out if the model is over- or under-determined, and for getting the units correct. More details can be found on that same page: http://physiome.org/jsim/docs/MML_CellML.html >From my work for this, I now also have translated versions of all 1055 models, so I can tell you which are the 159 models we found unit errors in, which models were overdetermined, etc. If some curator is interested in the list (and/or how they could make this list themselves), let me know. -Lucian * David Nickerson [2011-12-19 19:36] writes: > Hi all, > > JSim 2.05 has just been released and now has improved support for CellML > models. See the release announcement below. > > Cheers, > Andre. > > > > Highlights: > > o JSim now uses Java 6 rather than Java 5, resulting in various minor > improvements. If you're running JSim applets in your browser, but sure to > update your Java to version 6. > > o JSim's CellML importer has been substantially improved (thanks to LS). > JSim now runs 95% of the CellML 1.0 models in the CellML archive out of box > (no editing required). > > o Parameter set functionality has been substantially improved, including > the addition of loops, sensitivity and optimization configuration to > parameter sets. > > o Various minor fixes and feature improvements. > > See the JSim home page for complete information on JSim, including > documentation, downloads, documentation and model repositories: > > http://physiome.org/jsim/ > > For complete details on the latest release, click on "What's New?" > ___ > cellml-discussion mailing list > cellml-discussion@cellml.org > http://lists.cellml.org/mailman/listinfo/cellml-discussion ___ cellml-discussion mailing list cellml-discussion@cellml.org http://lists.cellml.org/mailman/listinfo/cellml-discussion
Re: [cellml-discussion] Independent variables, and delay
* David Nickerson [2011-12-16 22:48] writes: > Hi Lucian, > > On Sat, Dec 17, 2011 at 7:53 AM, Lucian Smith > wrote: > > A couple questions. ?One: ?is there a defined way in CellML to find the > > independent variables? ?The spec says (about 'initial_value'): > > > > ?This attribute provides a convenient means for specifying the value of a > > ?scalar real variable when all independent variables in the model have a > > ?value of 0.0. Independent variables are those whose values do not depend > > ?on others. > > > > From that definition, it would seem that if you defined 'pi' in your > > model, the initial value would apply when pi was equal to 0. > > This is one of the known problems with using the initial value > attribute to set constants. It is true that setting something like pi > (although there is a mathml constant for pi, btw) using the initial > value attribute is a bit ambiguous. It is therefore now suggested that > numerical constants are set using an equation rather than by the > initial value attribute. See http://models.cellml.org/exposure/d79 for > an example defining fundamental constants in this manner. That's not *quite* what I was getting at--I meant that if you had 'pi' in your model somewhere (or some other constant), it would be 'a variable whose value did not depend on others', and therefore would be classified as 'an independent variable'. So for all other variables, if the 'intial_value' only applied when all independent variables were equal to 0.0, it would have to wait for pi to equal zero, too ;-) (OK, so I didn't *really* think that was the correct interpretation, but I did wonder what exactly an 'independent variable' was if you couldn't denote it as such in CellML. Perhaps this would be something for 1.2?) > > But more generally, if you have a single equation in your model: > > > > u = sin(t) > > > > That's a single equation with two variables--how do you decide that you > > want to vary t and not u? ?Do you just apply heuristics, so if you see > > 'dx/dy' you assume y is the independent variable? ?Is it part of what you > > do *with* a CellML model, that you present the user with t and u as > > possible options, and they pick one? > > in this example, it is impossible to determine the independent > variable without further information. Of course, most tools would > probably assume t is the independent variable. Once you have a bound > variable in the model (MathML bvar element), that determines the > independent variable - this is one reason why some tools require at > least one differential equation in order to be able to run a > simulation. So, I guess it's impossible to write models with a dependent variable as a bvar? x initial_value=0; z initial_value=0; dx/dy = 3; dz/dx = 4; > In some of the tissue mechanics modelling we do we use CellML to > describe constitutive relationships which often are a series of > algebraic equations. In this case we need to define in our simulation > tool what the independent variable(s) are and provide the values for > them (i.e., the components of the strain tensor). Would it be helpful to encode this information into the model itself, or semantically, do you want to keep them distinct? I suppose it's edging into the SEDML territory of 'what you do with a model' instead of 'what the model is'--I can imagine models where you vary the components of the strain tensor in one simulation to determine some other value, and in your second simulation you vary the other value to determine the strain tensor. > > My second question is a bit simpler: ?is there a way to define a delay > > equation in CellML and if so, how do you do it? ?(A delay being > > something like 'x, 2 seconds ago'.) > > there is, but its not really used by any real models. The plan is to > make things easier in CellML 1.2, but the focus to date has been on > the use of instantaneous delays in event descriptions. You can see > https://tracker.physiomeproject.org/show_bug.cgi?id=70 and > https://tracker.physiomeproject.org/show_bug.cgi?id=1543 for some > comments along these lines, and hopefully Andrew or Randall will reply > with a better answer for you. What about tool support? Is there support in any/some tools for delays? I ask from the perspective of a translator, converting models with delays from other systems to CellML. -Lucian ___ cellml-discussion mailing list cellml-discussion@cellml.org http://lists.cellml.org/mailman/listinfo/cellml-discussion
[cellml-discussion] Independent variables, and delay
A couple questions. One: is there a defined way in CellML to find the independent variables? The spec says (about 'initial_value'): This attribute provides a convenient means for specifying the value of a scalar real variable when all independent variables in the model have a value of 0.0. Independent variables are those whose values do not depend on others. >From that definition, it would seem that if you defined 'pi' in your model, the initial value would apply when pi was equal to 0. But more generally, if you have a single equation in your model: u = sin(t) That's a single equation with two variables--how do you decide that you want to vary t and not u? Do you just apply heuristics, so if you see 'dx/dy' you assume y is the independent variable? Is it part of what you do *with* a CellML model, that you present the user with t and u as possible options, and they pick one? My second question is a bit simpler: is there a way to define a delay equation in CellML and if so, how do you do it? (A delay being something like 'x, 2 seconds ago'.) -Lucian ___ cellml-discussion mailing list cellml-discussion@cellml.org http://lists.cellml.org/mailman/listinfo/cellml-discussion
Re: [cellml-discussion] nested components in CellML
* Maxwell Neal [2011-10-21 22:03] writes: > Hi all, > > I was wondering - can CellML models have nested components? That is, are > there instances where some model component is a component in another model > component? > Thanks, Yes--this is covered by the concept of encapsulation. See http://www.cellml.org/getting-started/tutorials/tutorial/best_practice/#grouping for more detail, but basically you set up a whole tree of nested components, and this nesting determines the rules for how you can connect the variables in those components. Also, an imported component from another file that encapsulates other components brings those components (and corresponding connections) with it in the import. Is that a reasonable summary, list denizens? -Lucian ___ cellml-discussion mailing list cellml-discussion@cellml.org http://lists.cellml.org/mailman/listinfo/cellml-discussion
[cellml-discussion] New release of Antimony v2.0 and v2.1-beta
We are* pleased to announce the release of Antimony v2.0 and 2.1-beta at http://antimony.sourceforge.net/ where you can get windows binaries, source code, and documentation. = What has changed? = In addition to smaller changes like introducing a new syntax to accomodate SBML Level 3's new event features, the principle change with version 2.0 is the ability to translate CellML models, maintaining their modularity in Antimony's native modularity format. For version 2.1-beta, the principle change is the ability to produce SBML models that use the proposed 'Hierarchical Model Composition' package constructs. This feature uses the 'sbml-comp' package code written for libSBML (by yours truly) and can hopefully serve as an example both of how to write code using this package, as well as now providing the ability to produce actual hierarchical models in the proposed format. QTAntimony v2.1-beta allows you to view the SBML models in 'comp' and in 'flattened' form. From the SBML model tab, select 'Edit/Flatten SBML tab(s)' (or hit Control-F) to toggle between the two modes. The fact that v2.1 is currently in beta is a reflection of the fact that the 'comp' package proposal has not yet been finalized, and changes to the format may still occur which may invalidate models produced with this tool. Nonetheless, the models should be instructive to those interested in the comp package. Antimony now uses CMake as its build system, which hopefully will make compilation on a variety of platforms more straightforward. === What was it originally? === Antimony is a modular, human-readable, human-writeable model definition language, originally based off of Jarnac, and extended to be fully modular. So named because the chemical symbol for antimony is 'Sb', Antimony is designed to allow you to rapidly create new SBML models, and view SBML models in a simplified text form. libAntimony is a library designed to allow programmers to add interfaces to their software to allow users to create and view models in this way. It is currently used in the programs Tinkercell (http://www.tinkercell.com/) and JSim (http://www.physiome.org/jsim/). In addition, a simple editor 'QTAntimony' (written in, of all things, QT) is provided as a way to get started using Antimony on its own. This editor displays your model using different tabs, each containing a different translation. It can read and write models written in Antimony, SBML, and CellML, and can translate between the three formats by simply clicking on the appropriate tab. A major client of QTAntimony have been Biomodels.net curators, who have used it to transform models in published papers to SBML. == Where is it going? == Antimony will continue to be on the leading edge of 'comp' package use (since the same guy who's writing this program is also writing the libSBML-comp code), and will probably be one of the two implementations required to move the package to a 'finalized' status. As such, we will be adding the concept of deletions to the syntax soon, as well as the concept of conversion factors (assuming the latter survives to the final draft of the specification). In addition, it has long been our desire to add units to the Antimony syntax, and this is next on our list of Things To Do (tm). Attaching units to variables should be relatively straightforward, but allowing users to attach units to constants (as is now allowed in SBML Level 3) will probably require the development of a brand-new infix parser. If it does, we may consider donating this code to libsbml on the theory that others may find it useful as well. Watch this space! Who is to blame? Antimony was developed by Lucian Smith from an original specification developed by Dr. Herbert Sauro and Frank Bergmann, under a grant from the NIH (thanks, the NIH!). It uses libSBML (http://sbml.org/Software/libSBML), the CellML API (http://www.cellml.org/tools/api), and the QT libraries (http://qt.nokia.com/). Do I get something for reading this far? ==== My undying gratitude. And you get to read the joke footnote, below! Thank you! -Lucian Smith *(for values of 'We are' equal to 'I am'. But using 'we' makes it sound more distinguished, don't you think?) ___ cellml-discussion mailing list cellml-discussion@cellml.org http://lists.cellml.org/mailman/listinfo/cellml-discussion
Re: [cellml-discussion] ABI CellML Meeting Minutes, 14th September 2011
I should also mention that I've used the Windows Visual Studio 10 SDK with no problems at all (well, with no errors--there are about 15 bajillion warnings, but no errors). This is a tremendous relief, so thanks! (Still haven't gotten back to check the Red Hat issues I had--will report back when I do.) -Lucian * Alan Garny [2011-09-16 08:30] writes: > Hi, > > A quick comment on one of the minutes' items: > - CellML API - update: "Andrew: put out release candidate 2. Alan has > reported that something is not working in Qt Creator." For clarification, > this is not quite what I reported. I mentioned that my simple CellML test > program (using CMake; https://github.com/agarny/cellml-example-with-cmake) > works fine on Ubuntu (11.04 32- and 64-bit) and Mac OS X 10.7 (Lion), but > not on Windows 7 using the patched version of MinGW that comes with Qt SDK > 1.1.3. Qt Creator has nothing to do with it. > > Alan > > > -Original Message- > > From: cellml-discussion-boun...@cellml.org [mailto:cellml-discussion- > > boun...@cellml.org] On Behalf Of Dougal Cowan > > Sent: 16 September 2011 05:47 > > To: CellML Discussion List > > Subject: [cellml-discussion] ABI CellML Meeting Minutes, 14th September > > 2011 > > > > I have put the minutes from this week's meeting up at: > > > > http://www.cellml.org/community/meeting/minutes/2011/09.14 > > > > Cheers, > > Dougal > > > > ___ > > cellml-discussion mailing list > > cellml-discussion@cellml.org > > http://lists.cellml.org/mailman/listinfo/cellml-discussion > > ___ > cellml-discussion mailing list > cellml-discussion@cellml.org > http://lists.cellml.org/mailman/listinfo/cellml-discussion ___ cellml-discussion mailing list cellml-discussion@cellml.org http://lists.cellml.org/mailman/listinfo/cellml-discussion
Re: [cellml-discussion] ABI CellML Meeting Minutes, 6th July, 2011
* Dougal Cowan [2011-07-07 23:11] writes: > I have put the minutes from this week's meeting up at: > > http://www.cellml.org/community/meeting/minutes/2011/07.06 Re: statistical modeling, there was a workshop on the topic at the EBI a few weeks ago--the slides and audio there may be informative http://sbml.org/Events/Other_Events/statistical_models_workshop_2011 (And you can ask the sbml-distrib list at https://lists.sourceforge.net/lists/listinfo/sbml-distrib if some things are unclear--I think everyone at the conference is now on that list.) -Lucian ___ cellml-discussion mailing list cellml-discussion@cellml.org http://lists.cellml.org/mailman/listinfo/cellml-discussion
Re: [cellml-discussion] ABI CellML Meeting Minutes, 25th May 2011
For what it's worth, it's 'Darren', not 'Darryl' (the SBML 'distrib' package guy). -Lucian * Dougal Cowan [2011-05-26 22:32] writes: > I have put the minutes from this week's meeting up at: > > http://www.cellml.org/community/meeting/minutes/2011/05.25 > > Cheers, > Dougal > > ___ > cellml-discussion mailing list > cellml-discussion@cellml.org > http://lists.cellml.org/mailman/listinfo/cellml-discussion ___ cellml-discussion mailing list cellml-discussion@cellml.org http://lists.cellml.org/mailman/listinfo/cellml-discussion
Re: [cellml-discussion] Unofficial draft CellML specification - backwards compatibility, type attributes on variables
* Andrew Miller [2011-02-02 03:27] writes: > Hi all, > > I've just put up an unofficial draft CellML specification up at > http://www.cellml.org/Members/miller/draft-normative-spec-andrews-preferred/toplevel.xhtml > > to prototype what some of the new features could look like. > > This version has the following features: > Backwards and forwards compatibility with CellML 1.1. > A new attribute, type, on variables. It defaults to real, but can > alternatively point to a URL defining the type (it is up to secondary > specifications to define the meaning of URLs other than the one for real > values defined in the specification). > > The source for generating the specification and creating your own draft > version is up at http://repo.or.cz/w/cellml-draft-miller.git - the > andrews-preferred-version branch was used to generate the XHTML linked to. The section on MathML was a little vague--are *all* valid MathML constructs valid CellML constructs, or only a subset? Also, I didn't see anything in there about events--are those being deferred again? My only other suggestion is that eventually you'll want pictures in there ;-) -Lucian ___ cellml-discussion mailing list cellml-discussion@cellml.org http://lists.cellml.org/mailman/listinfo/cellml-discussion
Re: [cellml-discussion] ABI CellML Meeting Minutes, 8th December 2010
* Dougal Cowan [2010-12-09 22:12] writes: > I have put the minutes from this week's meeting up at: > > http://www.cellml.org/community/meeting/minutes/2010/12.08 Woo, I made the minutes! Thanks, guys. For what it's worth, xulrunner is not actually the only problem I am having. As I explained in more detail in an email today to Andrew and Randall, I also have problems compiling the API with omniidl (which I solved by hacking the Makefile), and with library linking (which I have not solved). The library linking issue happens whether or not I configure with xulrunner. That said, if Andrew wants to look into what it would take to change my code to not use xulrunner, I'm all for that. The code lives at svn://sys-bio.org/SVN/antimony and the main cellml bits live in src/module-cellml.cpp and src/cellmlx.cpp -Lucian ___ cellml-discussion mailing list cellml-discussion@cellml.org http://lists.cellml.org/mailman/listinfo/cellml-discussion
Re: [cellml-discussion] Fwd: [Fwd: Fwd: Curation flags]
* Catherine Lloyd [2010-06-03 20:55] writes: > Hi Lucian > > Adding to that, I'll emphasise again that this list forms the bare > minimum and we will be happy to expand on the list in the future. > "validity" and "simulation" could be two areas which we choose to > expand on first - for example simulation in a specific named tool, etc. I think 'validity' probably isn't worth spending too much time on. If it's not valid, there are probably a bajillion ways it can be invalid, and the actual 'this file is invalid on line 3 because...' message you get from the API is probably more valuable than trying to classify all the invalidity error messages into curatable groups. (Though perhaps 'the model is overspecified' might be a handy particular thing to know? And maybe it wouldn't be too hard to say 'the model is syntactically invalid' vs 'the model is semantically invalid'?) However, 'simulation' probably *is* a more productive area in which to expand--if you could tell, in general, what kind of math techniques a model needed to be simulated, you could tell if your simulator (/translator) could handle those techniques. ODE's, PDE's, algebraic rules, etc. -Lucian ___ cellml-discussion mailing list cellml-discussion@cellml.org http://www.cellml.org/mailman/listinfo/cellml-discussion
Re: [cellml-discussion] Fwd: [Fwd: Fwd: Curation flags]
My only comment is that lines 6 and 9 ('is it valid?' and 'is it
simulatable?') are the ones I'd be looking at/for the most, so if those
bit of the glyphs were emphasized or at least easy to pick out, that'd be
great.
-Lucian
* Catherine Lloyd [2010-06-03 13:27] writes:
> My apologies - my original email was more exclusive to its recipients
> that to the discussion list!
>
> I will be happy to leave this another week to give anyone else a
> change to respond if they have comments.
>
> Best wishes
> Catherine
>
>
>
> >
> >Begin forwarded message:
> >
> >>*From: *Catherine Lloyd >>>
> >>*Date: *13 May 2010 9:22:00 AM
> >>*To: *biomodels-net-disc...@lists.sourceforce.net
> >>
> >>*Cc: *Poul Nielsen >>>, Tommy Yu >>>, David Nickerson
> >>mailto:d.nicker...@auckland.ac.nz>>, Peter
> >> Hunter mailto:p.hun...@auckland.ac.nz>>,
> >> Randall Britten >> >
> >>*Subject: **Curation flags*
> >>
> >>Dear All
> >>
> >>During my last visit to the EBI in August last year I circulated a
> >>document describing the issues we have with the current star system
> >>of curation ratings, and the proposal to replace these stars with
> >>more meaningful curation "flags". Once I was back in Auckland James
> >>Lawson and I went through several iterations of testing out
> >>different flag options, and the topic was also extensively
> >>discussed at the weekly team meetings and also on the Physiome
> >>Tracker (https://tracker.physiomeproject.org/show_bug.cgi?id=87).
> >>Further, the topic was raised at the CellML workshop in February
> >>this year.
> >>
> >>In the end, as the bare minimum (we are happy to add further flags
> >>if needs be), we decided to go with the MIRIAM guidelines (see
> >>attached spreadsheet). This highlighted 2 issues with all the
> >>CellML models in the current repository - 1) None were associated
> >>with a specific terms of use/distribution and 2) None were
> >>annotated with biological data.
> >>
> >>The former has been addressed and we have chosen a creative commons
> >>attribution licence to cover all the data in the repository. Tommy
> >>has been implementing a "terms of use" page and also a "how to cite
> >>this model" page. We'd also like to include the licence term in
> >>the metadata of each model (we have found the correct RDF tag for
> >>this).
> >>
> >>The latter issue is still being addressed. I have annotated 2
> >>CellML models (Goldbeter 1991 and Teusink 2000) but we have to
> >>decide if this is the way we want to annotate models, and if so,
> >>confirm it in the metadata specification. Also until we have
> >>better annotation tools, adding these terms using a text editor is
> >>the only method available and it is less than ideal - that said, I
> >>will be meeting Allyson and Morgan next week to see if it is
> >>possible for me to use Saint to annotate the models. This would be
> >>fantastic from my point of view - BUT - there is then the danger of
> >>me annotating several models in a certain way - only to have to re-
> >>do them later when it's decided the method of annotation has to
> >>change.
> >>
> >>I'll also attend the annotation meeting at the EBI next week.
> >>
> >>I'm circulating this now at the request of the BioModels team, who
> >>are interested in our thoughts on the flags. Ideally the two
> >>efforts would adopt the same set of flags.
> >>
> >>Camille and Lukas looked at our spreadsheets a while ago, and the
> >>attached spreadsheet has been modified in response to their
> >>comments. Additional feedback is always welcome.
> >>
> >>Once we have confirmed the set of flags, Tommy will be able to
> >>start to implement them in the next version of PMR2.
> >>
> >>Best wishes
> >>Catherine
> >>
> >>
> >>
> >
> >>
> >>
> >>
> >>
> >
>
> ___
> 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] CellML models in Antimony format
Thanks to the help of many of you on this list, I now have a working CellML-to-Antimony translator, and have used it to translate all the models at models.cellml.org into the Antimony format. The results are at: http://antimony.sourceforge.net/antimony-cellml.html along with SBML versions of those files, as translated from Antimony. These SBML versions are probably not as good as those created with the existing cellml2sbml translators--various aspects of the CellML files have been lost. They do, however, work for 1.1 models, which (I believe) some cellml2sbml translators are unable to do (thanks to the use of the CellML API). The main advantage of this translator is that it preserves and translates the modularity from the CellML format to the Antimony format. The Antimony format is very similar to the as-yet-hypothetical hierarchical modeling package for SBML, and thus should provide a good basis for future translations between CellML and that SBML package. This modularity includes the 'encapsulation' concept in CellML--if one compartment 'encapsulates' another in a CellML file, that corresponding parent module in Antimony will contain the submodule. All of the math found in ~92% of the models was successfully translated; of the remaining 8%, most were due to Antimony's insistence that assignment rules not be defined circularly, and the remainder tended to be little-used CellML constructs such as partial differential equations or rates of change with respect to some non-time variable. All elements like this that failed to translate are mentioned in a comment a the top of the file. Other aspects that we didn't attempt to translate include units, compartments, and annotation. (And reactions, but there are zero reactions at cellml.org, so I think we're safe there.) We hope that future versions of the translator will include these aspects, at least insofar as cellml->antimony->SBML translators. If you have comments on how well or how poorly we managed to translate your favorite CellML model to Antimony, we would love to hear from you. Thank you! -Lucian ___ cellml-discussion mailing list cellml-discussion@cellml.org http://www.cellml.org/mailman/listinfo/cellml-discussion
Re: [cellml-discussion] Leftover thoughts from the CellML workshop
(Whoops, I meant to send this to the list, but replied directly to Poul instead...) - Forwarded message from Lucian Smith - A couple follow-up thoughts: * Poul Nielsen [2010-03-11 03:28] writes: > Dear Lucian > > Many thanks for your participation in the CellML workshop and subsequent > comments. > > On 2010-02-27, at 08:43, Lucian Smith wrote: > > > CellML 1.2: > >One thing I noticed was the claim that events could be stored in > > CellML as piecewise formulas. I'm pretty sure that won't be the case with > > SBML events, which are 'fire once' events instead of 'true while' events. > > Maybe one could come up with a piecewise hack to store SBML events, but if > > a goal is to become more amenable to SBML-translated models, you might > > want to think about how best to translate SBML events. Or maybe I'm wrong > > and there's already a way to do it? > >Another thing I noticed was a reluctance to add too many new features > > to the language in the fear that interpreters might not be able or willing > > to handle them. One way to mitigate this would be to allow models to > > claim somewhere in the header whether the model required that feature or > > not--an interpreter could then more cleanly note whether it was able to > > correctly interpret a given model, while still being able to interpret > > other 1.2 models. > > I don't think the goal is necessarily to become more amenable to > SBML-translated models. What we are most strongly motivated by is to > come up with simple, powerful generic mechanisms for representing events > and behaviours that depend on them. I would value your thoughts on why > piecewise representations are insufficient for handling events. Certainly I don't think SBML translation is *the* goal of CellML 1.2, I just posited that it might be *a* goal. Piecewise functions say "while (condition), the following is always true". SBML events say "when (condition) becomes true, set the following to be true at that instant, and let it change after that." Depending on the nature of the condition, these can be very different beasts. As an example, you could have a species X controlled by various reactions, and at regular intervals, it's being injected into the system (daily feeding, say). An SBML event would just say something like 'when time is a multiple of 24, X = X+5'. A piecewise function would have to incorporate that event into all the other things that change X. It might be possible, but the resulting expression will probably be very complicated. And it might be impossible to write any sort of automatic translator that translated SBML events to CellML. At the core, SBML events allow you to separate 'the sort of math the normally happens to these variables' from 'these things happen every so often, and the model adjusts accordingly'. If you require those two things to be mushed together into piecewise functions, I *think* you could probably end up with a function that produced the same output (though there might be some counter-examples), but it would be complicated. I'm not saying you definitely should add SBML-style events to CellML, but the tradeoff is simplicity for interpreters if you leave it as-is vs. simplicity for modelers if you add some new construct. -Lucian ___ cellml-discussion mailing list cellml-discussion@cellml.org http://www.cellml.org/mailman/listinfo/cellml-discussion
[cellml-discussion] Leftover thoughts from the CellML workshop
Thanks to all of you who were at the workshop for letting me attend remotely. I found it quite valuable, and hope you didn't mind me asking you all to repeat the questions too often. And special thanks to Catherine for being the driving force behind getting it all set up! I had a couple extra thoughts on some of the presentations, which I probably would have chatted with you about had I been there, but since I wasn't, here they are in email instead. The OpenCell network visualization tool: I agree that there is definitely a need both for automatically- generated network visualization and for human-arranged network visualization. One thing that might help this is to have a standard for exchanging or at least storing these--I know SBML has a 'layout extension' that stores the visual representation of SBML models. I don't know if a CellML extension is the right way to go or if that information is better suited to storing in a separate file, but you could at least look at that extension for an example of the information you'd want to store. CellML 1.2: One thing I noticed was the claim that events could be stored in CellML as piecewise formulas. I'm pretty sure that won't be the case with SBML events, which are 'fire once' events instead of 'true while' events. Maybe one could come up with a piecewise hack to store SBML events, but if a goal is to become more amenable to SBML-translated models, you might want to think about how best to translate SBML events. Or maybe I'm wrong and there's already a way to do it? Another thing I noticed was a reluctance to add too many new features to the language in the fear that interpreters might not be able or willing to handle them. One way to mitigate this would be to allow models to claim somewhere in the header whether the model required that feature or not--an interpreter could then more cleanly note whether it was able to correctly interpret a given model, while still being able to interpret other 1.2 models. Roundtrip translators: I think I'm coming around to the theory that we don't need non-lossy translators--that's probably an unattainable goal. What might be more helpful instead is roundtrop re-integrators. What I mean by that is that nobody actually needs a way to round-trip a model that has never been modified, because you still have the original. Instead, what you need is a way to translate a model to a new format, modify it in that new format, translate it back to the original format, and end up with a model that is identical to the original model except for those bits that have been changed. I think the best hope for this is if you take the original model and the round-tripped-and-modified model, and re-integrate the two. Obviously, the trickiest bit of this is if you've modified the model by deleting something--you need to know that the round-tripping was *able* to keep the information, so that if it's gone, that means it's been deleted on purpose. But everything else can stay. Similarly, you need to know if the format of the information will have changed, and if so, how to map the new format to the old format. This may well be the trickier bit--I certainly don't know off the top of my head what a good algorithm would be to track CellML's modularity through modularless SBML, for example. But perhaps with the Hierarchical Modeling extention up and running SBML, this would become attainable? At any rate, I'd be interested in others' thoughts on this. I'm certainly not saying that translators should discard information they could have saved--the more information they save, the better. I just think there will alwaybe be information they can't save (even if it's just some proprietary annotations), and re-itegration seems like the way to go here. -Lucian ___ cellml-discussion mailing list cellml-discussion@cellml.org http://www.cellml.org/mailman/listinfo/cellml-discussion
Re: [cellml-discussion] Lucian's questions
* Catherine Lloyd [2010-02-23 22:50] writes:
> Dear Andrew
>
> I am forwarding Lucian's questions onto you in case you feel you have
> to file tracker items for any of them or need to get in touch with
> Lucian again.
>
> I am also opening it up to the discussion list in case anyone else
> would like to comment.
I can at least put the answers I got; here they are:
> Begin forwarded message:
>
> >From: Lucian Smith
> >
> >-Currently, I must run my program from the directory with the
> >'components/'
> >subdirectory. Is there a way I can set things up so I can run my
> >program
> >from anywhere?
The short answer is 'yes'; the longer answer is 'look at the OpenCell
Installer'. I may need some help here, but it's at least a start.
> >-In the model bertram_satin_pedersen_luciani_sherman_2007.cellml,
> >'lambda'
> >gets translated into infix with a '$' before it. Is this because
> >'lambda'
> >is also a function name? Does this happen with any other variables?
Yes. Any variable may be prepended with the '$'; it's *required* for any
variable that is also a reserved word. There may be a list of reserved
words somewhere; someone said they'd look into forwarding me a copy.
> >-Is there documentation about how you define your infix?
Not externally, but it's inside the help in OpenCell.
> >-If I get a 'failed to load external entity' exception, it SIGABRTs
> >me,
> >despite being supposedly wrapped in one of those 'nsresult'
> >thingummies, and
> >try/catch doesn't seem to work. What do I need to do to catch this?
> >
> >code:
> >bool Registry::LoadCellML(nsCOMPtr model)
> >{
> > if (model == NULL) return true;
> > nsresult rv;
> > nsCOMPtr
> >cevasboot(do_GetService(CEVAS_BOOTSTRAP_CONTRACTID, &rv));
> > NS_ENSURE_SUCCESS(rv, true);
> >
> > nsCOMPtr cevas;
> > try {
> > rv = cevasboot->CreateCeVASForModel(model, getter_AddRefs(cevas));
> > }
> > catch (...){
> > return true;
> > }
> >
> >
> >result:
> >I/O warning : failed to load external entity "/home/lpsmith/CellML/
> >models/.\ImportExample2.cellml"
> >terminate called after throwing an instance of
> >'iface::cellml_api::CellMLException'
> > what(): std::exception
> >
> >Program received signal SIGABRT, Aborted.
> >0xb7f5b430 in __kernel_vsyscall ()
> >
Basically, this is a bug, so I submitted a tracker item for it. Andrew
had a workaround (I believe), but I don't remember what it was; it's a
low enough priority item for me I think I'll just wait for the fix.
> >-Speaking of, the above problem was due to the imported file name
> >being
> >called ".\ImportedExample2.cellml" instead of "./
> >ImportedExample2.cellml"
> >(and me running on a unix platform). Is there a good cross-platform
> >method
> >for fixing this problem?
This turned out to also be a bug in the example CellML file (the file in
question was named 'CompletedImportExample.cellml'). I submitted a
different tracker item for that. Basically, the answer was 'use / and not
\'.
> >-Can I get a zip file of all the cellml models on cellml.org from
> >anywhere?
The short answer was "What?" and the long answer was "Um, maybe?" There
may be a script that uses mercurial that could work for this. I still
think such a zip file would be very useful for anyone who wants to
translate models or just test their own systems. Biomodels does this
(albeit with a lower number of models), and that's what I always grab when
I'm testing things. If in the future I wanted to provide Antimony
versions of CellML models, it would be great if I could update those
translations with the current versions at the repository.
One possibility would be to download the cellml files grouped by their
curation status: cellml_threestar_models.tar.gz, etc.
> >-hypertrophy_or_deterioration_parent.cellml
> >-faville_model_2008: This model is recursive. When I loop over its
> >components, some components come up multiple times, every time under
> >the
> >original name. My code then sees the same thing again, and fails.
> >How
> >would I get the *new* name for the component? Here's the current
> >code:
> >
> > while (component != NULL) {
> > numcomps++;
> > //Each CellML 'component' becomes its own Antimony 'module'
> > nsString cellmltext;
> > rv
[cellml-discussion] Modules and Components
So, my current project is to translate CellML to Antimony, and take advantage of the modularity in both. So I have a couple questions about that, first, to make sure I understand CellML modularity, and second, to ask all of you how you would expect to find CellML's modules converted. So, as I understand it, there are two ways to modularize a CellML model. You can put variables into components, and/or you can put models into files. For now, there is a 1:1 relationship between files and models--one file will contain exactly one model. One model might contain any number of components, but only one copy of each. If you want multiple copies of a module, you need to put it in another file, then import that model multiple times. There is no such thing as an imported model that is not part of the model that imports it, though it's possible to import a model and not connect it to anything, thereby creating, in effect, two separate models that are running at the same time. (Well, I guess you'd still have to connect 'time' in those models. What if you didn't?) Any aspect of an element of a model is only defined once, by design. I am not sure what happens if a variable in one component is given (say) an initial value, and another variable in a different component is given a different initial value, and then the two are connected. Is that invalid CellML? Can you only connect things that have compatible public_interface bits set? At any rate, it is at least clear that the intent is to set the public_interface parts appropriately. In Antimony, each module is distinct from the other modules, much as if they had been converted to different files in CellML--they can be imported as needed into other models, but have their own separate existence, and can function as complete models on their own. Given this, I'm inclined to convert CellML components into Antimony models, 'promoting' them. My worry is that in practice, CellML components might be pretty small, and promoting each component to a full-fledged model might not make much sense. But on the other hand, if I flatten all components to a single Antimony model, all the modularity within a model will have been lost, which also seems unfortunate. So it seems like a good question to ask the CellML community--would you rather see components fully modularized, or flattened? And going back the other way, will converting Antimony modules to CellML components be enough, or would you prefer to see them as distinct CellML files/models? (This also has ramifications in the future, when SBML gets modularity, or 'hierarchical modeling', as they're calling it, so I'm sure the issue will be raised again in the future.) Thanks! -Lucian Smith ___ cellml-discussion mailing list cellml-discussion@cellml.org http://www.cellml.org/mailman/listinfo/cellml-discussion
Re: [cellml-discussion] The CellML library basics
* Justin Marsh [2009-07-28 00:31] writes: > Hi Lucian, > > The basic C++ should have two functions for each member attribute, > named after the attribute; one with no arguments, which returns the > value of the attribute, and one with one argument which sets the value > of the attribute. > > So, to set the name you would call > model->name(L"modelname"); > And to get the name, you would call > model->name(); > > These specific functions are located in > ./sources/cellml/CellMLImplementation.cpp Thanks! Is there information like this in the documentation somewhere? I'd rather not have to bug you all every time I have a basic question like this. -Lucian ___ cellml-discussion mailing list cellml-discussion@cellml.org http://www.cellml.org/mailman/listinfo/cellml-discussion
[cellml-discussion] The CellML library basics
(Thanks for the link to the CellML2C source; that was very helpful.) (Also, I'm more than willing to move this to some other forum if it's better suited there.) So, I feel like I'm missing something pretty fundamental here, because I can't figure out how to set the name of a model. The example Java program sets the name with a 'setName' function, but this doesn't exist for the basic C++. The docs say: attribute CellMLAttributeString name The name associated with this CellML element. but trying to do (say) model->name = L"modelname"; tells me 'invalid use of member', which probably refers to the fact that model->name() is a *function* that will give me the name of the model, should it already be set. So I don't know whether the docs are out of date, or if the 'attribute' bit means something I'm unfamiliar with, or what. In other first-encounter-with-the-library news, I am sad that there is no loadFile option, just loadFromURL and createFromText. Is the standard recommendation to convert a filename to a URL, or to load the file and extract the text myself? Thanks for bearing with me through the newbie stage! -Lucian ___ cellml-discussion mailing list cellml-discussion@cellml.org http://www.cellml.org/mailman/listinfo/cellml-discussion
Re: [cellml-discussion] 'Model' has pure virtual functions
* Andrew Miller [2009-07-24 01:55] writes: > > Model is an interface, not a concrete class. The way the API works is > that you always work with interfaces, but you never directly create them > directly. Instead, you need to use one of the bootstrap methods to get > access to an interface for the first object, and then from there use the > interfaces to get to everything else you need (working with pointers). Ah, OK. That wasn't clear from the single Java example at http://cellml-api.sourceforge.net/ > See the test programs like the unit tests, and CellML2C, to get an idea > of how to call the API from C++. That'd be great--where are they? I didn't see them or references to them in the documentation. Poking around in the source directory I found tests/ but I'm not sure what I'm looking at there. -Lucian ___ cellml-discussion mailing list cellml-discussion@cellml.org http://www.cellml.org/mailman/listinfo/cellml-discussion
[cellml-discussion] 'Model' has pure virtual functions
I am just starting to use the CellML DOM API in C++, and am running into problems. Everything compiled fine (I'm using v1.6), but I seem to be unable to declare 'Model' objects because they contain pure virtual functions: This code: cellml_api::Model model; gives me the error: src/module.cpp:1570: error: cannot declare variable 'model' to be of abstract type 'iface::cellml_api::Model' /usr/local/include/IfaceCellML_APISPEC.hxx:163: note: because the following virtual functions are pure within 'iface::cellml_api::Model': /usr/local/include/Ifacexpcom.hxx:25: note: virtual void iface::XPCOM::IObject::add_ref() /usr/local/include/Ifacexpcom.hxx:26: note: virtual void iface::XPCOM::IObject::release_ref() (etc. etc.) Is there a subclass of 'Model' that I need to use instead? The example seems to just use 'Model', but it's in Java. -Lucian (Also, the 'Issue tracker' and 'Support' links on http://www.cellml.org/tools/downloads/cellml_api are broken.) (Also also, all mailman links are also broken, though mailman itself seems to be running.) ___ cellml-discussion mailing list cellml-discussion@cellml.org http://www.cellml.org/mailman/listinfo/cellml-discussion
