Narrow down the functionality

If you write a solver for a special domain, create a subclass of your ExaHyPE numerical scheme of choice. Users then shall work against this subclass.

Next, you can narrow down the parameters. Do users really have to specify which terms are there if you already know the application domain and, therefore, the PDE type? ExaHyPE solvers are not simple in the sense that they are very generic. It can not harm to narrow down options.

If users wanna extend the functionality of your bespoke solver later on, the classes are still full-blown ExaHyPE solvers. They can still add all kinds of things they wanna add.

Keep functionality in C++

Unless you work with SymPy and similar options, it has paid off to move all Physics into separate C++ header files. In this case, you can compile them independently, and the Python solvers only contain calls to these routines. They map the solver-specific names for coordinates, for example, onto the right parameters for our C++ code.

This is obviously the right choice for developers favouring or needing Fortran: Create some C++ bindings and let the Python stubs work against these stubs.

Peano's makefiles can be added "additional" C++ files besides all the glue code Peano/ExaHyPE generate anyway. This way, you can embed your domain-specific realisations directly into the overall build environment.

Do not over-engineer

We have seen applications tremendously over-engineering code in the sense that they try to cover for all possible usage scenarios: starting from parser options all the way down to solver features. I do recommend that you go the other way round. After all, the easy modification and extension of code is definitely an advantage of Python. ExaHyPE mirrors this: Nothing stops you form running N different solver on one mesh.

Decompose your bespoke solver again into elementary building blocks just as the ExaHyPE core does.

Table of Contents

Narrow down the functionality

Keep functionality in C++

Do not over-engineer