OpenFOAM Int64 Catalyst is not loading properly because of a missing symbol

In Situ Support
1

Hello,

I am really sorry for this desperate plea, but I’d like to ask @utkarsh.ayachit and @olesenm for some help. I’ve been enjoying Catalyst V2 in ESI OpenFOAM for a while now, but now I am finally getting to a more serious benchmarking exercise and I needed to recompile OpenFOAM with Int64 labels to support larger meshes. Unfortunately, in two identical test cases Catalyst V2 does not load in the Int64 version.

The problem is a missing symbol _ZN4Foam14functionObject7executeEi. My adaptor function object for both versions contains it and nm says it’s undefined:

nm -gD libnaiveHexCatalyst2Foam.so | grep _ZN4Foam14functionObject7executeEi
                 U _ZN4Foam14functionObject7executeE

After happily browsing through OpenFOAM platforms/linux64GccDpInt*Opt/lib directories for 32 and 64 I found that the symbol is defined as T in my 32 version but not 64.

I would appreciate some advice. I do not know how to connect the symbols appearing in .so files with OpenFOAM compilation process or code. Could this be a bug or an issue with my compilation? I am happy to learn a little more about this as I often get stuck in chasing these symbol dependencies but I’ve been a bit rudderless for a while so would be really grateful if you could point me in the right direction. Thanks.

2

@Francois_Mazen @nicolas.vuaille

3

Not much time at the moment to test anything, but did notice that building against the most recent paraview fails anyhow with the following:

Could not find the VTK package with the following required components:
IOFFMPEG.

This all feels like such a moving target :frowning:

4

Thanks for a reply, @olesenm. I should have mentioned that this is still built against 5.9.1. Thinking about it, it may be that the problem is not on the PV side or my PV build, but my OF Int64 build. Could you direct me as to why _ZN4Foam14functionObject7executeEi is not present in Int64 but present in Int32? Where and how should I even look for the difference between the two? I am happy to do the testing myself.

In the interest of full disclosure, I’d like to solve this issue before August, as I am aiming to submit something for ISAV2022 workshop. I will definitely acknowledge all the support I am getting from this forum, but also happy to co-author if that’s of interest.

5

Hmmm,

c++filt _ZN4Foam14functionObject7executeEi
returns the more legible:
Foam::functionObject::execute(int)

My wild guess (knowing next to nothing about OpenFOAM’s build system) is that the argument type get modified based on your Int64/Inte32 setting and that that leads to a mismatch with what Catalyst V2 wants.

hth in some way and good luck on you submission.

2 Likes
6

This is a pretty good shout. There are in fact two different functionObject execute methods:

  • bool execute()
  • bool execute(const label subIndex)

So with WM_LABEL_SIZE=64, the second signature will be execute(int64_t) instead of execute(int32_t)

7

Thanks, @Dave_DeMarle, that’s a great suggestion. I did not know about c++filt command. Very useful tool.

So I have now confirmed that everything is OK with OpenFOAM as it contains:

nm -gD libOpenFOAM.so | grep functionObject | grep execute
00000000006046e0 T _ZN4Foam14functionObject25unavailableFunctionObject7executeEv
00000000006046b0 T _ZN4Foam14functionObject7executeEl
000000000061c680 T _ZN4Foam15functionObjects11timeControl7executeEl
000000000061c5a0 T _ZN4Foam15functionObjects11timeControl7executeEv
000000000060c000 T _ZN4Foam18functionObjectList7executeEl
000000000060c060 T _ZN4Foam18functionObjectList7executeERKNS_5UListINS_6wordReEEEl
000000000060e820 T _ZN4Foam18functionObjectList7executeEv

And _ZN4Foam14functionObject7executeEl demangles into long:

c++filt _ZN4Foam14functionObject7executeEl                 
Foam::functionObject::execute(long)

This narrows the problem down significantly and it points to my build of the catalyst adaptor. I am trying to figure out now what went wrong there and why my compiled so contains the “short int” name.

8

Wild guess that you didn’t have WM_LABEL_SIZE or Foam::label properly picked up.

We have the following in CMakeLists chain:

# Convenience name, as per wmake internals
set(LIB_SRC "$ENV{WM_PROJECT_DIR}/src")

# Needed for internal label-size, scalar-size, templates
add_definitions(
    -DWM_$ENV{WM_PRECISION_OPTION}
    -DWM_LABEL_SIZE=$ENV{WM_LABEL_SIZE}
    -DNoRepository
)
1 Like
9

Thanks, @olesenm. That was precisely it. I didn’t have to dig into CMake even. I have set up OpenFOAM on this cluster myself and generated my own module files for it in order to have both versions:

ml av
...
   openfoam/v2106/DPInt32        openfoam/v2112/DPInt64 (L)    paraview/5.10.0/osmesa (D)
   openfoam/v2112/DPInt32 (D)    paraview/5.10.0/egl           paraview/5.9.1/osmesa  (L)

I am a big Lmod fan as I think it makes it easy to manage shell environments, which can be complex on HPC. There is also now a full integration with sourcing shell files within Lmod, which I should be using, but this cluster has slightly older Lmod so I generated the module files with this and manually adjusted for different variants…

I changed WM_LABEL_OPTION, but missed WM_LABEL_SIZE so CMake properly picked up the wrong integer. The error, as often in my case, was between the seat and the keyboard.

Thanks to everyone for providing ideas.

10

If you do need to create modules or simplified shell environments for OpenFOAM, can also consider leveraging the bin/tools/foamCreateModuleInclude script.