Easy creation of new models

[joergbrech]

As a general goal for the redesign of the backend, we want a situation where it is easy to create new models, or adapt existing models by copy-pasting a directory. The code could either be designed in such a way, that memilio can be used as a library, or by having convenience (python?) scripts that generate necessary boilerplate code for new models, e.g.

python create_model.py --name spunk

Our directory structure would change to subdirectories for the memilio library, and a directory called models, that contains all models that we created based on the library that we want to maintain. Currently the models directory would contain two subdirectories, one for our age resolved SECIHURD model and one for the SEIR model.

The is more of a meta-issue/epic. We need to

• [ ] reorganize our current directory structure #66

• [ ] Create a list of functions that are currently very secir-specific, but can potentially be generalized for any compartmental model. These should be generalized and moved to the library part of memilio. #63

• [ ] Simplify the creation of compartmental models. As an example consider the get_derivatives function of the secir model. Here, the right-hand-side f of the ODE dydt = f(t,y) is evaluated by hand. It would be more readable and easier to maintain, if it was possible to define the rhs f in terms of flows between compartments. This way, authors of custom compartmental models would not have to concern themselves with conversation of population, etc. #61

• [ ] Document how to write custom models. Probably provide a few more models as examples.

• [ ] Discuss how we deal with python bindings, which are currently specific to a concrete model. Should a library user decide if she wants python bindings? Should we provide python bindings for (a subset of) our library? How do we decide which subset? E.g. with the templatized code it will probably never be possible to generate a customized model in Python alone, but if I write a custom model in C++ and have python bindings for it, will it be compatible with python bindings of memilio library functions?

  Comment by @dabele:

  I think we should provide bindings and IO for our models. these are templates, so bindings can be added to any model that sticks to our interface with one or at most a few lines. we may want to generate this code. if users extend the interface (e.g. a simulation class with more functions, custom types in ParameterSet, etc) and want bindings for those, they need to do it themselves (using our bindings as examples). automatic generation is basically impossible to do correctly and safely. But they should only have to write bindings/io for the things they added, not everything else. so our code needs to be extensible. E.g. the io function for parameterset calls a specific function for each parameter type. users provide an overload of that function for their custom types.

• [ ] Code cleanup: There currently is some redundant unused code in the repo, specifically old .cpp files that are not actually used anymore, because at some point all code moved to the header file.

• [ ] ...

Note: Copied/Modified from https://gitlab.dlr.de/hpc-against-corona/epidemiology/-/issues/424

[reneSchm]

I've made a list of questions that came up creating a simple SIR model:

• where to add a model in the directory structure
  • what namespace should be used
• what to include from where -> maybe have cmake accept include "compartmentalmodel.h" instead of "epidemeology/model/compartmentalmodel.h"?
• how to set up the compartment enum and Populations class
• how to create a ParameterSet
• how to create a (compartmental) model class
  • how to write constructor (base constructor needs template parameters)
  • how to construct Populations and ParameterSet
  • how to overwrite get_derivatives
  • how to correctly index the vector arguments
  • what is difference between arguments "pop" and "y" and when to use them
• how to set parameters and starting population for a model instance -> I think setters for the populations and parameters should have the same interface
• how to start simulation
  • where is simulate() -> make it a member function of the model?
  • how to view the output -> provide print to terminal function?
• how to compile the model -> maybe change cmake/directory setup such that the CMakeLists.txt's don't have to be edited for each new model?

We could answer these questions using a readme or guide, or make some design changes to address them. Almost all of these questions can currently be answered by finding(!) and looking at the seir example.