[Andrea1984]

Hi all,

I am trying to create my own solver modifying reactingMultiphaseEulerFoam in OpenFOAM v6.0.

To start with, I have created a copy of the original $FOAM_SOLVERS/multiphase/reactingEulerFoam/reactingMultiphaseEulerFoam in my local /applications/solvers folder

A this step I change target folders for the executable and the libraries to $FOAM_USER_APPBIN and $FOAM_USER_LIBBIN, change the name of the resulting executable and library files to avoid conflicts with existing ones and amend all the Make/option files accordingly

I can successfully compile and execute the solver created in this way (souce code attached in the OK tarball).

The issue arises when I want to modify also the phaseSystems library associated with my new solver. The "original" library is located in $FOAM_SOLVERS/multiphase/reactingEulerFoam/phaseSystems. I created a copy of this in my local applications/solvers/multiphaseReactingEulerFoam. Following the same procedure as before, I have changed the target folder to $FOAM_USER_LIBBIN, changed the name of the phaseSystems library and make sure that all the Make/options files of my solver point to the new local phaseSystems/lnInclude and to the local phaseSystems library.

Now the solver still compiles successfully, but I get loads of "Duplicate entry XXX in runtime selection table YYY" errors when I execute it. All the errors looks like the one below and I have loads of them, essentially one for every possible entry in every runtime selection table within phaseSystems:

Duplicate entry purePhaseModel in runtime selection table phaseModel
#0      /usr/not-backed-up/opt/OpenFOAM-6/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so(_ZN4Foam5error14safePrintStackERSo+0x27) [0x7fa7f41d1be7]
#1      /home/csunix/preades/OpenFOAM/preades-6/platforms/linux64GccDPInt32Opt/lib/libreactingPhaseSystemFlex.so(_ZN4Foam10phaseModel32addphaseSystemConstructorToTableINS_22AnisothermalPhaseModelINS_14PurePhaseModelINS_15InertPhaseModelINS_16MovingPhaseModelINS_16ThermoPhaseModelIS0_NS_9rhoThermoEEEEEEEEEEEEC2ERKNS_4wordE+0xd6) [0x7fa7f82b11b6]
#2      /home/csunix/preades/OpenFOAM/preades-6/platforms/linux64GccDPInt32Opt/lib/libreactingPhaseSystemFlex.so(+0xd4aa4) [0x7fa7f829aaa4]
#3      /lib64/ld-linux-x86-64.so.2(+0xf8f3) [0x7fa7f86468f3]
#4      /lib64/ld-linux-x86-64.so.2(+0x115a) [0x7fa7f863815a]

which is really puzzling me since the conflict does not seem to be between the local and the global phaseSystems libraries, but between the local phaseSystems and the global libOpenFOAM. The source code for the solver generating this error is attached in the ERROR tarball.

Any idea of the reasons behind this and how can I possibly fix it? I have been trying for weeks now and starting to be hopeless!

Many thanks,
Andrea

[clapointe]

In my experience this happens when the original library is referenced/linked at some point along the line -- and it may not be the first place you'd think to look. In the past I've methodically worked through a series of libraries to make sure they all reference "new" libraries in $FOAM_USER_LIBBIN and not the originals. That said, I've found them to be simple warnings (i.e., no solver crash) without impacting anything; just make sure that any new functionality added is indeed being used. Others should chime in if their experience differs!

Caelan

[Andrea1984]

Hi Caelan,

thanks for your reply. Would you mind clarifying a few things?

In my experience this happens when the original library is referenced/linked at some point along the line -> I have the same experience, but this time I really don't seem to reference the existing library anywhere ... or at least anywhere I would expect to find such a reference (see below)

and it may not be the first place you'd think to look -> Can you please expand on what you mean by this? Do you reckon I should look somewhere else apart from my Make/files and Make/options files? If yes....where? For the sake of clarity, I have already searched through the #include directives in the source code for absolute paths to the "original" header files, without finding any

In the past I've methodically worked through a series of libraries to make sure they all reference "new" libraries in $FOAM_USER_LIBBIN and not the originals -> Can you suggest any particular method to do this?

That said, I've found them to be simple warnings (i.e., no solver crash) without impacting anything; just make sure that any new functionality added is indeed being used -> Again, this is also my experience so far. But those are rather worrying warnings and are somehow undermining my confidence in the solver I am developing.

Many thanks,
Andrea

[ybapat]

This can happen if you have given same typename which is already used in OF code. The same typename is added twice in the run time selection table. You can change type name of the class that you have compiled.

[Andrea1984]

Thanks for the hint Yogesh. It is funny how this never happened to me before without changing the typename from an existing one - that is of course if are careful about linking only your local libraries and not the "original" ones.

I wanted to avoid renaming the class because it is quite a tedious task, but maybe I have no other options if I want to get rid of the error.

Andrea

[Shah Akib Sarwar]

Hello. Could you please elaborate on the solution you used to solve this problem. I am also having the same error message while developing my own solver.

[fmuni]

Originally Posted by Shah Akib Sarwar

Hello. Could you please elaborate on the solution you used to solve this problem. I am also having the same error message while developing my own solver.

This warning is issued when the same class is entered twice in any runTimeSelectionTable. It often happens when you take an existing OF library as a starting point for your own code, because libraries in OF are not independent. They cannot be, but in OpenFOAM they are probably too interdependent. So, check which library you are including is linking to the original lib in the source code and either don't link it or just make a copy of it. Otherwise, you can change all names, which is not a great solution considering you might want to just add a few classes to an enormous library.

[schmidt_d]

One other tip. I have gotten this warning after making my own version of the Lagrangian intermediate library, which I called liblagrangianIntermediateV.so. I was confused to learn that I still had duplicate elements of the built-in intermediate lagrangian library, even though I was certain that my new solver only included my new liblagrangianIntermediateV.so.

The answer to my problems was that the built-in Lagrangian turbulence library included elements from the built-in intermediate library. So I had to make my own Lagrangian turbulence library that referenced my own intermediate library, not the built-in version.

[killua1915]

Can someone give a more clear understanding why this happens and how to resolve this ? I am trying to compile a solver and I am getting following warnings for every possible entry in turbulenceModels library.

Duplicate entry cubeRootVol in runtime table LESdelta
[stack trace]
=============
#1 platforms/linux64GccDPInt32Opt/lib/libFGMFoamTurbulenceModels.so(+0xafd26) [0x7f1600477d26]
#2 /lib64/ld-linux-x86-64.so.2(+0x571f) [0x7f16047e371f]
#3 /lib64/ld-linux-x86-64.so.2(+0x5824) [0x7f16047e3824]
#4 /lib64/ld-linux-x86-64.so.2(+0x1f5a0) [0x7f16047fd5a0]
=============
Duplicate entry Prandtl in runtime table LESdelta
[stack trace]
=============
#1 platforms/linux64GccDPInt32Opt/lib/libFGMFoamTurbulenceModels.so(+0xaffc5) [0x7f1600477fc5]
#2 /lib64/ld-linux-x86-64.so.2(+0x571f) [0x7f16047e371f]
#3 /lib64/ld-linux-x86-64.so.2(+0x5824) [0x7f16047e3824]
#4 /lib64/ld-linux-x86-64.so.2(+0x1f5a0) [0x7f16047fd5a0]

I have made sure that in every Make/files and Make/options new custom library is referenced.

[killua1915]

For anyone wondering how I got rid of these warnings, I renamed all the classes which were mentioned in the warning. Crude approach but it worked. I have tried copying library from src to my local and recompiling it with different name but not sure why it didn't work.