[WIP] Automatic python bindings with cppyy

[JosephThomasParker]

Description

cppyy provides automatic python bindings for C++ functions. This allows us to call NESO functions from python scripts, which has the following advantages:

• Allows quick prototyping of different models (changing the python script doesn't require recompiling the C++)
• Easier to integrate NESO into python workflows (e.g. VVUQ, or ML type workflows)
• Makes NESO more user-friendly
• Allows currently hard-coded parameters to be changed in the python script without requiring a recompile

This PR adds:

• Changes to spack.yaml and requirements.txt to add dependencies
• A blurb in the CMakeLists.txt to build the python bindings
• The python script cppyy_run.py which executes the same program as src/main.cpp, but from python
• README_cppyy.md that gives instructions on how to build and run, and outlines problems I'm having with the build system

Type of change

• New feature (non-breaking change which adds functionality)
• Requires documentation updates

Testing

Please describe the tests that you ran to verify your changes and provide instructions for reproducibility. Please also list any relevant details for your test configuration.

• cppyy_run.py replicates the output of src/main.cpp
• Test can be automated, but isn't yet.

Test Configuration:

• OS: CentOS 7
• SYCL implementation: [email protected]
• Compiler: clang @12.0.1

Checklist:

• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• Any new dependencies are automatically built for users via cmake
• I have used understandable variable names
• I have run clang-format against my *.hpp and *.cpp changes
• I have run cmake-format against my changes to CMakeLists.txt
• I have run black against changes to *.py
• I have made corresponding changes to the documentation
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• My changes generate no new warnings

[JosephThomasParker]

So the main problem with this PR is that the code doesn't build automatically... I get build errors when I install through spack, but when I just copy and paste the failed commands into command line, the code compiles and the python bindings work. I've put detailed instructions of the process I go through to get it to build in README_cppyy.md. @jwscook and I have looked at the errors, but couldn't get anywhere. @cmacmackin is this something you can help with?

[jwscook]

In the end we'll want to have a spec per build, so something like

- neso%[email protected] ^openblas ^[email protected]%[email protected] ^scotch@6 ^[email protected]%[email protected]  ^[email protected]%[email protected] ^clang

Preferably with a set of allowable clangs and gccs.

[cmacmackin]

Wayne has told me this needs review. It's still marked as WIP. Should that label be removed? Or are there a few final changes needed prior to review?

[JosephThomasParker]

Hi @cmacmackin, I've stopped making changes and I'd like someone to have a look at it, but I know it's not in a state to get merged. Like I describe above, the actual build commands seem to work in isolation, but not when executed via the cmake script. To get some input on fixing the cmake would be great!

[cmacmackin]

OK, I can give it a go. I've never used cppyy before, so might take a bit of trial and error for me to figure it out and get the hang of it.

[cmacmackin]

Before I tried building the bindings I wanted to ensure I could build NESO properly with Clang. In the process of this I discovered that a regressions have been introduced and the test suite no longer passes for any of the compilers.

[cmacmackin]

This causes regressions. There were previously calls made to the Mesh() constructor with no arguments, expecting it to be equivalent to a call of Mesh(10, 0.1, 1000). However, now it will call your newly-defined default constructor, which uses a different value for nintervals_in and doesn't perform any of the setup done in the body of the original constructor.

[cmacmackin]

This seems to be causing the integration test Electrostatic2D3V.TwoStream to fail. Not entirely sure why that would happen, but when I comment it out the test passes.