Chronological Thread 

< Chronological >      < Thread >

---

this is starting to get complicated :)

I have typically been treating my components and models as "complete"
pieces which I connect into various configurations for different
purposes. In such an approach, I use the variable interfaces to
essentially define an internal API for the components and then use
encapsulation to provide a single external API for useful model
hierarchies. I guess this is very much a procedural approach to using
CellML.

What you are talking about is more a declarative approach, and you're
right - that makes for much more reusable and extendable components and
model hierarchies.

So perhaps the way that I need to start thinking about the interfaces is
that they are simply hints at the original author's intent for the use
of the component - but that is no reason to stop future users of the
component changing an input to an output variable, especially given we
now have the CCGS being capable of working out, at the simulation
instantiation stage, which are which in the context of the entire model.
The special hint of "none" is then simply an indication that the
variable is used outside the component at the users risk with undefined
behaviour?

I think you are starting to convince me that your original proposal is
the right way to be going...but more thought is definitely required :)


Andre.


Andrew Miller wrote:
> David Nickerson wrote:
>> The good thing about the existing rules is that you can see from the
>> variable interfaces for a given component what needs to be defined
>> externally and what may be used externally. While I can see your point
>> about the way mathematical expressions could end up modifying different
>> variables depending on how the entire model is defined, I'm not sure
>> that we want to start allowing variables with an interface off "in" to
>> be modified in any way.
>>
>> I guess I'd prefer a set of rules that somehow flag "in" variables as
>> constant within that component. If execution of the math in a particular
>> instantiation of the component would result in any such constants having
>> their value changed then that should be treated as an error.
>
> This would severely limit the re-usability of CellML components /
> imports, because it means that you have to decide ahead of time which
> variables are going to be used in which way, and if you then tried to
> use it in a different context for a different purpose, you would
> potentially end up changing something from an input to an output.
>
> If major recoding of a model is required to make minor changes to how
> the some mathematics are used, this does not fit well with the model
> sharing and reuse goals underlying the CellML project.
>
> Perhaps you could explain the reasons behind why you don't think we
> should allow this type of use case?
>
>> Essentially
>> what the current rules state, but perhaps not quite the way the rules
>> are being enforced in the CCGS?
>>
> I don't know if anyone has correctly enforced these rules - I have heard
> that COR simply expects that variable to be the second child element in
> the MathML apply element that is the child of the math element, which is
> rather arbitrary as the equations could be re-arranged and they would no
> longer pass this validation stage (perhaps Alan could confirm or correct
> this?).
>
>> If we were to remove such rules, is there any need for the public and
>> private interfaces at all?
>>
> We don't want to expose all variables, because some are intended to be
> component-local.
>
> We could have used a 'true' / 'false' type undirected system in which
> variables are either exposed or hidden on each interface. However,
> changing this now would create 100% forwards and backwards
> incompatibility both theoretically and with the actual software
> implementations available, as opposed to having a few models with
> theoretical 1.1-1.2 forwards compatibility issues that work in practice
> in all current software which such models needing minimisation steps
> would work in anyway.
>
> Best regards,
> Andrew
>> Andre.
>>
>>
>> Andrew Miller wrote:
>>
>>> Hi all,
>>>
>>> The current (CellML 1.1) specification has some wording like the
>>> following:
>>>
>>> ''The variable must also be declared in these components, which can then
>>> use the value of the variable in their own equations but must not modify
>>> it." (3.2.3)
>>>
>>>
>>> "
>>> 4.4.4
>>>
>>> * A mathematical expression defined using MathML must only modify
>>> the values of variables that belong to the current component.
>>> [ Variables that belong to a component are those that are not
>>> declared with a |public_interface| or |private_interface|
>>> attribute value of |"||in||"|. ]
>>>
>>> "
>>>
>>> It doesn't really make a lot of sense to talk about a mathematical
>>> expression modifying a variable, because an equation really only
>>> describes the relationships between variables, and doesn't specify which
>>> variable is to be modified. At least in the current CCGS implementation,
>>> exactly how an equation is used will vary depending on what other
>>> components are connected to a given component, and so it is possible
>>> that the rules would sometimes be met depending on what is connected to
>>> a particular component, which is obviously not a robust way to develop a
>>> model.
>>>
>>> I suggest that this requirement be dropped in the next version of CellML
>>> (I am also making a list of other changes from 1.1 I am proposing, which
>>> I will send to the mailing list when it is completed).
>>>
>>> Best regards,
>>> Andrew
>>>
>>> _______________________________________________
>>> 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

--
David Nickerson, PhD
Research Fellow
Division of Bioengineering
Faculty of Engineering
National University of Singapore
Email: david.nickerson at nus.edu.sg

---

• [cellml-discussion] 'Modification' of variables, Andrew Miller, 12/19/2007
  • [cellml-discussion] 'Modification' of variables, David Nickerson, 12/19/2007
    • [cellml-discussion] 'Modification' of variables, Andrew Miller, 12/19/2007
      • [cellml-discussion] 'Modification' of variables, David Nickerson, 12/19/2007
      • [cellml-discussion] 'Modification' of variables, Alan Garny, 12/20/2007

---

Archive powered by MHonArc 2.6.18.