Restructure demos into more functions where appropriate

[garth-wells]

Most demos (C++ and Python) have a flat structure. This is fine for simple problems, but I see time and time again that users model their more extensive solvers on the demos and create single function (C++) / flat script (Python) demos that can be many hundreds or thousands of lines.

It would be good to review the structure of demos and refactor with more functions where appropriate. Hopefully users will then model their own codes on the more structured demos.

[jhale]

I've seen issues amongst my collaborators on how to properly structure a 'real' DOLFINx solver. The flat files are very appealing, but it runs out of steam quickly. These are the things I see in 'real' solvers:

• Parametric problems.
• Mesh generation, real geometry, lots of facet and domain tags.
• Significant number of parameters, in different subdomains.
• A time loop. Perhaps with changing timestep at some point.
• Partial IO, i.e. not every timestep.
• Checkpointing output (after summer GSoC project).
• Multiple stages, e.g. preprocessing, simulation, postprocessing (e.g. summary statistics).
• Understanding which objects are expensive to make, and structuring code to avoid recreating them (or avoiding globals).

Clearly there is not only one way to do this, but an opinionated demo would be good to get people on the right track.

[jhale]

• Good ways to write input parameters as flat files and reading them in.

[risa-hirsh]

Hi, I’m new to contributing and would like to help with this. Is this still something that's needed? If so, is there a specific demo you would recommend starting with?