Is there any reason why we can't replace most of the internals of cellmlmanip with Myokit?

[MichaelClerx]

Benefits

• It has well tested CellML import
• It has a system to express equations that allows both a programmatic form myokit.Plus(myokit.Name(x), myokit.Number(2, myokit.units.mV)) and a user-friendly parsing-based form y.set_rhs('x + 2 [mV]').
• It has utility methods for unit conversion, including for incompatible units like A to uA/cm^2 https://myokit.readthedocs.io/api_core/units.html#myokit.Unit.conversion_factor
• It can convert equations to and from sympy https://myokit.readthedocs.io/api_formats/sympy.html (although units will be lost)
• It can resolve the 'solvable order' of all the equations https://myokit.readthedocs.io/api_core/Model.html#myokit.Model.solvable_order or the subset needed for a particular expression https://myokit.readthedocs.io/api_core/Model.html#myokit.Model.expressions_for
• It can import and export other formats
• It has fewer dependencies than cellmlmanip https://github.com/MichaelClerx/myokit/blob/master/setup.py#L60-L65
• Any new improvements we make will benefit a larger user base

Some downsides:

• It doesn't currently do unit conversion between components when importing cellml models (I could have this in within a week or so though)
• It doesn't support units with offsets, like celsius and fahrenheit (these are set to go in cellml 2)
• It doesn't support DAEs (neither does cellmlmanip)

It can also do some of the things cg does, although I think cg does them in a nicer way (with jinja templates)

[MichaelClerx]

We could do a version that exposes the myokit internals to the user, or we could do one that just uses myokit to read & validate, and then exposes a sympy interface to the user (more like it is now). Personally I'd keep sympy out of the loop until the very last step: Only once units etc are no longer necessary convert it all to sympy, allow simplification and jacobians etc., and then pass on to cg

[skeating]

I can see the value of this BUT are we not a bit late in the day to be completely rewriting things (again !).

I'm currently concentrating on unit conversion but if the above is going to happen am I doing stuff that will just get over written ?

[jonc125]

I don't think it's worth changing over at this stage! Also, I'm not convinced by the idea of having a separate maths representation and then changing to sympy for some manipulations. The design philosophy of cellmlmanip was to use best-of-breed libraries for each aspect of model manipulation (maths, units, rdf). (It was unfortunate that sympy's units support turned out to be very weak!) Myokit would be itself a large dependency for Web Lab/Chaste with many features we don't need, I believe.

Oh, and cellmlmanip only has 5 dependencies to Myokit's 6! (If you discount the GUI & optional stuff.)

[MichaelClerx]

Oh, and cellmlmanip only has 5 dependencies to Myokit's 6! (If you discount the GUI & optional stuff.)

OK

[MichaelClerx]

Myokit would be itself a large dependency for Web Lab/Chaste with many features we don't need, I believe.

Every dependency has lots of functionality you don't need. We only use 1 function from networkx for example. And sympy has lots of stuff we don't use.

The design philosophy of cellmlmanip was to use best-of-breed libraries for each aspect of model manipulation

But it doesn't hide any of those libraries! We're just making the user use them directly leading to this confused situation where they need to know about (1) sympy, (2) pint, (3) how our API ties them together, (4) networkx, (5) which bits of info go in networkx and which go in our sympy equations

Cellmlmanip doesn't wrap around these internals, it exposes them and makes users use bits of them - but not other bits. How is that user friendly?

[jonc125]

But it's not trying to wrap around them! It's giving users an easy way of parsing CellML into sympy for manipulation etc. without losing the critical units & annotation information. Exposing sympy was a conscious design decision, to avoid writing our own less complete symbolic manipulation library (like pycml is).

The networkx dependency is the only one I think is marginal, as (lexicographic) topological sorting is pretty easy to implement. But equally, if you have a graph you want to do graph algorithms on, why not use the already written and well tested leading Python graph library?

[MichaelClerx]

Because it's one more thing for users, developers, and maintainers to learn about. And one more breakable thing that's outside our control.

[MichaelClerx]

We're doing this:

1. Build some static equations w. sympy. Only using sympy as an expression tree. But with special rules to preserve units, annotations, etc. Users are not allowed use sympy properly at this point
2. Manipulate those equations (still with restrictions)
3. When all is done, use sympy magic
4. Generate expressions

So we've got sympy-but-not-quite expressions in step 1 and 2, and then sympy expressions in step 3 and 4 (after user interaction is over). So why make the user interact with sympy-but-not-quite in the first 2 steps?

[jonc125]

Equally, why make them learn another expression tree representation to do steps 1-2 from that used in steps 3-4?

[MichaelClerx]

They don't do 3 and 4, they only do 1 and 2. Steps 3 and 4 are under the hood. So all we give to users is the hacks-on-top-of-sympy bit. They never see the nice bit where all the cellml stuff is gone