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 mailing list [email protected] http://www.cellml.org/mailman/listinfo/cellml-discussion
