Python Interface / Scripting

[anicusan]

Hello,

Thank you for developing this library and making it so approachable - using just the lethe wiki and deal.II docs I was able to become quite productive and set up new cases without having very deep knowledge of FEM. I have a few ideas I'd like to discuss as a (currently) outside end-user of the library about a possible Python interface to lethe - all comments are much appreciated!

Many mature numerical simulation libraries create and use their own scripting languages - e.g. deal.II has .prm files, LAMMPS has its interpreted input scripts. While useful in the beginning for the exact use cases the library was developed for, it can become very limiting in the long-term as end-users try to run cases developers did not specifically envision. For example, simulating two nitsche IB spherical particles approaching is beautifully simple to set up with just two subsection nitsche solid blocks.

However, setting up an ensemble of 629 particles at various solids concentrations (which is something I'd actually like to do) is much more cumbersome, requiring automation - in this case, probably a Python script generating the .prm or JSON file. Why not cut the middleman and use a Turing-complete programming language to set up simulations directly, and get its entire cohesive ecosystem for free (e.g. pygmsh, numpy, pyvista)?

• It would also allow us to more easily keep track of possible parameters and their default values - for example, to find out what possible options there are for the bdf startup method , I had to look up parameters.cc to see the "sdirk step" variant (which I haven't found in any example); same for the default max krylov vectors value.
• General simulation start-up procedures are much easier and portable in Python - e.g. ensuring that the output path exists and creating that directory if needed; all I could find for filesystem management in C++ was in Boost, but that's a rather big dependency to bring in.
• And should something go wrong, it's much easier to print friendly user-facing errors in Python - if the output path does not exist, gls_nitsche_navier_stokes_33 just hangs for me; if the number of solids is accidently set too high, the error is simply "Error, invalid mesh type. Choices are gmsh and dealii". And perhaps we could automatically set restart to true if restart files are found before starting the simulation.

Finally, deal.II maintains conda packages - installing it is as simple as conda install dealii. It would greatly lower the entry barrier to using lethe (and perhaps developing it too) if we could just do conda install lethe and run a single Python script to set up a simulation. Then we could host interactive examples on Google Colab (example) without requiring any user installation - Jupyter Notebooks can be run or downloaded and have post-processing steps added as new code cells to create a cohesive, complete lethe workflow.

If this is something that the lethe developers think would be useful for the main project, I'd be more than happy to help develop and contribute such a Python interface and set up some conda recipes and Colab examples.

Best wishes,
Leonard

[blaisb]

Dear Leonard,
A warm welcome from the other side of the ocean. Thank you for your comments.

The parameter file format we use and inherited from deal.II obviously has some severe limitations. We generally get around them by scripting the generation of the files themselves (since this is easy to deploy), but I fully agree with you that this also brings limitations. One thing that has always annoyed me is how we need to specify both the number of boundary conditions, and then specify each boundary condition in a block. Using a more advanced XML / JSON parser, we could indeed just specify blocks and automatically know the number of boundary conditions for instance.

As for the python interface, I think this is a good idea. A lot of people are familiar with Python and some other FEM codes (e.g. FENICS) have had great success with such interfaces. My only worries with this is that it is a lot of work to maintain and I have seen a lot of other codes where there ended up being a disparity between the python interface and the regular code. This is always a challenge.

To be honest, I don't have the knowledge to generate such an interface and, at the moment, I lack the time to acquire it. We have juggled with a lot of things in the last year: Making a more robust CMake, deploying a better CI, making pull request friendlier and we are just spinning out a new documentation that will be completed this month (https://lethe-cfd.github.io/lethe/). All awesome work done by students or interns (@CaroleAnneDaunais , @paulapatience , @technophil98 ).

If you feel like such an interface would help you in your research, we will gladly try to help you achieve this :). We try to take a very open approach to community development in Lethe. Anybody can submit a PR and we will gladly review it and integrate it if it is coherent.