Re: Proposed backward-incompatible changes totheCCGS.

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-+N4dcC6UsuQdnm+yROfE0A@xxxxxxxxxxxxxxxx
> http://www.cellml.org/mailman/listinfo/cellml-discussion

-- 
David Nickerson, PhD
Research Fellow
Division of Bioengineering
Faculty of Engineering
National University of Singapore
Email: david.nickerson-6Bl98Hp8bEiLvajZxc+D7Q@xxxxxxxxxxxxxxxx