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: p.nielsen at auckland.ac.nz (Poul Nielsen)
  • Subject: [cellml-discussion] A list of proposed changes to semantics to makein CellML 1.2
  • Date: Sat, 22 Dec 2007 11:19:52 +1300
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.

Best wishes
Poul

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



Archive powered by MHonArc 2.6.18.

Top of page