excellent, thanks for the explanations Andrew - it all makes sense now :-)
Andre. Andrew Miller wrote: > 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 > cellml-discussion@cellml.org > http://www.cellml.org/mailman/listinfo/cellml-discussion -- David Nickerson, PhD Research Fellow Division of Bioengineering Faculty of Engineering National University of Singapore Email: [EMAIL PROTECTED] _______________________________________________ cellml-discussion mailing list cellml-discussion@cellml.org http://www.cellml.org/mailman/listinfo/cellml-discussion
