Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

init_RANS functions #1139

Open
cekees opened this issue Apr 17, 2020 · 1 comment
Open

init_RANS functions #1139

cekees opened this issue Apr 17, 2020 · 1 comment

Comments

@cekees
Copy link
Member

cekees commented Apr 17, 2020

@JohanMabille I was doing some local testing of the RANS3PSed class (just merged your PR #1133) and noticed some 2D calls in the 3D pybind11 wrappers:

$ grep init_RANS *.cpp
RANS3PF2D.cpp:void init_RANS3PF2D(py::module& m)
RANS3PF.cpp:void init_RANS3PF2D(py::module& m);
RANS3PF.cpp:    init_RANS3PF2D(m);
RANS3PSed2D.cpp:void init_RANS3PFSed2D(py::module& m)
RANS3PSed.cpp:void init_RANS3PFSed2D(py::module& m);
RANS3PSed.cpp:    init_RANS3PFSed2D(m);

I think it probably works fine anyway (just a naming issue), but can you explain what is going on here? I noticed that the RANS2P wrappers don't declare or call a module init function.

@JohanMabille
Copy link
Member

RANS2P and RANS2P2D are actually two separate Python extensions. RANS3PF and RANS3PF2D sill belong to the same Python extension, I just split the bindings in two separate cpp files. This reduces the amount of memory required for building each of these cpp files while not requiring any change on the Python side.

The cpp file defining the bindings still has to bind both classes, thus the init_XXX function.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants