Development issueshttps://develop.openfoam.com/groups/Development/-/issues2021-08-04T13:32:32Zhttps://develop.openfoam.com/Development/openfoam/-/issues/2122BUG: DMD: snapshot0 becomes lost due to purgeWrite2021-08-04T13:32:32ZKutalmış BerçinBUG: DMD: snapshot0 becomes lost due to purgeWrite<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be re...<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be rendered on the platform by using the
"preview" tab above
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
<!-- Summarize the bug encountered concisely -->
`IOField<scalar> snapshot0` is the so-called first snapshot required by mode-sorting algorithms of DMD at the end of a process. We have been storing the set of associated data in the first execution time of a given DMD FO - to avoid keeping it in the memory all along a simulation - but this data is discarded whenever `purgeWrite` is activated.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Enable `purgeWrite 1;` in `$FOAM_TUTORIALS/incompressible/pimpleFoam/laminar/cylinder2D`, and `./Allrun`.
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v1806|v1812|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
```
api = 2103
patch = 210414
HEAD = 02f255b3d6
version = com
compiler = Clang (system)
= clang version 9.0.1
mpi = SYSTEMOPENMPI
= mpirun (Open MPI) 1.10.7.0.5e373bf1fd
OS = Description: openSUSE Leap 15.1
opts = linux64ClangDPInt32Opt
```
### Possible fixes
<!--
If you can, link to the line of code that might be responsible for the
problem
The "/label ~bug" text is a gitlab flag that will add the "bug" label to this
issue
-->
Changing the IO address of `IOField<scalar> snapshot0` to something which cannot be overwritten by `purgeWrite`, may be to `0`.Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2124potentialFoam tutorials call2021-06-24T14:47:48ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.compotentialFoam tutorials call### Functionality to add/problem to solve
potentialFoam tutorials call streamFunction FO even though there is no flux field.
Either
- remove call to postProcess -streamFunction from scripts
- or add -writephi to force potentialFoam wri...### Functionality to add/problem to solve
potentialFoam tutorials call streamFunction FO even though there is no flux field.
Either
- remove call to postProcess -streamFunction from scripts
- or add -writephi to force potentialFoam writingMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/2125injectorPipe : initial blockMesh should not have 'empty' patches2021-06-28T16:43:45ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.cominjectorPipe : initial blockMesh should not have 'empty' patches### Functionality to add/problem to solve
When using blockMesh to generate the initial block of cells for use in snappyHexMesh: in some cases the initial patches are not present in the snappyHexMesh. If so one can use the 'defaultFaces'...### Functionality to add/problem to solve
When using blockMesh to generate the initial block of cells for use in snappyHexMesh: in some cases the initial patches are not present in the snappyHexMesh. If so one can use the 'defaultFaces' fall-back for automatic patching of the outside faces. However the defaultFaces should not have a constraint type (e.g. 'empty') since this automatically implies some constraint (e.g. 1D/2D ness in case of empty). Instead use a generic 'patch' type. (the actual type does not matter since these patches are removed during the running of snappyHexMesh)Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/2126more consistent version output2021-09-09T16:16:25ZMark OLESENmore consistent version outputCurrently output the WM_PROJECT_VERSION in the top banner, but probably more reasonable to have the current API value instead.
Can recover the WM_PROJECT_VERSION in the "Build: ... " output.Currently output the WM_PROJECT_VERSION in the top banner, but probably more reasonable to have the current API value instead.
Can recover the WM_PROJECT_VERSION in the "Build: ... " output.v2112Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2127rigidBodyMeshMotion accesses CofG even if CofG object not specified2021-06-28T16:43:45ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comrigidBodyMeshMotion accesses CofG even if CofG object not specified<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be re...<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be rendered on the platform by using the
"preview" tab above
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
<!-- Summarize the bug encountered concisely -->
rigidBodyMeshMotion saves the CofG of even if not needed. This causes problems whilst checking for whether the body supplying the CofG is actually valid.
### Steps to reproduce
multiphase/overInterDyMFoam/boatAndPropeller tutorial
### What is the current *bug* behaviour?
<!-- What actually happens -->
Out-of-bounds access if bodyId of CofG is negative.
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v1806|v1812|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2103
### Possible fixes
<!--
If you can, link to the line of code that might be responsible for the
problem
The "/label ~bug" text is a gitlab flag that will add the "bug" label to this
issue
-->
do not access rigidBodyMeshMotion::bodyIdCofG_ unless needed.
@SergioMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/2129surfaceFieldValue with vector weights blocks in parallel2021-06-18T15:34:05ZMark OLESENsurfaceFieldValue with vector weights blocks in parallel@Prashant noticed this one. Bug introduced by ab692caf7cb.
Execution branches become de-synchronized and it blocks.@Prashant noticed this one. Bug introduced by ab692caf7cb.
Execution branches become de-synchronized and it blocks.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2130haloToCell improvements2021-06-21T09:23:26ZMark OLESENhaloToCell improvementsAs noted in !463, the haloToCell is currently too rigid. It enforces grow/shrink step of at least 1, can also show some issues with parallel-synchronization.As noted in !463, the haloToCell is currently too rigid. It enforces grow/shrink step of at least 1, can also show some issues with parallel-synchronization.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2132BUG: turbulenceFields: Local omega funcs are unused2021-08-04T13:32:32ZKutalmış BerçinBUG: turbulenceFields: Local omega funcs are unused<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be re...<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be rendered on the platform by using the
"preview" tab above
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
<!-- Summarize the bug encountered concisely -->
- turbulenceFields.C#L185-188
```
case cfOmega:
{
processField<scalar>(f, omega(model));
break;
}
```
calls the `omega` of `turbulenceFields` rather than `model.omega()`.
- Another issue is that using `simulationType laminar;`, albeit unrealistic, unforgivingly throws fatal error - ceasing simulation.
- Also, the `nuTilda` expression of `turbulenceFields` is incorrect. `nuTilda` is not equal to `k/omega`:
```
template<class Model>
Foam::tmp<Foam::volScalarField>
Foam::functionObjects::turbulenceFields::nuTilda
(
const Model& model
) const
{
return tmp<volScalarField>::New
(
"nuTilda.tmp",
model.k()/omega(model)
);
}
```
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v1806|v1812|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
```
base1 = develop
api = 2106
patch = 0
HEAD = 3825c4ee95
version = com
compiler = Clang (system)
= clang version 9.0.1
mpi = SYSTEMOPENMPI
= mpirun (Open MPI) 1.10.7.0.5e373bf1fd
OS = Description: openSUSE Leap 15.1
opts = linux64ClangDPInt32Opt
```v2112Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2133noise - write in vtk format2021-07-20T15:06:29ZPrashant Sonakarnoise - write in vtk formatAttached case showing issue in vtk LEGACY writing while the EnSight works.
The script as well as logs are in the attachment.[pitzDaily.tgz](/uploads/de0f7a27c459a0bb44fd9889779fa6d8/pitzDaily.tgz)Attached case showing issue in vtk LEGACY writing while the EnSight works.
The script as well as logs are in the attachment.[pitzDaily.tgz](/uploads/de0f7a27c459a0bb44fd9889779fa6d8/pitzDaily.tgz)https://develop.openfoam.com/Development/openfoam/-/issues/2134ENH: parameterization of hopper blockMeshDict2021-08-04T13:32:32ZBas NieuwboerENH: parameterization of hopper blockMeshDictI've parameterized the blockMeshDict for the hopper simulations for a own case using the variables and the modern #eval function. This makes the blockMeshDict much more readable and could serve as a template for users writing blockMeshDi...I've parameterized the blockMeshDict for the hopper simulations for a own case using the variables and the modern #eval function. This makes the blockMeshDict much more readable and could serve as a template for users writing blockMeshDicts. Would it be possible to push this the develop version? I can imagine it is a hectic time during the release. Just let this sit until afterwards.[blockMeshDict](/uploads/c92998237391570c7b682a297f52517d/blockMeshDict)Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2135MRFzoneTemplate.C issue2021-06-23T15:01:59ZAshutosh MauryaMRFzoneTemplate.C issueHi ,
I was compiling OpenFoam Adapter from https://precice.org/ . The compiler requires to include certain headers from openFoam. The compilation failed ,I reported it to their forum they said that is not issue with openFoam adapter. I a...Hi ,
I was compiling OpenFoam Adapter from https://precice.org/ . The compiler requires to include certain headers from openFoam. The compilation failed ,I reported it to their forum they said that is not issue with openFoam adapter. I am attaching wmake.log file for more info.
OpenFoam Version: 2012
OS: Ubuntu 20.04 on WSL
[wmake.log](/uploads/09b88701e47a56a5b6a76a8300529465/wmake.log)Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2137topoSet sources bypass bitSet2021-06-23T08:45:08ZMark OLESENtopoSet sources bypass bitSetwe have various source (labelHashSet, zones, bitSet). If these are passed straight through, the combine operations might pick up the wrong contents.
Mostly not a problem, except with things like haloToCell which starts from the given set.we have various source (labelHashSet, zones, bitSet). If these are passed straight through, the combine operations might pick up the wrong contents.
Mostly not a problem, except with things like haloToCell which starts from the given set.Sergio FerrarisSergio Ferrarishttps://develop.openfoam.com/Development/openfoam/-/issues/2138fan boundary condition : issue in post process mode2021-06-25T08:09:56ZPrashant Sonakarfan boundary condition : issue in post process modePlease find attached case to replicate the issue.[TJunctionFan.tgz](/uploads/3a7892939f85494e4fcfe77a288c8a8a/TJunctionFan.tgz)Please find attached case to replicate the issue.[TJunctionFan.tgz](/uploads/3a7892939f85494e4fcfe77a288c8a8a/TJunctionFan.tgz)https://develop.openfoam.com/Development/openfoam/-/issues/2140Unable to run flowover cylinder tutorial in potentialFoam using Allrun2021-06-25T18:40:16ZAshutosh MauryaUnable to run flowover cylinder tutorial in potentialFoam using AllrunI tried to run flow over Cylinder using Allrun this giving me error (more in log file attached). This Issue similar to my previous issue.
OpenFoam Version: 2012
OS: Ubuntu 20.04 on WSL
Compiler : 9.3.0 (Ubuntu 9.3.0-17ubuntu1~20.04)
...I tried to run flow over Cylinder using Allrun this giving me error (more in log file attached). This Issue similar to my previous issue.
OpenFoam Version: 2012
OS: Ubuntu 20.04 on WSL
Compiler : 9.3.0 (Ubuntu 9.3.0-17ubuntu1~20.04)
[log.potentialFoam](/uploads/30b1885ece4619ef3439642a5812b67a/log.potentialFoam)Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2142BUG: liquidProperties: reading wrong type of coefficients2021-07-20T15:06:29ZDanielBUG: liquidProperties: reading wrong type of coefficients<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be re...<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be rendered on the platform by using the
"preview" tab above
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
Class liquidProperties reads coefficients using [label type instead of scalar](https://develop.openfoam.com/Development/openfoam/-/blob/master/src/thermophysicalModels/thermophysicalProperties/liquidProperties/liquidProperties/liquidProperties.C#L75).
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v1806|v1812|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : dev
<!--
If you can, link to the line of code that might be responsible for the
problem
The "/label ~bug" text is a gitlab flag that will add the "bug" label to this
issue
-->Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2143Build system includes non-existent directories2021-07-08T07:02:35ZIlya PopovBuild system includes non-existent directoriesI have checked out the OpenFOAM-v2106 tag. I have inspected the build system, and found that a few Make/options files contain include flags with non-existent directories. Hereafter these are listed:
- [`src/lagrangian/turbulence/Make/op...I have checked out the OpenFOAM-v2106 tag. I have inspected the build system, and found that a few Make/options files contain include flags with non-existent directories. Hereafter these are listed:
- [`src/lagrangian/turbulence/Make/options`](https://develop.openfoam.com/Development/openfoam/-/blob/OpenFOAM-v2106/src/lagrangian/turbulence/Make/options#L14) includes non-existent `src/thermophysicalModels/radiationModels/lnInclude`
- [`src/transportModels/interfaceProperties/Make/options`](https://develop.openfoam.com/Development/openfoam/-/blob/OpenFOAM-v2106/src/transportModels/interfaceProperties/Make/options#L3) includes non-existent `src/transportModels/twoPhaseProperties/alphaContactAngle/alphaContactAngle`
- [`src/regionModels/regionCoupling/Make/options`](https://develop.openfoam.com/Development/openfoam/-/blob/OpenFOAM-v2106/src/regionModels/regionCoupling/Make/options#L16) includes non-existent `src/thermophysicalModels/solid/lnInclude` and `src/turbulenceModels/lnInclude`
- [`src/regionModels/thermalBaffleModels/Make/options`](https://develop.openfoam.com/Development/openfoam/-/blob/OpenFOAM-v2106/src/regionModels/thermalBaffleModels/Make/options) includes non-existent `src/AMIInterpolation/lnInclude`
- [`src/regionModels/pyrolysisModels/Make/options`](https://develop.openfoam.com/Development/openfoam/-/blob/OpenFOAM-v2106/src/regionModels/pyrolysisModels/Make/options#L11) includes non-existent `src/turbulenceModels/lnInclude`
- [`src/thermophysicalModels/chemistryModel/Make/options`](https://develop.openfoam.com/Development/openfoam/-/blob/OpenFOAM-v2106/src/thermophysicalModels/chemistryModel/Make/options#L10) includes non-existent `src/thermophysicalModels/functions/Polynomial` and `src/thermophysicalModels/thermophysicalFunctions/lnInclude`
- [`src/thermophysicalModels/thermophysicalPropertiesFvPatchFields/liquidProperties/Make/options`](https://develop.openfoam.com/Development/openfoam/-/blob/OpenFOAM-v2106/src/thermophysicalModels/thermophysicalPropertiesFvPatchFields/liquidProperties/Make/options#L4) includes non-existent `src/thermophysicalModels/thermophysicalFunctions/lnInclude`
Given the fact that OpenFOAM builds successfully with these wrong includes, it looks like these are extraneous and can be safely removed.https://develop.openfoam.com/Development/openfoam/-/issues/2144catching fails with bad input (fluxSummary)2021-11-25T08:12:30ZMark OLESENcatching fails with bad input (fluxSummary)As raised on EP1510, using `errors` handling in fluxSummary does not work.
With an empty or missing surface, it still tries a `lookupObject` for the phi field. Within objectRegistry this lookup failure triggers an `abort(FatalError)`, wh...As raised on EP1510, using `errors` handling in fluxSummary does not work.
With an empty or missing surface, it still tries a `lookupObject` for the phi field. Within objectRegistry this lookup failure triggers an `abort(FatalError)`, which cannot be caught.
Possible fixes:
- downgrade abort() to exit()? ... maybe not good
- check for field iff the surface actually has faces
- use cfind instead of lookup within fluxSummary
- a second template parameter on lookupObject: `template <class Type, bool Abort=true> lookupObject( ... )`
Related to #1779Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2145cyclicPeriodicAMI does not transform contributions2021-09-16T17:49:21ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comcyclicPeriodicAMI does not transform contributions<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be re...<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be rendered on the platform by using the
"preview" tab above
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
<!-- Summarize the bug encountered concisely -->
cyclicPeriodicAMI uses underlying cyclicAMI to do area weighted interpolation. It uses an underlying patch to provide a transform for the geometry to obtain full coverage. It however does not use this transform to do interpolation so non-scalar properties are interpolated incorrectly (if using a rotational periodicity, not for planar periodicity)
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
tutorial combustion/XiDyMFoam/annularCombustorTurbine
Check any of the tangential components of the velocity.
### What is the current *bug* behaviour?
<!-- What actually happens -->
Discontinuity (in the tangential component) where the target is partially overlapped so it requires another transform to do full coverage.
### What is the expected *correct* behavior?
<!-- What you should see instead -->
No discontinuity.
### Relevant logs and/or images
<!--
Paste any relevant logs - please use code blocks (```) to format console
output, logs, and code as it's very hard to read otherwise.
-->
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v1806|v1812|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2106
### Possible fixes
<!--
If you can, link to the line of code that might be responsible for the
problem
The "/label ~bug" text is a gitlab flag that will add the "bug" label to this
issue
-->
Ideas:
- have multiple AMI, each with their own transformation
- tag AMI addressing with their transformation
- interpolate in cylindrical coordinate system (produces slight inconsistency between weights (since from overlap areas calculated in global coordinate system) and values)
@andy @PrashantMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/2146Compilation of meshTools/searchableSurfaces/searchableSphere/searchableSphere...2021-07-23T09:39:23ZPhilip CardiffCompilation of meshTools/searchableSurfaces/searchableSphere/searchableSphere.C needs "#include <array>" with clang 12.0.5 (macOS)<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be re...<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be rendered on the platform by using the
"preview" tab above
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
<!-- Summarize the bug encountered concisely -->
On OpenFOAM-v2012, ${FOAM_SRC}/meshTools/searchableSurfaces/searchableSphere/searchableSphere.C requires that the "#include \<array\>" header is added to the top of the file when compiling with clang 12.0.5 (macOS 11.4, arm).
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Try compile OpenFOAM-v2012 on a case-sensitive partition on macOS 11.4 (arm) using Clang, Apple clang version 12.0.5 (clang-1205.0.22.9).
### Example case
<!--
If possible, please create a SMALL example and attach it to your report
If you are using an older version of OpenFOAM this will also determine
whether the bug has been fixed in a more recent version
-->
N/A
### What is the current *bug* behaviour?
<!-- What actually happens -->
Compilation error.
### What is the expected *correct* behavior?
<!-- What you should see instead -->
It compiles :)
### Relevant logs and/or images
<!--
Paste any relevant logs - please use code blocks (```) to format console
output, logs, and code as it's very hard to read otherwise.
-->
N/A
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v1806|v1812|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2012
- Operating system : macOS 11.4 (arm)
- Hardware info : Apple m1 arm CPU
- Compiler : Apple clang version 12.0.5 (clang-1205.0.22.9), with target arm64-apple-darwin20.5.0
### Possible fixes
<!--
If you can, link to the line of code that might be responsible for the
problem
The "/label ~bug" text is a gitlab flag that will add the "bug" label to this
issue
-->
Line 528 in searchableSphere.C causes the error:
```
std::array<uint8_t, 3> idx{0, 1, 2};
```
A quick fix is to add the array header at the top of the file:
```
#include "searchableSphere.H"
#include "addToRunTimeSelectionTable.H"
#include <array>
```https://develop.openfoam.com/Development/openfoam/-/issues/2147Compilation - linker issue2022-06-24T13:19:22ZVojtech BetakCompilation - linker issueDear developers,
I observe some compilation - linker issue when I am compiling OpenFOAM-v2106 on openSUSE Tumbelweed. The src directory is compiled without significant problems but the applications directory is not possible to compile a...Dear developers,
I observe some compilation - linker issue when I am compiling OpenFOAM-v2106 on openSUSE Tumbelweed. The src directory is compiled without significant problems but the applications directory is not possible to compile and end with the following error message
```
/usr/lib64/gcc/x86_64-suse-linux/11/../../../../x86_64-suse-linux/bin/ld: /home/betak/OpenFOAM/OpenFOAM-v2106/platforms/linux64GccDPInt32Opt/lib/libcompressibleTurbulenceModels.so: undefined reference to `Foam::fv::convectionScheme<Foam::SymmTensor<double> >::IstreamConstructorTablePtr_[abi:cxx11]'
/usr/lib64/gcc/x86_64-suse-linux/11/../../../../x86_64-suse-linux/bin/ld: /home/betak/OpenFOAM/OpenFOAM-v2106/platforms/linux64GccDPInt32Opt/lib/libfiniteVolume.so: undefined reference to `Foam::pointPatchField<Foam::SphericalTensor<double> >::dictionaryConstructorTablePtr_[abi:cxx11]'
/usr/lib64/gcc/x86_64-suse-linux/11/../../../../x86_64-suse-linux/bin/ld: /home/betak/OpenFOAM/OpenFOAM-v2106/platforms/linux64GccDPInt32Opt/lib/libreactionThermophysicalModels.so: undefined reference to `Foam::Reaction<Foam::polynomialTransport<Foam::species::thermo<Foam::hPolynomialThermo<Foam::icoPolynomial<Foam::specie, 8>, 8>, Foam::sensibleEnthalpy>, 8> >::dictionaryConstructorTablePtr_[abi:cxx11]'
```
To verify this issue, I have tried to compile an older version of OpenFOAM(OpenFOAM-v2012) and this compilation was successful
Thank a lot
With regards
Vojtech BetakMark OLESENMark OLESEN