Chronological Thread 

< Chronological >      < Thread >

---

Hi Jonathan,

> I've recently been working on a tool to symbolically compute an analytic
> Jacobian for (parts of) cardiac electrophysiological models described in
> CellML. Those of you at the CellML workshop may remember a few slides on
> this in the Oxford talk. The tool determines the Jacobian needed for a
> Newton solve of the nonlinear system portion of a decoupled model being
> solved by backward Euler.
>
> That's the background. I'm currently pondering the best way to represent
> the output of this tool within CellML, and I think this question also has
> relevance to how CellML 1.1 models should be structured for optimal
> reusability.

I'm wondering what advantage you see putting this information into a
CellML model? isn't the representation of the Jacobian going to depend
on the integration/simulation method and/or implementation used? Or do
you imagine annotating the resultant CellML model with enough metadata
that applications could work out how to populate a Jacobian matrix for
use with their particular numerical integrator from a given set of
expressions contained in a model? In this case I can see the advantage
where your tool could then provide the analytic Jacobian formulation to
other tools which do not support the symbolic computation.

> The mathematics describing the analytic Jacobian needs access to
> potentially all the state variables in the model (and it may well need
> other variables also). However, in most models a substantial portion of
> these are defined within encapsulated components, and not visible at the
> top level of the model. Thus we cannot define a component at the top
> level to contain the Jacobian mathematics, since it is illegal to define
> connections by which it may import the variables it needs.

I would say that in this case the underlying model needs to be updated
to expose the required variables.

> It is possible to modify the model, such that all necessary variables are
> exported up the encapsulation hierarchy until they are visible. This
> approach is similar to Andre's best practices for CellML 1.1 models,
> except that the information flow is in the opposite direction: here we
> export variables up the hierarchy, whereas he suggests defining all
> parameters at the top level and exporting them downwards into
> encapsulated components where they are needed.

no, I'd suggest both ways :-)

> This would work, but it does not seem particularly clean to me. It
> requires model authors to be aware of these issues when writing models,
> for one thing. We could ameliorate this problem by writing a tool to add
> the extra variables and connections for us. However, this still makes
> the notion of encapsulation less useful, if we have to expose most of the
> encapsulated content.

but the "content" of the encapsulated components is the mathematical
representation, which is what we are trying to abstract away by
encapsulation. By not making a variable available from within an
encapsulated sub-model, the model author is specifically stating that
the variable is of no use to anyone outside the context of the given
sub-model. However, as things evolve different people will come along
and say that no longer holds true and that variable should now be
exposed. It will be up to tool developers to make that process "easy"
for model authors.

> I am uncertain as to what the best way to deal with this is, but I think
> it merits some discussion. Can we come up with a better mechanism for
> allowing limited access to encapsulated variables, in order to allow for:
> * setting parameters in imported models; and

Discussion is definitely merited :-)

The way I see it, if parameter values are not set outside the
encapsulation hierarchy of a model then it is impossible to change the
parameter values without rebuilding the hierarchy. Thus making model
reuse less useful. I would also suggest that any state variables (and
any other potentially useful variables) should be exported up the
hierarchy, otherwise there is not much use reusing the
model/sub-models/components. In all cases, model authors need to not
only carefully consider encapsulation hierarchies but also individual
variable interfaces within all components. This is kind of what I was
trying to get at with my idea of best practices at the workshop, and
when I get time I'm hoping to start writing some of this down at
cellml.org so we, as a community, can start to consider the best
approach to writing re-usable models.

It seems wrong to me to break the encapsulation rules simply to allow
variable values to be accessible without exposing the variables up or
down the encapsulation hierarchy. If you have a model and need access to
variables embedded deep in the encapsulation hierarchy it would be much
better to create a new version of that model which provides access to
such variables through the top level of the encapsulation hierarchy (and
yes, tools which do this in some kind of automated way would be very
good to have!). This would also hopefully force people to look at why
the original author kept the particular variable hidden within the
encapsulation hierarchy (which may be useful if the model had been
written with reuse in mind and the author really didn't want anyone
looking at some variable, not sure why, but I guess its possible).

> * creating a meta-component containing a Jacobian for use by solvers?

This could be one way to achieve what you're after without changing the
underlying model, although probably quite a tedious way to achieve it.
You create a new model and simply import the components which define the
mathematics and parameter values you need for the Jacobian evaluation.
You are then free to define your own encapsulation hierarchy if and as
required. You could then imagine that a simulation tool could be
configured to use one model for the rate equations and a different model
for the Jacobian evaluation. This way you would not be adding extra
mathematics to the model for simulation tools which do not use the
analytic Jacobian formulation, although I suspect Andrew's new CCGS code
would simply ignore the unused equations in this case. This approach
would still not help if the actual variable interfaces within the base
components are not suitable for reuse (i.e., public/private_interface
values of "none").

However, I think the issues you are encountering are due more to the
fact that the vast majority of CellML models currently available are
CellML 1.0 models written to be entirely self-sufficient with no thought
given to component reuse (i.e., written in a pre-1.1 world). As we move
forward, hopefully tools (and documentation?) will aid and encourage
model authors and contributors to think about reuse and model imports
etc. and the issues you are encountering will disappear. In such a
world, you'd imagine that the new model defining the Jacobian would then
simply import some kind of high level component which would provide
access to all required variables.


Andre.

---

• [cellml-discussion] Analytic Jacobians and visibility of variables, Jonathan Cooper, 05/22/2007
  • [cellml-discussion] Analytic Jacobians and visibility of variables, David Nickerson, 05/22/2007

---

Archive powered by MHonArc 2.6.18.