First login?
Lost password?
 
 
cellml-discussion AT lists.cellml.org 
CellML Discussion List

Text archives Help


[cellml-discussion] A list of proposed changes to semantics to makein CellML 1.2


Chronological Thread 
  • From: jonathan.cooper at comlab.ox.ac.uk (Jonathan Cooper)
  • Subject: [cellml-discussion] A list of proposed changes to semantics to makein CellML 1.2
  • Date: Sat, 22 Dec 2007 07:21:33 +0000
On Sat, Dec 22, 2007 at 11:19:52AM +1300, Poul Nielsen wrote:
> I think that Jonathan is correct - the concept of 'in' and 'out'
> does not make sense in a declarative description. One way to remedy
> this would be to remove the 'public_interface' and
> 'private_interface' attributes from the <variable> element and
> replace them with an 'interface' attribute which could assume values
> "public", "private", or "none". This is a pretty fundamental change
> to the specification but I think that it better reflects the
> declarative intent of CellML model descriptions.

How would that work for a component like B below, which has both a public
and private interface for the same variable?

Jonathan.


> On 2007 Dec 22, at 03:20, Jonathan Cooper wrote:
>
> > On Thu, Dec 20, 2007 at 12:30:32AM +0800, David Nickerson wrote:
> >>> * The current specification says:
> >>> "A variable with either a private_interface or public_interface
> >>> attribute
> >>> value of "in" must be mapped to no more than one other
> >>> variable in the
> >>> model. [ Note that a similar restriction does not apply to
> >>> variables with
> >>> interface values of "out". An output variable can be mapped to
> >>> multiple
> >>> input variables in various components in the current model. ]"
> >>>
> >>> The problem with this is that it doesn't properly account for
> >>> mappings where a variable is forwarded into an encapsulated
> >>> block. As
> >>> an example, consider the following encapsulation hierarchy (higher
> >>> components encapsulate lower ones)...
> >>>
> >>> A
> >>> |
> >>> B
> >>> / \
> >>> C D
> >>>
> >>> Suppose that component A has, for variable v,
> >>> public_interface="none", private_interface="out", and B has for
> >>> variable v, public_interface="in", private_interface="out"
> >>> (connected to A), and C and D have public_interface="in",
> >>> private_interface="none", both of which are connected to B.
> >>>
> >>> There is no reason why this should not be valid. However, the
> >>> specification contradicts itself on whether this is allowed. On
> >>> one
> >>> hand, because B has private_interface="out", it "can be mapped to
> >>> multiple input variables in various components in the current
> >>> model.", but because it has a public interface of in, it "must be
> >>> mapped to no more than one other variable in the model".
> >>>
> >>> This can be fixed by firstly defining the interpretation of
> >>> connections and interfaces, and then adding constraints based on
> >>> that which actually describe which connections are allowed to each
> >>> set of variables.
> >>
> >> will be interesting to see how such a definition ties in with the
> >> idea
> >> of input variables becoming output variables based on the way the
> >> components are hooked together :)
> >
> > Indeed.
> >
> > The use of "in" and "out" on interfaces very strongly implies that
> > connections have a directionality, and this is also reflected in the
> > quote from the specification above - it assumes that variables are
> > only
> > defined in one place, and hence it doesn't make sense to import a
> > variable (via an "in" interface) from multiple locations. It does
> > however make sense to export a variable to multiple locations, or
> > forward
> > an imported variable to multiple locations (the example Andrew gives).
> >
> > If we don't want connections to have directionality, then I think this
> > requires quite a major change in the specification, even if only to
> > avoid
> > user confusion. For example, I would want to deprecate the use of
> > "in"
> > and "out", and instead allow public_interface="yes" or
> > public_interface="no" (perhaps a synonym for "none") and similarly for
> > private interfaces. The terms used in the language then reflect the
> > nature of the interfaces - if connections are bidirectional, then it
> > doesn't make sense to talk of an "in" interface, since it may function
> > either as input or output depending on the other components in the
> > system.
> >
> > Jonathan.
> >
> > --
> > Jonathan Cooper MSN: msn at jonc.me.uk www: jonc.me.uk/
> >
> > We are tribbles of Borg. Prepare to be replicated.
> > _______________________________________________
> > 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

--
Jonathan Cooper MSN: msn at jonc.me.uk www: jonc.me.uk/

I haven't lost my mind... It's backed up on tape somewhere.


Archive powered by MHonArc 2.6.18.

Top of page