Below follows my notes for investigating the problem with RTS duplicate warnings in the solver log files of TwoPhaseFlow.
The problem:
When running any of the solvers with postProcess linked in the controlDict or the multiRegionPhaseChangeFlow solver even without postProcess linked, one gets Runtime selection table duplicate entry warnings for reconstructionSchemes in the top of the log file. This is because they are added to the table both by TwoPhaseFlow's libVoF.so and by OpenFOAM's libgeometricVoF.so.
It is important to note that solvers seem to run fine using the correct versions of the schemes, so this is only an annoying polution of the log file. The simulations still run as they should although the end with a crash after finalising because of the duplicate entries.
An example:
From TwoPhaseFlow's run/depthCharge2D case log file:
Create time
Duplicate entry isoAlpha in runtime table reconstructionSchemes
[stack trace]
=============
#1 platforms/linux64GccDPInt32Opt/lib/libgeometricVoF.so(+0x48509) [0x74cfce300509]
#2 /lib64/ld-linux-x86-64.so.2(+0x647e) [0x74cfdaabe47e]
...
=============
Duplicate entry gradAlpha in runtime table reconstructionSchemes
[stack trace]
=============
#1 platforms/linux64GccDPInt32Opt/lib/libgeometricVoF.so(+0x485f9) [0x74cfce3005f9]
...
=============
Duplicate entry plicRDF in runtime table reconstructionSchemes
[stack trace]
=============
#1 platforms/linux64GccDPInt32Opt/lib/libgeometricVoF.so(+0x486e9) [0x74cfce3006e9]
...
=============
Duplicate entry interface in runtime table sampledSurface
[stack trace]
=============
#1 platforms/linux64GccDPInt32Opt/lib/libpostProcess.so(+0x6b9a9) [0x74cfcf0b99a9]
...
=============
Create mesh for time = 0
The above example is with OpenFOAM-v2512 but older versions show similar similar warnings.
Investigation:
With lddtree I found that compressibleInterFlow does not have geometricVoF linked in.
But the depthDiscarge2D case has TwoPhaseFlow's libpostProcess.so in controlDict.
lddtree on libpostProcess.so gives:
postProcess => fieldFunctionObjects => incompressibleMultiphaseSystems => geometricVoF
The multiRegionPhaseChangeFlow solver gives the same problem even without the postProcess in controlDict.
A case showing the problem is: testsuite/cht/fixedFlux (run it and inspect top of log file).
Doing lddtree on multiRegionPhaseChangeFlow gives:
multiRegionPhaseChangeFlow => libthermoTools.so => libincompressibleMultiphaseSystems.so => libgeometricVoF.so
Where does incompressibleMultiphaseSystems need something from geometricVoF?
Answer:
$ grep -r "cutCellIso " src/phaseSystemModels/multiphaseInter/phasesSystem/
src/phaseSystemModels/multiphaseInter/phasesSystem/massTransferModels/kineticGasEvaporation/kineticGasEvaporation.C: cutCellIso cutCell(mesh, ap);
src/phaseSystemModels/multiphaseInter/phasesSystem/massTransferModels/interfaceOxideRate/interfaceOxideRate.C: cutCellIso cutCell(mesh, ap);
src/phaseSystemModels/multiphaseInter/phasesSystem/massTransferModels/diffusionGasEvaporation/diffusionGasEvaporation.C: cutCellIso cutCell(mesh, ap);
src/phaseSystemModels/multiphaseInter/phasesSystem/massTransferModels/interfaceHeatResistance/interfaceHeatResistance.C: cutCellIso cutCell(mesh, ap);
These models use cutCellIso to estimate the surface area inside cells.
These are the only uses of geometricVoF stuff in the whole incompressibleMultiphaseSystems library.
Possible fix:
Removing incompressibleMultiphaseSystems dependency on geometricVoF:
I found a minimal fix which is to add -I${LIB_SRC}/transportModels/geometricVoF/lninclude to:
src/phaseSystemModels/multiphaseInter/phasesSystem/Make/options
and include C files from $(LIB_SRC)/transportModels/geometriVoF/cutCells/ here:
src/phaseSystemModels/multiphaseInter/phasesSystem/Make/files
(note that similar changes could be done to these to free them of geometricVoF dependency: src/optimisation/adjointOptimisation/adjoint/Make/files
src/optimisation/adjointOptimisation/adjoint/Make/options).
With this, one can remove -lgeometricVoF from incompressibleMultiphaseSystems's Make/options file. But this breaks the OpenFOAM convention of a library only including its own C files in Make/files.
There is also the option of taking cutCell stuff out of geometricVoF and compile it into a separate library that can then be linked by incompressibleMultiphaseSystems instead of geometricVoF. This would solve the problem, but is potentially unkind to downstream geometricVoF users.
To be continued...
Below follows my notes for investigating the problem with RTS duplicate warnings in the solver log files of TwoPhaseFlow.
The problem:
When running any of the solvers with postProcess linked in the controlDict or the multiRegionPhaseChangeFlow solver even without postProcess linked, one gets Runtime selection table duplicate entry warnings for reconstructionSchemes in the top of the log file. This is because they are added to the table both by TwoPhaseFlow's libVoF.so and by OpenFOAM's libgeometricVoF.so.
It is important to note that solvers seem to run fine using the correct versions of the schemes, so this is only an annoying polution of the log file. The simulations still run as they should although the end with a crash after finalising because of the duplicate entries.
An example:
From TwoPhaseFlow's run/depthCharge2D case log file:
The above example is with OpenFOAM-v2512 but older versions show similar similar warnings.
Investigation:
With lddtree I found that compressibleInterFlow does not have geometricVoF linked in.
But the depthDiscarge2D case has TwoPhaseFlow's libpostProcess.so in controlDict.
lddtree on libpostProcess.so gives:
postProcess => fieldFunctionObjects => incompressibleMultiphaseSystems => geometricVoF
The multiRegionPhaseChangeFlow solver gives the same problem even without the postProcess in controlDict.
A case showing the problem is: testsuite/cht/fixedFlux (run it and inspect top of log file).
Doing lddtree on multiRegionPhaseChangeFlow gives:
multiRegionPhaseChangeFlow => libthermoTools.so => libincompressibleMultiphaseSystems.so => libgeometricVoF.so
Where does incompressibleMultiphaseSystems need something from geometricVoF?
Answer:
These models use cutCellIso to estimate the surface area inside cells.
These are the only uses of geometricVoF stuff in the whole incompressibleMultiphaseSystems library.
Possible fix:
Removing incompressibleMultiphaseSystems dependency on geometricVoF:
I found a minimal fix which is to add -I${LIB_SRC}/transportModels/geometricVoF/lninclude to:
and include C files from $(LIB_SRC)/transportModels/geometriVoF/cutCells/ here:
(note that similar changes could be done to these to free them of geometricVoF dependency: src/optimisation/adjointOptimisation/adjoint/Make/files
src/optimisation/adjointOptimisation/adjoint/Make/options).
With this, one can remove -lgeometricVoF from incompressibleMultiphaseSystems's Make/options file. But this breaks the OpenFOAM convention of a library only including its own C files in Make/files.
There is also the option of taking cutCell stuff out of geometricVoF and compile it into a separate library that can then be linked by incompressibleMultiphaseSystems instead of geometricVoF. This would solve the problem, but is potentially unkind to downstream geometricVoF users.
To be continued...