Chronological Thread 

< Chronological >      < Thread >

---

Michael Cooling wrote:
>> because if connections don't have directionality, then it makes no
>> sense in the language to say
>> that a connection is from A to B, as opposed to from B to A, and we
>> wouldn't want to force users to duplicate information and provide both
>>
>
> Oops I didn't mean to imply directionality. I shouldn't have used the
> words 'from' and 'to', sorry. It's not the language that I want to
> change.
>
>
>> I'm not sure what you mean there. In CellML 1.1, there can be attributes
>> like public_interface="in" private_interface="out", I have used
>> something more like public_interface="yes" or public_interface="no"
>> here, thereby removing the directionality - in and out correspond to
>> yes, none corresponds to no.
>>
>
> Ah I see. I suspect just having an optional public_interface="yes"
> would be the way to go, private="yes" being always
> implicit. I.e. private by default, and public includes private. As you
> say this will no doubt be discussed later.
>

This particular aspect has already been discussed. See
http://www.cellml.org/pipermail/cellml-discussion/2008-January/001144.html
and the follow on discussion for why public and private interfaces are
not analogous to public and private in most object orientated
programming languages, and why public does not imply private.

By default, we have public_interface="no" private_interface="no", which
means that the variable cannot be used outside of the component.
public_interface="yes" means that encapsulating components can connect
to the variable, while private_interface="yes" means that encapsulated
components can connect to the variable.

>
>> The mathematical model you get from this would be sub-optimal without
>> some intelligence on the part of software tools - there would be two
>> state variables with identical rates and initial values for the
>> concentration of b and the concentration of y
>>
>
> This is why I am wary of such convenience components....they imply an
> interface that doesn't really exist - I think they can be useful but
> since one never
> knows what might get connected to what....
>

Removing directionality, and using sets for the list of all fluxes mean
that it doesn't matter what the flux set is connected to behind the
interface. The duplication of state variables is unfortunate, but it
doesn't actually have any theoretical implications for the correctness
of the model, if both state variables have the same initial values and
rates (which they would, since they are the sum over the same set of
fluxes). This means that the model should just work in all cases.

> If one tries to use them as an interface to the system that MUST be
> used (not that you were doing this)
> then you limit the usefulness of your model...essentially you are
> assuming that your interface is sufficient for all future
> requirements.

Yes, and that is a good assumption if you provide everything on the
interface.

> Even for ion channels, that might not be true in the future.
> I think duplications may also be resolved by chosing a particular
> substance_b
> (ie human decision) at model aggregation-time facilitated by tools
> identifying this situation.
>

I don't think we want to do that manually. The duplication is only a
problem because it artificially inflates the dimensionality of the
model, creating a performance problem, and the algorithm to detect this
artificial inflation of dimensionality and merge the state variables for
computational purposes should be tractable if we limit it to the case
where identical variables are being put through an identical equations,
rather than going for a more general and costly isomorphic mathematical
structure detection.

Best regards,
Andrew

---

• [cellml-discussion] Using proposed CellML 1.2 features to create more re-usable metabolic models, Andrew Miller, 01/30/2008
  • [cellml-discussion] Using proposed CellML 1.2 features to create more re-usable metabolic models, Michael Cooling, 01/31/2008
    • [cellml-discussion] Using proposed CellML 1.2 features to create more re-usable metabolic models, Andrew Miller, 01/31/2008
      • [cellml-discussion] Using proposed CellML 1.2 features to create more re-usable metabolic models, Michael Cooling, 01/31/2008
        • [cellml-discussion] Using proposed CellML 1.2 features to create more re-usable metabolic models, Andrew Miller, 01/31/2008
          • [cellml-discussion] Using proposed CellML 1.2 features to create more re-usable metabolic models, Michael Cooling, 01/31/2008
            • [cellml-discussion] Using proposed CellML 1.2 features to create more re-usable metabolic models, Andrew Miller, 01/31/2008
            • [cellml-discussion] Using proposed CellML 1.2 features to create more re-usable metabolic models, Michael Cooling, 01/31/2008
  • [cellml-discussion] Using proposed CellML 1.2 features to createmore re-usable metabolic models, David Nickerson, 01/31/2008
    • [cellml-discussion] Using proposed CellML 1.2 features to createmore re-usable metabolic models, Andrew Miller, 01/31/2008

---

Archive powered by MHonArc 2.6.18.