Chronological Thread 

< Chronological >      < Thread >

---

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. Essentially
what the current rules state, but perhaps not quite the way the rules
are being enforced in the CCGS?

If we were to remove such rules, is there any need for the public and
private interfaces at all?


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

--
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.