Interface for code generation - from Model manipulation

[skeating]

Remaining items from this section of #21

• Iterate over all equations
• Topological sort of equations
• Renaming variables if needed?
• Mark a variable as
  • Modifiable parameter
  • System output of interest (also called derived quantity in pycml)
• Cython + CVODE code gen - this is more for weblab-cg
  • Basic system of ODEs
  • Add interfaces for setting parameters & reading outputs
  • Handling a purely algebraic system

@MauriceHendrix it would be useful if you added things here as you encounter them; since I think these are things that will directly impact you

• Would be useful if model.get_symbols accepted a list instead of single equation model.get_symbols([eqations])

• Would be useful to have a sort of "dimensionally_equivalent" (that's how pycml calls it) which cheks of 2 things are in the same sort of unit, ignoring conversion factor

• Shortcut functions requested: shortcut for factor = model.units.get_conversion_factor(1 * current_units, secondary_units)
  ideally I guess I'd do something like factor = model.get_conversion_factor(eq.lhs, desired_units) (and return 1.0 if the units are the same)? see Shortcut conversion factor #98

get_equations_for features:

• the lexicographical_sort flag is not quite what I need No longer needed.
  Would it be possible to have the output ordered according to the input symbols. so that I don't have to do:

for x in symbols:
    equations.append(model.get_equations_for([x]))```
* [ ] Can we add a feature that stops recursion past a list of given symbols, so you don't include those symbols or their dependencies? right now I've got to do:
```equations = []
for x in symbols:
    if x not in unwanted_symbols:
        equations.append(model.get_equations_for([x]))```

[MauriceHendrix]

Any chance model.get_symbols could take a list of equations, rather than just 1? Or maybe even better, allow both options?
Equally it would be nice if model.get_equations_for had the option of just accepting 1 equation?

[jonc125]

You can always do model.get_equations_for([eqn]) if you only have one though? Would you want to be in a situation where you weren't sure if you were dealing with a single equation or a list?

[MauriceHendrix]

that's true so I suppose maybe keep get_equations_for the way it is but then it would be nice for model.get_symbols to also work that way I suppose

[MichaelClerx]

Not sure we need renaming of variables in cellml: With code generation we (have the option to) rename anyway

[jonc125]

In pycml the renaming was primarily to avoid conflicts - both in its internal state, and in generated code. Within cellmlmanip Model we have the name_to_symbol mapping, so that still requires unique variable names internally.

[MichaelClerx]

OK!
I think "Mark a variable as " can though, right? We're pretty much doing that now in cg/fc, using ontology terms read through cellmlmanip, don't think cellmlmanip needs to know about this

[jonc125]

Hmm, certainly fc needs to tell cg that info. It might need to tell cellmlmanip something about the outputs of interest to be able to ignore irrelevant state variables? That logic will need to go somewhere between the 3 codes, anyway.

[MichaelClerx]

Hmmm.. so a "mark as used" option, to stop outputs from being optimised away?

[jonc125]

Depends where that optimisation happens - I suspect it'll become clearer once we start implementing it in fc!

[skeating]

Outstanding issues that need clarification at this point

• [] renaming variables

is this off the table for cellmlmanip; discussion above looks like it might be but we are further on with fc/cg and may have a clearer answer

• [] Mark a variable as
  - [] Modifiable parameter
  - [] System output of interest (also called derived quantity in pycml)

still necessary ? If so, where would this flag go ? On VariableDummy ?

@MauriceHendrix
Do you still need this:
get_equations_for features:

the lexicographical_sort flag is not quite what I need. Would it be possible to have the output ordered according to the input symbols. so that I don't have to do: (see above)

[MauriceHendrix]

@skeating that isn't necessary anymore you can close any tickets related to that if you want.

[MichaelClerx]

I'm guessing we don't need the "mark variable" bit, since sympy doesn't simplify out any variables. So all variables are guaranteed to still exist after manipulations, at the moment.

[jonc125]

Yeah, I think the marking probably isn't needed - it'll be better if CG/FC keep their own lists of variables for this. (In the case of Chaste CG, some of this is done through RDF annotations.)

So we can close this I think.