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.
joergbrech
commented
3 years ago
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.
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 themodelsdirectory 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_derivativesfunction 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 rhsfin 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:
[ ] 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