Hi Taishin, Firstly, I think most people on the team list are also on the cellml-discussion list so I'm dropping off the CC to the team list. Rest on my comments inline below...
Taishin Nomura wrote: > Dear all, > > We had a discussion on CellML format in response to the comment > made by Bandall. In our discussion, we tried to illustrate structure > of coupled_pendulum.cellml. We are not sure whether or not you are > interseted in this discussion. Nevertheless, we would like to make > this clear so that we can continue our effort to completely support > cellml API since we believe it has a definite meaning. > > A dominant part of the file we are going to argue may be like fig. 1 > shown temporalily at > http://www3.bpe.es.osaka-u.ac.jp/~suzuki/coupled_pendulum.pdf > This page will be closed when dicussion stops. > > The corresponding structue may roughly be represented in fig. 2 > as a schematic diagram. > > Then, possible implication of "private_interface" and "public_interface", > based on our understanding, is added to the diagram as fig. 3, > where > red lines indicate "public_interface" > and > blue lines "private_interface". > > Can we share the understanding of this diagram? yep - very nice diagrams! > Suppose yes, then we have several questions and comments. > > # On a Redundant definition of the initial value > The initial value of > <variable name="b"> at <component name="Pendulum"> > and > <variable name="b"> at <component name="PendulumLowerSegment"> > are defined redundantly as indicated by fig. 4. > Is there any reason for this redundant definition? > Please let us know. This is becuase if these two redundantly > defined initial values are not identical, it may cause a problem. definitely, as you describe the model the initial_value attribute for the b variable in the Pendulum component is not only redundant it is invalid CellML. (you can't have an initial_value if any of the interfaces is 'in'.) > Note that we are aware of the fact that > <variable name="b"> at <component name="Pendulum"> > implies > <variable name="b"> at <component name="PendulumLowerSegment"> > using <connection> property. > We are also aware of the fact that > the redundant definition of > <variable name="b"> at <component name="Pendulum"> > and > <variable name="b"> at <component name="PendulumLowerSegment"> > is natural and necessary to allow other components to utilze > <variable name="b"> of <component name="Pendulum"> which is encapsulated. yep - that all makes sense. > # Policy on location of definition of equations and initial values > For example, > <variable name="a_angular_velocity"> is defined both > in <component name="Pendulum"> > and > in <component name="PendulumUpperSegment">. > This is okay for the same reason mentined above. > However, in this case, the initial value is defined > in <component name="Pendulum">, but no definition of equations, > while > the equation is defined in <component name="PendulumUpperSegment">, > but no definition of the initial value. I think you have name="Pendulum" and name="PendulumUpperSegment" swapped around, but again this is invalid CellML. Since variable a_angular_velocity (and also b_angular_velocity) has a private interface of 'in', it is invalid to define the differential equation d(a_angular_velocity)/dt in the Pendulum component. > Regarding this sort of distributed definitions of properties of > an object, we would like to know your policy. Of course, > the current situation is fairly lax and the user can define a property > anywhere within an encapsuled component, even in a component > in the encapsulated component. However, it could be a source of > errors if we have to deal with a complicated model with many > properties and components. I think this is because the model you are describing is invalid. This kind of distributed definition of properties is invalid CellML (as far as I can tell). Only the component which "owns" a variable (i.e., the component in which the variable is defined with no interface of "in") is allowed to alter the variable's value - either with an initial_value or some mathematical equation. > # An alternative way to describe the pendulum (A proposal) > Fig. 5 is an alternative structure to describe the pendulum. > It seems that this is natural in the following sense: > every <variable> such as > <variable name="a_angular_velocity"> > or > <variable name="b_angular_velocity"> > has both the initial value and the equation together. > Then, the encapsulted <component name="Pendulum"> plays a > simple role to put > <component name="PendulumUpperSegment"> > and > <component name="PendulumLowerSegment"> > together within a single component. > > There may be other kinds of structure such as a case > illustrated in Fig. 6. Both of these look correct to me, although the one in Fig. 5 seems more natural to me :-) Looking back, I see this is the PCEnv test model that Randall mentioned a while back. And looking at that original code it certainly looks like an invalid model to me...and passing it through Jonathan's validator (https://chaste.ediamond.ox.ac.uk/cellml/) that seems to agree with me... Hope that helps clear things up, David. _______________________________________________ cellml-discussion mailing list [email protected] http://www.cellml.org/mailman/listinfo/cellml-discussion
