CellML Discussion List

Text archives Help


[cellml-discussion] Analytic Jacobians and visibility of variables


Chronological Thread 
  • From: jonathan.cooper at comlab.ox.ac.uk (Jonathan Cooper)
  • Subject: [cellml-discussion] Analytic Jacobians and visibility of variables
  • Date: Mon, 21 May 2007 13:53:32 +0100

Hello all,

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.

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.

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.

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.

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
* creating a meta-component containing a Jacobian for use by solvers?

Any suggestions?

Jonathan.

--
Jonathan Cooper MSN: msn at jonc.me.uk www: jonc.me.uk/

Remember - a photon is for life, not just for Christmas




Archive powered by MHonArc 2.6.18.

Top of page