Error while building openfoam-adapter for OpenFOAM-v1912

[Stan]

Hi preCICE team,
Today I tried to build openfoam-adapter for OpenFOAM-v1912 but failed(but worked for OpenFOAM-7). Unlike the other topic with the same error, I didn’t use spack and just followed the guide to install precice and openfoam-adapter. The error message is uploaded.
Allwmake.log (708 Bytes)
ldd.log (9.3 KB)
wmake.log (621.9 KB)

I also tried to download openfoam-adapter_v1.0.0_OpenFOAMv1812-v2106 and built it. However, the same error happened. How could I deal with this problem?
Thanks in advance!

[ajaust]

Did you use the package manager (apt) for installing OpenFOAM or did you compile it from source? Did you check the OpenFOAM installation if it works as expected?

@Makis had commented on the same error 2.5 years ago on Gitter. Back then it was not clear what was the reason for the error. Maybe Makis has any idea now?

[DavidSCN]

Your linker reports undefined symbols indeed. I guess one potential issue might be that you have a 64 bit OpenFOAM version, but preCICE only supports 32 bit versions for the moment (actually never tried it, you might be lucky if you stay below the 32 bit integers). There is also a related issue Add support for 64-bit indices · Issue #887 · precice/precice · GitHub

Still, I’m not sure if it resolves your issue. The linker issue might be unrelated.

[Stan]

@ajaust @DavidSCN
Thanks for your reply.

@ajaust

Did you use the package manager (apt) for installing OpenFOAM or did you compile it from source? Did you check the OpenFOAM installation if it works as expected?

I compiled both OpenFOAM-7 and OpenFOAM-v1912 from source. Yes, I’ve run cases using both versions and they worked well.

@DavidSCN

I guess one potential issue might be that you have a 64 bit OpenFOAM version, but preCICE only supports 32 bit versions for the moment (actually never tried it, you might be lucky if you stay below the 32 bit integers).

Yes, both OF I currently used are 64 bit versions. However, the adapter is built successfully for OF7…
I’ll install a 32 bit OpenFOAM version to see whether the adapter can be built successfully.

[Makis]

Looking at your ldd.log, I see the following error:

undefined symbol: fftw_taint	(/lib/x86_64-linux-gnu/libfftw3_mpi.so.3)
undefined symbol: fftw_join_taint	(/lib/x86_64-linux-gnu/libfftw3_mpi.so.3)

Could it be that you have multiple versions of libfftw3 installed and it picks a different one when compiling and a different one when linking? By the way, this is not a direct dependency of the adapter, so try building another OpenFOAM function object to check.

You can check shared libraries for runtime linking with ldd mylibrary.so.

[Stan]

Hi Makis,
It seems that there are different versions of libfftw3.

@Makis

By the way, this is not a direct dependency of the adapter, so try building another OpenFOAM function object to check.

You can check shared libraries for runtime linking with ldd mylibrary.so .

I’m sorry that I don’t quite understand your suggestion. Do you mean that I should build some function object to check whether the linking process is fine?

@Stan

I’ll install a 32 bit OpenFOAM version to see whether the adapter can be built successfully.

By the way, I’ve just installed a 32 bit OF-v1912 and failed building openfoam-adapter. It may not be the problem of 64 bit OpenFOAM version.

[Makis]

@Stan

It seems that there are different versions of libfftw3 .

This still looks like the same version to me. Maybe OpenFOAM ships libfftw3 in their ThirdParty solver? Did you have to build that dependency when you built OpenFOAM?

I still believe that this should be the direction to look at.

@Stan

Do you mean that I should build some function object to check whether the linking process is fine?

Exactly. Take the example function object (on my system at /usr/lib/openfoam/openfoam2106/etc/codeTemplates/functionObject/ and try building it. Then use ldd on the built object. I hope that this will still rely on FFTW, even though it is too simple.

@Stan

By the way, I’ve just installed a 32 bit OF-v1912 and failed building openfoam-adapter. It may not be the problem of 64 bit OpenFOAM version.

To be honest, we never considered single precision for the OpenFOAM adapter, so I am not surprised. I don’t think that this is really related to the 64bit labels issue, but let’s see.

[Stan]

Thank you for the explanation!

@Makis

This still looks like the same version to me.

Yes, now I know the files in cyan are just linking files.

@Makis

Exactly. Take the example function object (on my system at /usr/lib/openfoam/openfoam2106/etc/codeTemplates/functionObject/ and try building it. Then use ldd on the built object. I hope that this will still rely on FFTW, even though it is too simple.

I’ve built the function object and the logs are posted. It seems that it doesn’t rely on FFTW.
ldd_functionobject.log (2.0 KB)
wmake_functionobject.log (8.4 KB)

[Makis]

Can you maybe also try with the “forces” function object?

[Stan]

Sorry that I forgot to reply.
I’ve just tried with “forces” function object and the logs are as follows.
ldd_libforces.log (1.9 KB)
wmake_forces.log (131.5 KB)

[steffenger]

Hello Stan, i had the same issue and I reinstalled openfoam without the third party packages, because there was a fftw3-3-7 folder in the third party directory. Maybe this can help.

best regards steffen

[Stan]

Thanks for your reply! After reinstalling openfoam without the third party, the openfoam adapter is compiled successfully.
Thanks again for the help provided by you and preCICE team

[Makis]

Related: Compiling the OpenFOAM adapter complains about std::make_unique - #15 by Makis