Chronological Thread 

< Chronological >      < Thread >

---

Dear Lucian

I'd like to start by keeping a distinction between a CellML <model>,
which I'll denote with angle brackets, and a model in the way people
use that word (which can be a very slippery and ambiguous term).

As you say, you can partition variables (and mathematics) into
components, and you can also place components (wrapped in <model>s) in
different files. In CellML, a model and a component are not equivalent
concepts - models may also encompass none, one or many unit
definitions, information on the hierarchical grouping of components,
annotations, and connections between component variables.

The question about creating two separate models in a single <model> is
interesting. I enclose a cellml file that does this. Time is not an
implicit concept in Cellml so as you will see in this <model> I have
two time variables, t1 and t2. I essentially have (in one component,
even) two models, one tracking the change in A over t1, and one
tracking B over t2.

While it is possible to do this, most models I have seen simply have
one time variable. But in CellML it is possible to have many.

As a slight tangent, as well as importing the same component to get
multiple 'copies', I do know one researcher who uses cut-n-paste to
achieve the same goal . That seems potentially bad to me, but for that
researcher there are other constraints.... my point is that there is
another possible way, even if few choose to take it (for good reason).

Connecting two variables up with different initial conditions is
something of a contradiction. Perhaps think of the <connection>
element as declaring a statement of equivalency. When time = 0, we
would be declaring that two unequal quantities are in fact equal.... I
haven't tried it but I would expect OpenCell to report that the model
is overconstrained in that case.

The question about public/private interfaces interacts with grouping
(the hierarchical component structure information which may be present
in a model). Have you seen the CellML spec?

http://www.cellml.org/specifications/cellml_1.1

Or, you can email me if you like and I will try to answer your
questions, (although I'm on leave after tomorrow morning) - sometimes
it's easier and quicker just to talk to someone :).

In my work with CellML, we have certainly gone in the 'fully
modularised' direction. One advantage is that modularised models can
be refined independently and for large systems that is desirable. It
is also possible to write a tool to 'flatten' a model should you need
it (and often they are more flexible for certain tasks when
flattened), whereas going the other way automatically might be more
tricky (although, I think, still possible if you don't mind the
potential of losing some kinds of information along the way). To some
extent, I would say it depends what you are trying to do, but the
modular approach seems more flexible to me, even if there is sometimes
extra overhead in terms of model verbosity and processing.

Finally, would you mind sending me a preprint or similar of your
Antimony paper? In theory I should have access to it, but I seem to be
having some problems with that just now, and it sounds intriguing :).


Cheers,

Mike.

Quoting Lucian Smith <lpsmith at spod-central.org>:

> 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 at cellml.org
> http://www.cellml.org/mailman/listinfo/cellml-discussion
>



----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: TwoTimer.cellml
Type: application/cellml+xml
Size: 855 bytes
Desc: not available
URL:
<http://www.cellml.org/pipermail/cellml-discussion/attachments/20090730/36d664a6/attachment.bin>

---

• [cellml-discussion] Modules and Components, Lucian Smith, 07/30/2009
  • [cellml-discussion] Modules and Components, Michael Cooling, 07/30/2009

---

Archive powered by MHonArc 2.6.18.