Use more sympy features to optimise/improve generated code

[jonc125]

Picking up from the discussion in #190. Look into things like:

• https://docs.sympy.org/1.5.1/modules/rewriting.html#common-subexpression-detection-and-collection
• https://docs.sympy.org/1.5.1/modules/codegen.html#module-sympy.codegen.cfunctions for things like log to base 10 (update transpiler)
• https://docs.sympy.org/1.5.1/modules/codegen.html#module-sympy.codegen.rewriting - automatically using 'c' math functions to optimise numeric edge cases like expm1

[MauriceHendrix]

As many know we've also had issues with sympy simplifying exp when we don't want it. We can stop that by substituting in another function name for exp and then at print time printing exp

The thing with the codegen stuff is that it's too late (you apply it to an already simplified equation), so not that much different to our current printing.

we could add an option for the transpiler to just spit out functions named math. etc.
or maybe for the the model to take some optional handlers to pass to the transpiler? or maybe a SIMPLE_MATHML_TO_SYMPY_NAMES dictionary (edited)

[jonc125]

Is exp the only function you've found where sympy simplifications assuming infinite precision result in wrong code generated? I wonder if log or trig functions might show something similar occasionally, and just not in models we've tested thus far...

Anyway, I can see benefits to using our 'own' functions for these by default in the CellML parsing stage, with a method on Model perhaps to substitute the real sympy functions for users that need them. I'm guessing using Sympy's facilities for calculating Jacobians would want its own exp to be used to get the full benefit!

The reason for linking the question to this issue in my mind was that the optimisations above for cases like expm1 look like they need to see exp so we might need to either copy/paste versions of those that understand 'our' EXP function to apply them, or do some sort of pipeline where we (1) parse to Sympy exp with NumberDummy, (2) optimise for better numerics, (3) substitute EXP instead of exp, (4) replace NumberDummys with sympy.Float, then generate code?

Maybe computing analytic Jacobians etc would come either between stages 1 & 2 (most likely), or between 2 & 3? Using log10 etc would come in stage 1. CSE probably just before or after 4?

[MauriceHendrix]

it's entirely possible that log could cause issues, just not with the numbers our test models happen to be using.

[MauriceHendrix]

So I've just mad a codegen PR improving speed of generating the model

In terms of timing generating normal Shannon2004 on cardiac.nottingham now talkes 8.5s for one of the biggest model, about half of which is load time (cellmlmanip.load_model).