[adrian.delser]

Hello everyone,


Let's say I wish to call a simple python function (defined in its own separate .py file) from a custom foam solver. The function will take an input (for example the velocity field: volVectorField U), and return a modified version of it. Let's say for simplicity we just want to take the velocity values defined for each cell centre, flip the sign of each component of velocity (just as a test) and return this to C++ as a modified volVectorField.



The simplified question is: how can I use a variable currently defined in the solver in C++ as an input of a python function and then use the output of that python function back inside C++.


I have seen generic implementations using " #include Python.h ", but none of these use variables present in the C++ code as inputs for the python code.


Thanks!

[Tobermory]

Have you thought about writing to a scratch file, instead of passing the data as parameters? Not as elegant, but easy to do in both directions.

[olesen]

Originally Posted by adrian.delser

Hello everyone,


Let's say I wish to call a simple python function (defined in its own separate .py file) from a custom foam solver. The function will take an input (for example the velocity field: volVectorField U), and return a modified version of it. Let's say for simplicity we just want to take the velocity values defined for each cell centre, flip the sign of each component of velocity (just as a test) and return this to C++ as a modified volVectorField.



The simplified question is: how can I use a variable currently defined in the solver in C++ as an input of a python function and then use the output of that python function back inside C++.


I have seen generic implementations using " #include Python.h ", but none of these use variables present in the C++ code as inputs for the python code.

Thanks!

I haven't yet gotten around to doing these wrappings, but as a slight brute-force method you could follow what is being done here:


https://github.com/argonne-lcf/Pytho...thonComm.H#L74


but I really believe that it should be possible to simply define a wrapped numpy array pointing to the volField:rimitiveField::data() address, with the appropriate stride according to pTraits nComponents - however I haven't yet found the time to test.


If that works out properly (please ping me on develop.openfoam.com if you get something workable), it should be possible to build a bidirectional wrapper, but you will still need a correctBoundaryConditions after doing any modifications behind the scenes. Could probably make it have access to any field registered on the object registry.

[adrian.delser]

Originally Posted by Tobermory

Have you thought about writing to a scratch file, instead of passing the data as parameters? Not as elegant, but easy to do in both directions.

I have thought of that, but I'm not entirely sure to tell python to work on that file every time it gets updated by openfoam. Basically, I'm testing a deep learning poisson solver (implemented in python) to replace the classical cfd methods of correcting the velocity field as a way to save time. This means that for every temporal iteration, openfoam would have to write the unocorrected (non divergence free) velocity field to a scratch file and I would have to somehow tell python to correct that field as soon as openfoam updates the file and then tell openfoam to do the same when python is done correcting the field. I'm not quite sure how to tell either program to read the file only when it has been changed by the other.



Perhaps this is a well known issue for which solutions exist that I am unaware of!

[Tobermory]

Aah - with that much data being transferred so regularly, then a scratch file is not very efficient/clever. Look at Mark's response above - that's the pro way to do it!

[adrian.delser]

Originally Posted by olesen

I haven't yet gotten around to doing these wrappings, but as a slight brute-force method you could follow what is being done here:


https://github.com/argonne-lcf/Pytho...thonComm.H#L74


but I really believe that it should be possible to simply define a wrapped numpy array pointing to the volField:rimitiveField::data() address, with the appropriate stride according to pTraits nComponents - however I haven't yet found the time to test.


If that works out properly (please ping me on develop.openfoam.com if you get something workable), it should be possible to build a bidirectional wrapper, but you will still need a correctBoundaryConditions after doing any modifications behind the scenes. Could probably make it have access to any field registered on the object registry.

Thanks! This is all a little new to me still but I’ll spend some time figuring out what you’ve suggested and I’ll get back if I make progress (or with questions if not)