-
-
Notifications
You must be signed in to change notification settings - Fork 12
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
precice v2.3.0 incompatible with Fluent 21.2.0 due to Boost library #23
Comments
Thanks again @mtree22 for the debugging session! Unfortunately we found out that we cannot do a lot here, as you already described. We got stuck at the following boost call leading to a crash in preCICE due to incompatible boost versions of preCICE (min 1.65) and fluent 21.2 (1.63):
I marked this issue as |
The particular library from boost we were having trouble with was libboost_filesystem.so.1.63.0. I had a crazy idea to soft link this filename to libboost_filesystem.so.1.73.0, hoping I could fake-out Fluent. In theory, this might have worked if absolutely no other libraries that existed within the Fluent install were dependent on 1.63.0. Of course, that's not the case and this caused Fluent to not run. It was a long shot that didn't pan out. I have a question in with the Fluent customer portal that I'm being assured will eventually be answered. Stay tuned! |
I asked this: And was told this: Not surprising, but still disappointing. |
The least hacky solution is to change the CMakeLists.txt of preCICE to request 1.63.0 and then try to get preCICE to work with this version of Boost. --- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -149,7 +149,7 @@ if(TPL_ENABLE_BOOST)
set(Boost_NO_SYSTEM_PATHS ON CACHE BOOL "" FORCE)
unset(ENV{BOOST_ROOT})
endif()
-find_package(Boost 1.65.1 REQUIRED
+find_package(Boost 1.63.0 EXACT REQUIRED
COMPONENTS filesystem log log_setup program_options system thread unit_test_framework
)f
Then disable the tests and hope for the best. $ cd path/to/precice/build
$ cmake -DBUILD_TESTING=OFF -DBOOST_ROOT=...** ..
fingers crossed The biggest potential pitfall will be the projection mappings. The hacky solution would be to build boost as a static library, then link preCICE against it. Then build only build the library. |
I actually elected to try the more hacky solution first. I'm hoping if we can successfully use static Boost then any changes to Fluent Boost won't matter. It may also pave the way for building adapters to other commercial codes that use libraries over which we have no control. So, I built boost as a static library using this bash script: I then forked the precice repo here, and create a branch. I added a precice build option called Of course, when I built preCICE I had to turn
I think the best course of action may be to back up and work through getting the build testing to work before trying to get the fluent adapter to work. Or maybe I should pick a tutorial case to test against before proceeding on to Fluent. Any ideas? |
@mtree22 You are halfway there! As preCICE statically links against boost, it also contains all its symbols, which is why this segmentation fault originates from libprecice.so instead from libboost-log:
The last step is to tell the linker to hide all symbols except the preCICE API.
// file: precice/SolverInterface.hpp
// add this define to simplify your life
#define PRECICE_API __attribute__ ((visibility ("default")))
class PRECICE_API SolverInterface { ... };
PRECICE_API std::string getVersionInformation();
...
PRECICE_API const std::string & actionWriteInitialData();
PRECICE_API const std::string &actionWriteIterationCheckpoint();
PRECICE_API const std::string &actionReadIterationCheckpoint(); Then recompile and you should be ready to go. |
I think I did these next steps correctly, but I'm still getting the same error. I switch from using our internal solver adapter, just to remove any code there as a variable. Now, I'm running the partitioned pipe tutorial case using OpenFOAM. Here are the changes I made to CMakeLists.txt: CMakeLists_changes.txt
And finally, here is the output from pimpleFoam when I try and run the partitioned pipe tutorial: pimpleFoam_out.txt Here's a link to the branch I'm pushing these changes to: https://github.com/mtree22/precice/tree/static-boost-for-fluent |
Well, I was running out of ideas, so I just tried commenting out line 34 of Logger.cpp, and it actually might have worked! The branch of the precice repo I'm working from is the same as above: Once I compiled preCICE with this line commented out, Fluent continued on until waiting for CSMdummy.py to be run. From there, it appears that the python solver never truly receives data from Fluent, but the Fluent solver progresses as if it does. Any ideas? Here is the Fluent output: Here is the preCICE logger output: Here is the output from the python solver: |
I have no idea what's going on here or why this seems to work. You could use a one-way-coupling to have Fluent only receiving data, if this currently seems to be working. You can use the |
@mtree22 The last preCICE log is it leaving This looks like a silly mistake somewhere though. You did build against a modern boost version and not the one shipped with Fluent, right? |
During debugging of a preCICE communication error (specifically a call to Boost that appends filepaths together leading to a segFault at conInfo.read()), it was found that Fluent 21.2.0 employs Boost v1.63.0. preCICE v2.3.0 needs at least Boost v1.65.1, so these are incompatible and is what causes the segFault. In practice, I had compiled preCICE on my own and was using Boost v1.73, but this doesn't change the fact that the Boost versions are incompatible.
This essentially prevents a Fluent adaptor from existing for any version of preCICE except for those compatible with Boost v1.63.0. I believe a quick look-up by developers showed that this is around preCICE v1.4.
The only real solution is to see if we can get Fluent to reference a more recent version of Boost. We know it is possible for Fluent to employ local versions of MPI (using environment variables), so maybe changing Boost versions is a similar option.
I will reach out to Fluent and to see how hard they laugh when I ask about this. I'll report back here.
The text was updated successfully, but these errors were encountered: