Skip to content

Refactor of ion_if and ion_type to C++ classes

Raphaël Colin requested to merge rewrite-ion-type-ion-if-alternative into master

This merge request mainly contains the following changes (it's a pretty big "code bomb" as discussed in #170 (closed) :D ):

  • Rewriting of the ion_if and ion_type structures as C++ classes
  • Removal of function pointers for ionic models (instead replaced with virtual functions and inheritance)
  • Removal of some generated code (mainly, the IonIf and IonType classes, (former ion_if and ion_type structures) are not generated anymore and the generated code to assign function pointers to generated model functions has been removed
  • New code architecture for model data: The IonIf class is now a template class and can allocate and free all data required by ionic models. This centralizes memory allocations in one place in actual hand-written C++ instead of having allocations all over in generated code (this also means almost no void pointers are used)
  • Memory allocations in the LIMPET library no longer go through a single macro. This means that memory is allocated depending on where the model is running (CPU / GPU), and makes switching between those targets easier
  • Comments and documentation where possible: I added documentation for new functions and classes and tried to complement or write new documentation for existing functions.

Some other notes:

  • Not all code from LIMPET was rewritten as it is too much work for this single merge request: for example, plugins still work by accessing the parent's state variables through an offset and a raw pointer to the parent's state variables, some other utility functions still do these kinds of accesses as well. In order to keep those features working, the new classes expose getter functions to these pointers.
  • In #170 (closed), I proposed to merge the IonIf and IonType classes. This also turns out to cause a lot more headache than necessary for very little gain. The current architecture with a "data" class (IonIf) and an "interface" (IonType) feels clean and requires a lot less changes in LIMPET.
  • Models can technically be moved between GPU and CPU during execution, but some configurations will not work properly (mainly when involving models using the Rosenbrock integration method). This is a consequence of this MR rather than a real stated goal, but future commits will improve on this feature.

I believe these changes make a lot of places in the LIMPET library clearer to follow and understand, and will help in future implementation efforts regarding ionic models.

Please feel free to give me feedback on this, I am available if you have any question or criticism about this MR (these are mainly design choices after all, and are meant to be discussed or questioned)

Merge request reports