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: j.marsh at auckland.ac.nz (Justin Marsh)
  • Subject: [cellml-discussion] A list of proposed changes to semantics to makein CellML 1.2
  • Date: Mon, 24 Dec 2007 16:08:40 +1300
Hi all,
I hope that I haven't missed the point of bidirectionality,
but the way it is suggested seems not to be a declarative way to
do things.

As far as I can tell, in a procedural language it makes sense
to modify variables in multiple locations, as application is
essentially sequential; the seperation between 'big ticks'
and 'little ticks' allows one to flatten the calculation for
each time step. In a declarative language however,
there is essentially no application; this means that we want
to group every part of a definition of something together.
When we want to have parts of the definition of a thing in several places,
the thing becomes that which explicitly joins together the
definitions into one definition, via mappings and maths.

In a declarative language, this should not explicitly be done by order;
explicit grouping is accomplished by containment, or something like
tagging, which is just a flattened form of containment.

The 'in' and 'out' interface values are a form of tagging, specifying
that the 'out' version of the variable is where its definition is grouped,
with all of the 'in' versions using that definition to
specify other definitions.

The purpose that I see bidirectionality being put to is to allow
for a certain kind of notational laziness, two cases of which stand out.

The first is the variable forwarding case, which is not terribly
problematic. It could be unambiguously
resolved by explicitly separating the 'in' variable from the 'out'
variable, for instance.

Suppose we have encapsulated components like so:

A
|
B
/ \
C D

We wish to forward variable v through component B.
What we can do is have a variable v_in, mapped to variable v
in component A, and a variable v_out, which is set equal
to v_in in the Maths element of component B. The variable
v_out can then be mapped to v in both C and D without
ambiguity. This is a rather longhand way of doing this,
but it could be done automatically fairly easily.

The second case that springs to mind is where someone
implicitly uses a procedural methodology in their model.
For example, suppose you have a variable in a component,
and that variable represented the level of a particular
compound that was metabolised in the body. It may be
necessary to add a stimulus protocol in order to get
oscillation, and it may be desirous for the stimulus protocol to
be in a separate component; to do that in a procedural language one
would simply
perturb the value of the variable at particular time points, by
effectively having the variable sometimes have an 'in'
interface and sometimes have an 'out' interface.
A declarative way of doing this would be to create a variable
defined by a piecewise equation within a separate
stimulus protocol component, map that variable onto a variable
in the compound component, and add the stimulus protocol variable into
the maths that defines the levels of the compound; this is how
these models are currently built.

Best regards,
Justin.



Quoting Andrew Miller <ak.miller at auckland.ac.nz>:

> 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".
>
> I think we also need "both" for the forwarding case if we were going to
> take this approach.
>
> This is a pretty fundamental change
>> to the specification but I think that it better reflects the
>> declarative intent of CellML model descriptions.
>
> I think that if we want the bulk of valid CellML 1.1 models to be valid
> CellML 1.2 models, we would need to at least keep the directionality as
> an option, even if it carries information which is not meaningful in
> CellML 1.2. This would mean 1.2 software could process most 1.1 models
> without having to implement the two specifications separately, which is
> probably a good goal to have.
>
> I think that it all depends on how much we are prepared to change the
> specification for CellML 1.2 - I have so far been aiming to get forwards
> and backwards compatibility unless the model actually uses some feature
> available in one version that isn't in another.
>
> Best regards,
> Andrew
>
>>
>> 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
>>
>> _______________________________________________
>> 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
>



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



Archive powered by MHonArc 2.6.18.

Top of page