Re: [cellml-discussion] ABI CellML Meeting Minutes, 21st April 2010
Hi Alan, - I have already exceeded the two weeks you spent on the Qt/C++ prototype; I have spent two and a bit weeks on code, and just under two weeks on trivial problems with tool configuration, dependency management, libraries and external components etc, and things unrelated to the prototype. I actually found learning Scala easier than learning the various giant Java libraries. - I have not put up a binary version anywhere; I will in the next few days. - The source code is available at http://github.com/flaviusb/sOC/ It can be cloned by git clone http://github.com/flaviusb/sOC.git or svn checkout http://svn.github.com/flaviusb/sOC.git - In the case of the demo I was writing, the DSL in question was a toy to try to learn a few Scala language features; in function, it was simply a way to make menu item layout faster and less crufty than it usually is under SWT. An example of use can be found here: http://github.com/flaviusb/sOC/blob/master/src/soc/ApplicationActionBarAdvisor.scala#L81 Writing a tiny DSL is a common pattern in Scala GUI code; I had seen them for other things, but not using the particular approach of case classes and implicit functions, and not for menu layout. They usually seemed to use Functors or trait classes and plain functions. - I have not done development for the prototype outside of Linux. Dependency management under Eclipse can be done in several ways; supposedly using Maven2 or Ant and the respective plugins for Eclipse is totally cross platform, but setting up Maven2 or Ant configuration files is quite time consuming, especially as the dependant projects (jeuclid and JFreechart) do not seem to have valid Ant or Maven2 configuration files. For the purpose of the demo, I chose to do this in the 'Eclipse' way, which it turns out is not really friendly with source control. Importing a project with dependencies into an Eclipse workspace does not work nicely unless you either use Maven2 or Ant, or bundle *all* of the jars under your project, or have *all* of the jars have the same *absolute* path under all machines, or already have 'projects' in that workspace that deal with this in one of the ways above which your project is dependant upon; the 'cascading project' pattern is quite common, but would require putting the entire thing under version control. I am sure there is another way that is actually workable (or that the Ant or Maven2 way is workable) that I just do not know, but I have already exceeded a reasonable fraction of the total time I had available on this particular problem. If we do go ahead with using Scala, setting up a dependency handling system so that this is not something anyone has to deal with again will be one of the first things I want to do, as otherwise this system fails at one of our hard requirements (that is, that other people can build and develop for OpenCell 'easily'). Ideally, one should be able to build it with just the jdk, a scala compiler, and something like Ant or Maven2. - A vanilla Scala application is trivial to deploy; there is a particular jar you can bundle your application with that allows it to run under the jvm. This bundle has no native components. Eclipse RCP applications require a few more platform specific jars bundled with them to run under the respective jvms, but there is a specific archive available from eclipse.org (the Eclipse Delta pack) which you just need to take the jars from. I have not attempted to create a 'launcher' (which is Eclipse speak for something that looks like a native application) on any platform other than Linux; it worked under Linux at the push of a button in Eclipse. I am currently working on a solution that will work from the command line. - I did not know Scala before I started this demo. I supported the choice to use it as it was the only non-Java JVM language where it both seemed to be acceptable for what we needed, and it seemed to be possible to convince more than just myself and Andrew that it was a workable solution. I did not see any possibility of making a good enough case for Clojure or Rhino for example, even though I believed them to be better solutions, and was actually familiar with them already. The point of having me rather than Andrew write the demo was to show that someone with no familiarity with the language or tools could get to the point of making contributions pretty quickly; if that were not true, then no matter how awesome the language or tools were, they would fail one of the hard requirements we have. Best Regards, Justin. Alan Garny wrote: Regarding "5) OpenCell development - update" and Justin's Scale work in particular: - How much time has been spent on this so far? - Where can one get a binary version of the demo for Windows, Linux and Mac OS X? - What are internal DSLs? - Where can one get the source code? (Incidentally, I really wish it had been regularly committed to the OpenCell repository for peop
Re: [cellml-discussion] ABI CellML Meeting Minutes, 21st April 2010
Andrew pointed out some time ago that even if consistent IC's are provided by the model author, one of the things we often do with models is change some of the parameters, or re-use the models in a different context, in which case some assistance from the software in recalculating new consistent IC's is invaluable. Regards, Randall > -Original Message- > From: cellml-discussion-boun...@cellml.org [mailto:cellml-discussion- > boun...@cellml.org] On Behalf Of Alan Garny > Sent: Friday, 23 April 2010 11:43 p.m. > To: 'CellML Discussion List' > Subject: Re: [cellml-discussion] ABI CellML Meeting Minutes, 21st April 2010 > > But aren't or, rather, shouldn't ICs be provided by the model developer? Or > is it the case that you want to be able to determine the ICs, should the > model developer not have provided some? Then again, if no ICs have been > provided, then this would be a shortcoming of the model, and rather than > trying to determine some ICs, we should try to get the ICs from the model > author. Just thinking 'aloud', so sorry if I am missing something obvious > here (not least because I have never 'played' with DAEs myself). > > Alan > > > -Original Message- > > From: cellml-discussion-boun...@cellml.org [mailto:cellml-discussion- > > boun...@cellml.org] On Behalf Of Randall Britten > > Sent: 23 April 2010 12:35 > > To: CellML Discussion List > > Subject: Re: [cellml-discussion] ABI CellML Meeting Minutes, 21st April > 2010 > > > > DAEs are a little more complex, it isn't always obvious which unknowns > > require initial conditions, or how to ensure ICs are consistent. > > > > Regards, > > Randall > > > > On 23/04/2010, at 8:50 PM, "Alan Garny" > > wrote: > > > > > Sorry, one more (non-OpenCell) comment: > > > - "... the biggest problem is using IDA's default solver for initial > > > conditions..." -- What is exactly meant by solver for initial > > > conditions? Do you mean that you are trying to use IDA to determine > > > what the initial value of the state variables should (i.e. like those > > > 99 guesses in the original OpenCell DAE solver?)? I would think/hope > > > not (I thought we had 'agreed' to provide the initial conditions to > > > the solver?). > > > > > > Alan > > > > > >> -Original Message- > > >> From: cellml-discussion-boun...@cellml.org [mailto:cellml-discussion- > > >> boun...@cellml.org] On Behalf Of Dougal Cowan > > >> Sent: 22 April 2010 21:19 > > >> To: CellML Discussion List > > >> Subject: [cellml-discussion] ABI CellML Meeting Minutes, 21st April > > >> 2010 > > >> > > >> I have put the minutes from this week's meeting up at: > > >> > > >> http://www.cellml.org/community/meeting/minutes/2010/04.21 > > >> > > >> Thanks, > > >> Dougal > > >> > > >> ___ > > >> cellml-discussion mailing list > > >> cellml-discussion@cellml.org > > >> http://www.cellml.org/mailman/listinfo/cellml-discussion > > > > > > ___ > > > cellml-discussion mailing list > > > cellml-discussion@cellml.org > > > http://www.cellml.org/mailman/listinfo/cellml-discussion > > ___ > > cellml-discussion mailing list > > cellml-discussion@cellml.org > > http://www.cellml.org/mailman/listinfo/cellml-discussion > > ___ > 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
Re: [cellml-discussion] CellML models in Antimony format
A stellar effort Lucian - congratulations! little-used CellML constructs such as partial differential equations or rates of change with respect to some non-time variable Yes - these are a legacy of coding up models in a text editor without any way of testing them! Partial diffs can be coded up in CellML but there are no existing tools which will recognise them. There shouldn't be anymore PDE models added to the repository, I believe they fall under the FieldML domain. But I am happy to be corrected if I am wrong! Best wishes Catherine On 24/04/2010, at 12:04 PM, Lucian Smith wrote: 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 ___ cellml-discussion mailing list cellml-discussion@cellml.org http://www.cellml.org/mailman/listinfo/cellml-discussion
