-
Notifications
You must be signed in to change notification settings - Fork 109
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
Fix/pyAction: Separate classes for python bindings and opm embedded #4017
Fix/pyAction: Separate classes for python bindings and opm embedded #4017
Conversation
ccc241b
to
e97bc99
Compare
@hakonhagland: Can you also have a look at this? Thanks! (I'm tagging you here because for some reason you don't appear in the reviewers dropdown) |
jenkins build this please |
e97bc99
to
39387f5
Compare
jenkins build this please |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since I don't really know enough about pybind11 I just have a tangential question. Overall this looks good to me and I appreciate the refactoring.
python/cxx/export.hpp
Outdated
void export_ScheduleState(py::module& module); | ||
void export_TableManager(py::module& module); | ||
void export_Well(py::module& module); | ||
void export_Log(py::module& module); | ||
void export_IO(py::module& module); | ||
void export_EModel(py::module& module); | ||
void export_SummaryState(py::module& module); | ||
void export_SummaryState_embedded(py::module& module); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a formal requirement that all functions which export something have to be named export_*
? If not, could we conceivably have
namespace python::common::export {
void SummaryState_embedded(py::module& module);
// &c
}
instead?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
export is a keyword in C++, if we use another one, like python::common::export_opm then that's possible, then I'd suggest
python::common::export_opm {
void summaryState_embedded(py::module& module);
// &c
}
7df6d2f
to
2f6f260
Compare
jenkins build this please |
95c13af
to
6f22c00
Compare
I was a bit unsure whether the macro magic really works with CMake and I checked the output of
Seems link |
That might have been with an old version |
Clarified in a quick phone call - I also found what you meant: The link -DEMBEDDED_PYTHON comes from this line: https://github.com/OPM/opm-common/blob/master/CMakeLists.txt#L502 |
Well, I am too slow pulling, or you just too fast for me. Sorry for the noise. With the new version it works |
6f22c00
to
006c283
Compare
jenkins build this please |
1 similar comment
jenkins build this please |
006c283
to
085fdf2
Compare
jenkins build this please |
@hakonhagland: Can you have another look? |
4b98e51
to
8972bb9
Compare
jenkins build this please |
@blattms @bska @akva2 @hakonhagland this PR and #4029 are finally green and ready :) |
…create opm.common.* Now, there are two modules created - opmcommon_python - opm_embedded, as embedded Python module, needed for PYACTION and PYINPUT
d99e29b
to
1590f66
Compare
jenkins build this please |
1590f66
to
a41887b
Compare
jenkins build this please |
I tested this one on Ubuntu noble (version of this morning at 8:00) and the tests in opm-common build fine. So this seems to work for Python 3.12. We still have OPM/opm-simulators#5322 (but as it turns out we do not run the (failing) python tests on Debian and Ubuntu and the problem is there for older python versions). Problem is that currently I am really nervous and will also try to run a few of the models in the regression test suite on Ubuntu noble. Let's see... |
Did you run this one or #4029? But in any case: good that we have sth. working on Ubuntu noble!!! 🎉 |
Turns out I am a bit stupid and somehow missed activating OPM_EMBEDDED Last commit is "Add file and entry in README.md for autocompletion in VS Code" |
a41887b
to
2589a48
Compare
2589a48
to
d2f45c5
Compare
@blattms: I've changed the stub file now - your idea of putting it at opm_embedded/init.pyi worked 👍 |
jenkins build this please |
Looks good and is tested. Merging. |
I was using the super cmake file (https://github.com/OPM/opm-utilities/tree/master/opm-super) without building everything but only The cmake flags is after But when I tried to
Basically, it means that the module It is nice that dependence handling can be improved when coming to this. Thanks. @lisajulia |
@GitPaean: Thanks for noticing! |
|
Ok, thanks, can you check if the python library file opmcommon_python is really not in |
The important point here is that he uses the super-build and not the separate buildsystem per module. Do not try to use a separate buildsystem build / dune-control build to analyze this situation. |
|
Ok, thanks for all the info! |
at the core the problem is very simple: he built a specific target, not the all target, and this specific target does not get a dependency on the opm_embedded target set. one could argue that is the correct behavior but i guess it can be seen as a little inconvenient. |
ok - well I'd say opmcommon_python should be built in any case if the flag OPM_ENABLE_EMBEDDED_PYTHON (which implies OPM_ENABLE_PYTHON) is set to true, no? |
and it will be if you build the all target. but he specifically said only build flow_blackoil. |
opm_embedded is just there and not built. Library opmcommon_python needs library opmcommon. For this we have a dependency of opmcommon_python on opmcommon. Now it seems that your superbuild would need to know that library opmsimulators depends on both opmcommon_python and opmcommon. There seems to be no way to resolve this via dependencies within opm-common. (Assuming circular dependencies are evil and we cannot have opmcommon depend on opmcommon_python in addition). I am not 100% sure how your superbuilds work. The only clean solution seems to be to have another exported target within the build system of opm-common for library opmcommon_python and makes sure that library opmsimulators depends on this, too. This will be some work. |
the super-build just does add_subdirectory() on each module, https://github.com/OPM/opm-utilities/blob/master/opm-super/CMakeLists.txt if(TARGET opm_embedded)
add_dependencies(flow_blackoil opm_embedded)
endif() in the opm-simulators buildsystem, just like e.g. https://github.com/OPM/opm-simulators/blob/master/CMakeLists.txt#L643 so there is not really any voodoo required. the question is, as I said, whether this is a correct change or not. |
This PR contains 5 minor commits, one larger change and one commit adding a stub-file for opm_embedded as well as an entry about that to the python/README.md.
The larger change:
Before, there were three modules exported to Python:
- opmcommon_python
- opm_embedded, as embedded Python module
- opm_embedded, as the shared library
Now, opm_embedded is not built as a shared library anymore, but uses opmcommon_python
PR #4029 removes the creation of a shared library entirely, then only opmcommon_python is built.