Python+Idefix now available for testing

[glesur]

Following popular request during the Idefix days, the python binding of Idefix pydefix is now available on the public repository, in the pythonBinding branch. There is no proper documentation, but an example and a README file are provided in test/IO/pydefix directory.

We will wait for your feedback before merging this into the develop branch. Thanks!

[neutrinoceros]

For what it's worth idefix-cli is now aware of this feature (since version 5.2.0) and treats Python modules as source files by default in idfx clone, which seems to do the job.

[jeankpf]

Hello, I just want to keep track of a small feature I added wrt the initial version of the Python binding module (which might be worth to include in future versions). For a slightly more advanced initialisation of the flow, I sometime need to know which sub-domain is handled by the current process (in multi-processing), which I usually know thanks to the gbeg, np_int/tot array of a DataBlockHost instance. Those array were not accessible from its python counterpart data, so I added the following lines in the src/pydefix.cpp file:

    .def_readwrite("nghost", &DataBlockHost::nghost)
    .def_readwrite("np_int", &DataBlockHost::np_int)
    .def_readwrite("gbeg", &DataBlockHost::gbeg)

While doing so, I noticed that those array can similarly be modified from the Python interface (like the IdefixArray Vc or Vs for example). I guess that you are already aware of this, but user should be careful about not messing with that while initialising the flow.

[glesur]

It might be safer to define these properties as readonly (i.e. .def_readonly("nghost", &DataBlockHost::nghost)) to avoid this sort of mistake? (not sure this works as it might requires nghost to be declared as const).

[jeankpf]

I agree on the principle, after few test cases however, it seems that I was unable to mess with the nghost, np_int, nor the gbeg arrays even though they were still declared as readwrite. I have the feeling that the pythonised counterparts of the dataBlockHost attributes are processed differently according to their C++ types. More specifically, it seems always possible to write in a pythonised IdefixHostArray (even when declared as readonly) like Vs, Vc, or even worse, dV, it is also possible to write in a pythonised array of IdefixHostArray (no matter its r&w properties) like x, but never in a pythonised array of int like gbeg, np_int for instance. I don't think any of these behaviours is critical though, but they're worth being kept in mind or posted in a discussion like here.

[glesur]

It's true that I had to write my own wrapper for IdefixArrays ensuring that the C++ and its python counterpart were both referencing the same memory region (I.e no copy involved when passing to python)

The automatic type casting provided by pybind11 for standard types like 'std::array' is actually a copy, not a reference, so it doesn't modify the original C++ array content... that's why.

[glesur]

Update: you now have the possibility to gather the data from all of the MPI processes in python, and hence play with the entire dataset in python.

2025 will be a good year for pydefix!