Chronological Thread 

< Chronological >      < Thread >

---

After much reading of the spec and drawing diagrams, I finally solved the
problem of how to connect two variables which might be in disparate
components. In the hopes that my solution might be helpful to others,
and/or might make for some helpful documentation some day, I'll summarize
my findings:

There are three ways to connect variables in adjoining modules, which I
call 'up', 'down', and 'sideways'. The first two are parent-child
connections: when you're connecting 'up', the canonical version of the
variable can be found in the parent, and when you're connecting 'down' the
canonical version of the variable can be found in the child. You can also
connect variables in sibling components; this is the 'sideways'
connection.

The canonical version must have the appropriate interface set 'out', and
the non-canonical version must have the appropriate interface set 'in'.
Which interface that is, is different for the three scenarios:

UP: The variable in the child component must have a public interface of
'in', and the variable in the parent component must have a private
interface of 'out'.

DOWN: The child variable must have a public interface of 'out', and the
parent variable must have a private interface of 'in'.

SIDEWAYS: Both variables must have a public interface set: the canonical
with 'public: out' and the non-canonical with 'public:in'.


If you have widely-separated components that use the same variable in an
equation or two, you must trace out a path between those components,
putting the variable in the interstitial components as needed, and
connecting them with 'up', 'down', and 'sideways' connections. This can
seem daunting, but it turns out there is a relatively straightforward
algorithm than can get you from one to the other:

First, find the series of encapsulation parents of the canonical variable.
If the variable you wish to connect to it is in one of these parents,
connect 'down', either to the canonical variable or to the child in this
chain. If doing this doesn't connect directly to the canonical variable,
recursively call this algorithm again on the target.

If we are not connecting down, check instead if the parent of the
component is in the list of encapsulation parents. If it is, connect
'sideways', either to the canonical variable or to the sibling in the
parent chain. If the latter, recursively call the algorithm again on the
target.

In all other cases, connect 'up'. Call recursively on the target if you
haven't connected to the canonical variable yet.


There is a slight complication in that if you have some variables that are
already connected, you must connect to those variables before creating a
new one.

And that's it!



Now, as far as 1.3 suggestions: I know that it is already proposed to
abandon the 'in' vs. 'out' aspects of connections, and I heartily support
this idea. I also think the 'sideways' connections are the odd man out in
the current scheme; I think it would harm nothing if they were discarded
for all but top-level components. You could also abandon the whole
private vs. public interface thing: every variable would either have a
public interface or it wouldn't, and you could connect one of your
variables to a variable in a child component with a public interface and
that's it. The only exception would be that one top-level component could
connect one of its variables to another top-level component's variable
with a public interface.

You could even get rid of these now-vestigal 'sideways' connections by
declaring that every CellML file must have exactly one component with no
parent, or possibly by declaring that encapsulation trees could not
connect to 'parallel' encapsulation trees (continuing to allow one to
encode multiple models in a single CellML file).

It would also be nice if you dropped the restriction that a varible's
intial value and rate of change be defined in the same component. This
would allow people to define models where the intial values might be all
collected and defined in a single component, with the rates of change
scattered throughout the model.

There should be some way to 'import' a component that was defined in the
current file. The current need to copy and paste and/or define in a new
file (which is much more easily separated from the existing file) is, I
think, counterproductive.


Finally, I noticed in the minutes that you all are planning to move some
of the features of OpenCell into the API: the one such feature I would
want in the API is the infix to MathML translation abilities.

-Lucian

---

• [cellml-dev] Connections and v1.3 suggestions, Lucian Smith, 08/10/2010
  • [cellml-dev] Connections and v1.3 suggestions, David Nickerson, 08/10/2010
  • [cellml-dev] Connections and v1.3 suggestions, Jonathan Cooper, 08/10/2010

---

Archive powered by MHonArc 2.6.18.