David Nickerson wrote: > Hi Andrew, > > I think the advantages offered by this transition outweigh the lack of > backwards compatibility and have no objections to your proposal, just a > few clarifications below... > > >> I am planning on completely updating the CCGS to make use of CeVAS, >> MaLaES, and CUSES. Due to the large scale of the changes, I am taking >> this opportunity to fix some design issues which currently limit what >> CCGS can do. This inevitably means breaking the existing interface, and >> any code that uses it (I could have tried to make the interfaces look >> the same, but the code generated would still be different, due to the >> changes discussed below). >> >> Major changes proposed: >> * The concept of variables and rates in CCGS is being replaced by a >> concept of a computation target. A computation target is anything which >> can be computed by CCGS, and includes variables and rates (possibly >> multiple times). >> > > I'm not sure I follow how variable's are linked to a ComputationTarget. > You say that a given variable may be associated with multiple > computable's - does this mean there are possibly multiple methods to > compute the same variable or will all the ComputationTarget's for a > given variable resolve to the same computational steps? > Hi Andre,
'Computing a variable' no longer has much meaning, because there can be more than one thing which you need to compute (multiple derivatives of the same variable). For example, if you have an equation like d^3(x)/dt^3 = t in the CellML, then what actually gets computed is: 1. The rate d^3(x)/dt^3 2. The rate d^2(x) / dt^2 (copied from the state variable for 1 above). 3. The rate d(x)/dt (copied from the state variable for 2 above). All three rates are separate computation targets associated with variable x, and all three get computed (there is no choice between them). They do not 'resolve to the same computational step' in the sense that they could be computed in different places in the generated code. However, the order chosen will always ensure that rates or variables are computed prior to being used to compute another rate or variable. > >> * There will no longer be separate blocks of code which explicitly >> compute rates and blocks which explicitly compute variables. Instead, >> computation targets are computed, and as a side effect of this, any >> other algebraic or rate variable may be computed as a pre-requisite. One >> positive result of this is that it will be possible to use derivatives >> like any other variable, so the same derivative can appear more than >> once, and derivatives can even be solved by Newton-Raphson steps if >> required. It means that it is possible to efficient code which evolves >> the model without computing unnecessary variables until they are needed >> for presentation purposes. This completely changes the structure of the >> strings produced, causing backward-incompatibility. >> > > Could you clarify what you mean by "presentation purposes"? > Perhaps 'presentation purposes' is not the best phrase, because obviously it might be used for further non-CellML computations rather than presentation to the user. The point is that the blocks of code generated will be split up differently. One block of code will compute how to initialise constants, another will compute the rates and the minimum other variables needed to compute the rates, and the third will compute all remaining variables. The third block does not need to be run at every integration step unless you have a compelling reason to know the values of the variables computed in it (e.g. to present them to the user, or to allow for further use of these values). This makes it possible to have lots of extra variables which just give you some more useful interpretation of the model but don't actually affect the evolution of the state variables, without worrying that they will slow the algorithm when they aren't needed (the current code does have something similar which was hacked in using pre-processor macros in the generated code, to avoid breaking backwards compatibility, but that solution is not sustainable especially for languages without pre-processors, and the new split is much cleaner). > >> * The idea that a rate is a constant is contemplated, allowing for more >> efficient computation. >> > > Is this looking at the math defining a rate and checking if it would > remain constant after all the other math has been processed? > Yes. The current code allows for variables to be 'computed constants', but not rates. The new code gives rates equivalent status to variables, so they can also be computed only once if that is required. Some integrators might require that the rates array be backed up and copied to support this (because in reality, there is more than one rates array internal to the integrator), but a copy is still better than performing complex computations which are not necessary at every step (of course, it is not clear that such rates are very common in real models, but I think it makes sense to put all computation targets into the same general framework, so any future optimisations which might be more useful also can be used). In the future, for example, this could be used as part of a partial evaluation framework, or perhaps models could be split into non-coupled components, allowing larger models to be more efficiently evaluated, and perhaps some parts being evaluated analytically. Best regards, Andrew _______________________________________________ cellml-discussion mailing list [email protected] http://www.cellml.org/mailman/listinfo/cellml-discussion
