Development issueshttps://develop.openfoam.com/groups/Development/-/issues2023-05-30T17:05:36Zhttps://develop.openfoam.com/Development/openfoam/-/issues/2687Inconsistency in ATCModel treatment2023-05-30T17:05:36ZMartin WertherInconsistency in ATCModel treatment<!--
*** 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 -->
When comparing sensitivity maps obtained with "globally" cancelling the ATC term (ATCModel cancel) to 'standard' formulation with wall-near zeroing operating on both parameters, extraConvection and nSmooth, it was seen that results differ more and more from 'cancel' with increasing values for masking. One would assume the opposite since propagating the masking towards the interior of the domain comes close to cancelling globally.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Simply compare results obtained with 'cancel' option to
- ATCModel {ATCModel standard; zeroATCPatchTypes (wall patch); extraConvection n; nSmooth n; }
- ATCModel {ATCModel standard; zeroATCPatchTypes (wall patch); extraConvection n; nSmooth n+10; }
- ATCModel {ATCModel standard; zeroATCPatchTypes (wall patch); extraConvection n; nSmooth n*100; }
e.g., n = 7.
<!-- ### 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
-->
### What is the current *bug* behaviour?
<!-- What actually happens -->
The current implementation
extraConvection * (adjointConvection - mask * altDiscrAdjointConvection)
leads to an unmatched extraConvection*adjointConvection term in the cells affected by the mask.
### What is the expected *correct* behavior?
<!-- What you should see instead -->
@vaggelisp already proposed patching to
extraConvection * mask * (adjointConvection - altDiscrAdjointConvection)
to ensure consistency in the difference causing the aimed for numerical dissipation.
<!-- ### 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 : v2212|v2206|v2112|v2106|v2012 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
<!--
- OpenFOAM version :
- Operating system :
- Hardware info :
- Compiler :
-->
<!-- ### 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
-->https://develop.openfoam.com/Development/openfoam/-/issues/2683(more) parallel consistency issues with finiteArea2023-02-22T08:29:36ZMark OLESEN(more) parallel consistency issues with finiteAreaAs noted in EP2074 by Jiri and @kuti.As noted in EP2074 by Jiri and @kuti.https://develop.openfoam.com/Development/openfoam/-/issues/2681model cofficients not read2023-02-14T13:00:13ZMark OLESENmodel cofficients not readMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2679Bug in limitVelocity with latest release v2212 - Uname_ not set if keyword U ...2023-02-14T13:00:13ZTobias HolzmannBug in limitVelocity with latest release v2212 - Uname_ not set if keyword U is 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
Hey everybody,
just found a bug in the limitVelocity fvOptions introduced with the commit https://develop.openfoam.com/Development/openfoam/-/commit/48f86809419c2e14883f9390fba4d7f3f95ffe72 by @kuti specifically by removing this line https://develop.openfoam.com/Development/openfoam/-/commit/48f86809419c2e14883f9390fba4d7f3f95ffe72#0ed39fecc176429fc7e14900a867f502ffca27ff_56_73
In the new version, if we don´t specify the U entry, the UName_ variable is not set and we get an warning:
--> FOAM Warning :
From virtual void Foam::fv::option::checkApplied() const
in file cfdTools/general/fvOptions/fvOption.C at line 137
Source limitVelocity defined for field but never used
https://develop.openfoam.com/Development/openfoam/-/blob/master/src/fvOptions/corrections/limitVelocity/limitVelocity.C#L91
### What is the expected *correct* behavior?
Default initialisation for UName_ with "U".
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v2212|v2206|v2112|v2106|v2012 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2212
- Operating system :
- Hardware info :
- Compiler :
### Possible fixes
Given above.
Thanks, TobiKutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2678newer coordSet writer with VTK legacy - incorrect entries2023-02-22T08:29:36ZMark OLESENnewer coordSet writer with VTK legacy - incorrect entriesReported by @PrashantReported by @PrashantMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2677Adding functionobjects/expression to Openfoam v19122023-01-16T00:36:44ZHaitham OsmanAdding functionobjects/expression to Openfoam v1912I have OP v1912 installed on a server. However, expression/fvExpressionField (exprField) utility is NOT installed in the OP v1912. I wonder what is the way to add this feature to OP v1912.
Thanks in advanceI have OP v1912 installed on a server. However, expression/fvExpressionField (exprField) utility is NOT installed in the OP v1912. I wonder what is the way to add this feature to OP v1912.
Thanks in advancehttps://develop.openfoam.com/Development/openfoam/-/issues/2676Documentation of tangential coefficient of restitution in StandardWallInterac...2023-10-04T16:08:21ZDarrin StephensDocumentation of tangential coefficient of restitution in StandardWallInteraction is incorrect### Summary
Documentation of tangential coefficient of restitution in StandardWallInteraction.H is incorrect.
The documentation in the header says
" mu 0; // optional - restitution coeff"
However, if you set mu = 1...### Summary
Documentation of tangential coefficient of restitution in StandardWallInteraction.H is incorrect.
The documentation in the header says
" mu 0; // optional - restitution coeff"
However, if you set mu = 1 then line 234 (v2212) results in the tangential velocity being reduced to zero which is what you should get for a perfectly inelastic collision, i.e. a coefficient of restitution of 1.
" U -= mu_*Ut;"
### What is the current *bug* behaviour?
Setting a value of mu = 1 behaves as a perfectly inelastic collision instead of a perfectly elastic collision.
### What is the expected *correct* behavior?
Setting a value of mu = 1 should not alter the tangential velocity upon impact with the wall. Conversely setting mu = 0 should reduce the particle tangential velocity to that of the patch.
### Possible fixes
The documentation should state the mu is equal to 1 minus the coefficient of restitution. This is how it is implemented in the code.
Or the code (line 234) should be changed so that mu behaves as a coefficient of restitution.Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2674independent handling of MPI_Request2023-01-21T15:02:37ZMark OLESENindependent handling of MPI_RequestThe current handling of MPI_Request is generally based on the idea of handling multiple requests and generally has this type of coding:
```
const label startOfRequests = UPstream::nRequests();
... setup receives
... setup sends
UPstre...The current handling of MPI_Request is generally based on the idea of handling multiple requests and generally has this type of coding:
```
const label startOfRequests = UPstream::nRequests();
... setup receives
... setup sends
UPstream::waitRequests(startOfRequests);
```
However, when we start wishing to intersperse individual non-blocking transfers, we end up with this type of _stuff_:
```
if
(
outstandingRequest >= 0
&& outstandingRequest < UPstream::nRequests()
)
{
UPstream::waitRequest(outstandingRequest);
}
```
The integer value of `outstandingRequest` is from somewhere within the overall list of requests, and internally there is various bits of logic to _recycle_ the freedRequests, with side-effect of allToAll communication being used to re-align things. In summary: a bit of a mess.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2672odd/inconsistent handling of processor patches2023-02-22T10:17:23ZMark OLESENodd/inconsistent handling of processor patchesVarious items, in no particular order:
- processorFaPatchField updateInterfaceMatrix uses `add` to apply `+=` whereas the fv version calls addToInternal with the add value flipped. Looks like a long standing bug, which was inconsistent...Various items, in no particular order:
- processorFaPatchField updateInterfaceMatrix uses `add` to apply `+=` whereas the fv version calls addToInternal with the add value flipped. Looks like a long standing bug, which was inconsistently handled by scalar/non-scalar versions (see commit 0de1df7309).
- processor patchFields have hit/miss approach to transformCoupleField. In some cases the scalar versions are protected with an `is_arithmetic`, but not consistently.
@andy @Mattijs @kutiMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2671Since v2212: reference to typeName is ambiguous (refCast to const fvPatchScal...2024-01-09T11:59:20ZGerasimos ChourdakisSince v2212: reference to typeName is ambiguous (refCast to const fvPatchScalarField)In the [preCICE OpenFOAM adapter, version v1.2.1](https://github.com/precice/openfoam-adapter/tree/v1.2.1), in [this file](https://github.com/precice/openfoam-adapter/blob/v1.2.1/CHT/SinkTemperature.C#L26-L29), I have the following code:...In the [preCICE OpenFOAM adapter, version v1.2.1](https://github.com/precice/openfoam-adapter/tree/v1.2.1), in [this file](https://github.com/precice/openfoam-adapter/blob/v1.2.1/CHT/SinkTemperature.C#L26-L29), I have the following code:
```c++
// Get the boundary field of Temperature on the patch
const fvPatchScalarField& TPatch(
refCast<const fvPatchScalarField>(
T_->boundaryField()[patchID]));
```
This compiles with v2206 (and several previous versions), but fails since v2212, only referencing OpenFOAM-internal code. In both cases, I am using GCC 11.3.0 on Ubuntu 22.04. Error summary:
```text
In file included from /usr/lib/openfoam/openfoam2212/src/OpenFOAM/lnInclude/token.H:49,
from /usr/lib/openfoam/openfoam2212/src/OpenFOAM/lnInclude/Istream.H:50,
from /usr/lib/openfoam/openfoam2212/src/OpenFOAM/lnInclude/ISstream.H:42,
from /usr/lib/openfoam/openfoam2212/src/OpenFOAM/lnInclude/IOstreams.H:41,
from ./Utilities.H:40,
from ./CouplingDataUser.H:4,
from CHT/SinkTemperature.H:4,
from CHT/SinkTemperature.C:1:
/usr/lib/openfoam/openfoam2212/src/OpenFOAM/lnInclude/typeInfo.H: In instantiation of ‘Type& Foam::refCast(U&) [with Type = const Foam::fvPatchField<double>; U = const Foam::fvPatchField<double>]’:
CHT/SinkTemperature.C:28:46: required from here
/usr/lib/openfoam/openfoam2212/src/OpenFOAM/lnInclude/typeInfo.H:151:37: error: reference to ‘const Foam::fvPatchField<double>::typeName’ is ambiguous
151 | << " to type " << Type::typeName
| ^~~~~~~~
```
with candidates being `const char* const Foam::FieldBase::typeName` and `const Foam::word Foam::fvPatchFieldBase::typeName`. [This is the related template](https://develop.openfoam.com/Development/openfoam/-/blob/master/src/OpenFOAM/db/typeInfo/typeInfo.H#L139-156):
```c++
//- A dynamic_cast (for references) that generates FatalError on failed casts,
//- uses the virtual type() method for error messages.
template<class Type, class U>
inline Type& refCast(U& obj)
{
U* p = &obj;
Type* casted = dynamic_cast<Type*>(p);
if (!casted)
{
FatalErrorInFunction
<< "Attempt to cast type " << obj.type()
<< " to type " << Type::typeName
<< abort(FatalError);
}
return *casted;
}
```
I do not completely understand how this is triggered at the moment, but it looks to me like a regression (or I was always doing something wrong).
I do not see anything related in the [Developer Upgrade Guide](https://develop.openfoam.com/Development/openfoam/-/wikis/upgrade/v2212-Developer-Upgrade-Guide).
Full log: [v2212-error.log](/uploads/617292e86bd0276d63ecf5a4d2325243/v2212-error.log)https://develop.openfoam.com/Development/openfoam/-/issues/2670Cannot employ multiple layers of interpolated cells using layerRelax in OpenF...2023-01-13T00:16:16ZKemeng XiCannot employ multiple layers of interpolated cells using layerRelax in OpenFOAM v2212.<!--
*** 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 -->
In the previous version like OpenFOAM v2012, the keyword "layerRelax" in subsection OversetInterpolation in fvSchemes could be used to assign multiple layers as interpolated cells. However, in the latest version v2212, after updating some features in the overset mesh technique, it seems this function cannot be used as usual.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
### Example case
Based on the change on simpleRotor case in \\wsl$\Ubuntu 20.04\usr\lib\openfoam\openfoam2212\tutorials\multiphase\overInterDyMFoam\simpleRotor
<!--
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
-->
### What is the current *bug* behaviour?
I disable the function of pushwalk of the interpolated cells on the background mesh in order to used in v2012 and added the layerRelax 0.5 to assign two layers of interpolated cells.![v2012](/uploads/203a4be6cf9c3f5ac7b6f735d35dd92e/v2012.png)
<!-- What actually happens -->
However, when solved using OpenFOAM v2212, it cannot work:
![v2212](/uploads/2a4d663dc1918a68dd57afa9f5647743/v2212.png)
### What is the expected *correct* behavior?
<!-- What you should see instead -->
### 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 : v2212|v2206|v2112|v2106|v2012 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2212
- Operating system : window WSL, ubuntu 20.4 LTS
### 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
-->Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/2669DES hybrid divergence scheme implementation2022-12-30T11:34:56ZChristoph IrrenfriedDES hybrid divergence scheme implementationHi,
is there a reason for the division of OmegaLim_ with tau0_ in src/TurbulenceModels/schemes/DEShybrid/DEShybrid.H? I can not find that in [1] or [2].
`
tmp<volScalarField> tB =
CH3_*Omega*max(S, Omega)
...Hi,
is there a reason for the division of OmegaLim_ with tau0_ in src/TurbulenceModels/schemes/DEShybrid/DEShybrid.H? I can not find that in [1] or [2].
`
tmp<volScalarField> tB =
CH3_*Omega*max(S, Omega)
/max(0.5*(sqr(S) + sqr(Omega)), sqr(**OmegaLim_/tau0_**));
`
[1] A. Travin, M. Shur, M. Strelets, and P.R. Spalart. Physical and Numerical Upgrades in the Detached-Eddy Simulation of Complex Turbulent Flows. In A_dvances in LES of Complex Flows, volume 65 of Fluid Mechanics and Its Applications_, pages 239–254, Munich, Germany, 2000. Springer Netherlands.
[2] P. Spalart, M.L. Shur, M. Strelets, and A. Travin. Sensitivity of Landing-Gear Noise Predictions by Large-Eddy Simulation to Numerics and Resolution. In _Aerospace Sciences Meetings_, Nashville, Tennessee, 2012.
Thanks and best regards,
Chrishttps://develop.openfoam.com/Development/openfoam/-/issues/2668viewFactorsGen Make/options missing separator error in OpenFOAM v22122023-02-23T08:23:14ZGabriel GerleroviewFactorsGen Make/options missing separator error in OpenFOAM v2212<!--
*** 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 -->
Building OpenFOAM on macOS 11 (x86_64) fails with a `missing separator` error caused by bad formatting in the wmake-generated `build/darwin64ClangDPInt32Optapplications/utilities/preProcessing/viewFactorsGen/options` file.
This problem did not occur with previous releases of OpenFOAM, nor happens on another macOS variant I've tested (macOS 13 on arm64).
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Compile OpenFOAM (specifically, run `applications/utilities/preProcessing/viewFactorsGen/Allwmake`)
### 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 -->
`.../build/darwin64ClangDPInt32Opt/applications/utilities/preProcessing/viewFactorsGen/options:22: *** missing separator` error, where lines 21-22 of that generated file are:
```
EXE_LIBS =
-lfiniteVolume -lsurfMesh -lmeshTools -ldistributed -lradiationModels
```
The newline (with no backslash) after `EXE_LIBS =` explains the error.
### What is the expected *correct* behavior?
<!-- What you should see instead -->
Same lines of the generated `.../viewFactorsGen/options` file on macOS 13 arm64, where this issue doesn't seem to be present:
```
EXE_LIBS = -lfiniteVolume -lsurfMesh -lmeshTools -ldistributed -lradiationModels
```
### 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.
-->
```
wmake viewFactorsGen
54850
found CGAL -- enabling CGAL support.
54851
/Volumes/OpenFOAM-v2212/build/darwin64ClangDPInt32Opt/applications/utilities/preProcessing/viewFactorsGen/options:22: *** missing separator. Stop.
54852
/Volumes/OpenFOAM-v2212/build/darwin64ClangDPInt32Opt/applications/utilities/preProcessing/viewFactorsGen/options:22: *** missing separator. Stop.
54853
wmake error: file '/Volumes/OpenFOAM-v2212/build/darwin64ClangDPInt32Opt/applications/utilities/preProcessing/viewFactorsGen/sourceFiles' could not be created in /Volumes/OpenFOAM-v2212/applications/utilities/preProcessing/viewFactorsGen
54854
make[2]: *** [viewFactorsGen] Error 1
54855
make[1]: *** [preProcessing] Error 2
```
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v2212|v2206|v2112|v2106|v2012 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2212
- Operating system : macOS 11
- Hardware info : x86_64
- Compiler : clang
### 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
-->
Actually deleting [this commented-out line in `applications/utilities/preProcessing/viewFactorsGen/Make/options`]( https://develop.openfoam.com/Development/openfoam/-/blob/66908158ae0c5751c921facd1b817ef4d3603f00/applications/utilities/preProcessing/viewFactorsGen/Make/options#L15) appears to fix the issue when compiling with macOS 11Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2666update of third-party packages for v22122024-01-09T12:05:20ZPrashant Sonakarupdate of third-party packages for v2212Placeholder for listing changes for ThirdParty for v2212
Refer https://develop.openfoam.com/Development/ThirdParty-common/-/commit/7c729298876e7d1a283bc3febaee18a82df0c2fd#aca192678d8f1c8e375af049bcf6fbc3ab1373a2
@mark @andyPlaceholder for listing changes for ThirdParty for v2212
Refer https://develop.openfoam.com/Development/ThirdParty-common/-/commit/7c729298876e7d1a283bc3febaee18a82df0c2fd#aca192678d8f1c8e375af049bcf6fbc3ab1373a2
@mark @andyv2212https://develop.openfoam.com/Development/openfoam/-/issues/2665foamyHexMesh build failure with CGAL 5.52023-01-26T14:30:20ZGabriel GerlerofoamyHexMesh build failure with CGAL 5.5<!--
*** 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
foamyHexMesh will fail to compile with CGAL >= 5.5
### Steps to reproduce
Attempt to compile OpenFOAM with CGAL version >= 5.5
### 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 -->
Compile error due to missing CGAL header file ```"CGAL/Robust_circumcenter_filtered_traits_3.h"``` when processing [`CGALTriangulation3DKernel.H`](https://develop.openfoam.com/Development/openfoam/-/blob/master/applications/utilities/mesh/generation/foamyMesh/conformalVoronoiMesh/conformalVoronoiMesh/CGALTriangulation3DKernel.H#L57)
### What is the expected *correct* behavior?
<!-- What you should see instead -->
Compilation succeeds
### 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.
-->
```
In file included from foamyHexMesh.C:42:
In file included from ../conformalVoronoiMesh/lnInclude/conformalVoronoiMesh.H:46:
In file included from ../conformalVoronoiMesh/lnInclude/CGALTriangulation3Ddefs.H:43:
../conformalVoronoiMesh/lnInclude/CGALTriangulation3DKernel.H:56:14: fatal error: 'CGAL/Robust_circumcenter_filtered_traits_3.h' file not found
#include "CGAL/Robust_circumcenter_filtered_traits_3.h"
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
4 warnings and 1 error generated.
make[3]: *** [/Volumes/OpenFOAM-v2206/build/darwin64ClangDPInt32Opt/applications/utilities/mesh/generation/foamyMesh/foamyHexMesh/foamyHexMesh.o] Error 1
Finish foamyMesh
```
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v2206|v2112|v2106|v2012|v2006 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2206|develop
- Operating system : macOS (note: using the suggested fix in #2664 to avoid that issue)
- Hardware info : arm64
- Compiler : clang
### Possible fixes
The missing `"CGAL/Robust_circumcenter_filtered_traits_3.h"` header was removed from CGAL [in this commit](https://github.com/CGAL/cgal/commit/19162905ebcd8a9683dce46717993eaf577f335a).
Looking at the rest of the changes in that CGAL commit, it seems that the fix is to have `CGALTriangulation3DKernel.H` include `"CGAL/Robust_weighted_circumcenter_filtered_traits_3.h"` instead. I have tried this change and found that it fixes the error.https://develop.openfoam.com/Development/openfoam/-/issues/2664Darwin-specific wmake rule prevents compilation with CGAL 52023-02-21T13:32:14ZGabriel GerleroDarwin-specific wmake rule prevents compilation with CGAL 5<!--
*** 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 -->
Darwin/macOS-specific wmake rule at `wmake/rules/darwin64Clang/cgal` causes macOS builds to fail with a linker error with CGAL versions >= 5
### Steps to reproduce
Compile OpenFOAM on macOS with CGAL version >= 5
Note: CGAL versions >= 5.5 are also affected by #2665
### 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 -->
Linker error `ld: library not found for -lCGAL` (note: CGAL >= 5 is header-only)
### What is the expected *correct* behavior?
<!-- What you should see instead -->
Build succeeds
### 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.
-->
```
wmake PolyhedronReader
link: /Volumes/OpenFOAM-v2206/platforms/darwin64ClangDPInt32Opt/lib/libPolyhedronReader.dylib
ld: library not found for -lCGAL
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[3]: *** [/Volumes/OpenFOAM-v2206/platforms/darwin64ClangDPInt32Opt/lib/libPolyhedronReader.dylib] Error 1
make[2]: *** [surfaceBooleanFeatures] Error 2
make[1]: *** [surface] Error 2
```
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v2206|v2112|v2106|v2012|v2006 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2206|v2112|master|develop
- Operating system : macOS
- Hardware info : arm64|x86_64
- Compiler : clang
### 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
-->
Delete the [`wmake/rules/darwin64Clang/cgal` file](https://develop.openfoam.com/Development/openfoam/-/blob/8993af73ac6e58fd9741a3accc8e52eeb37e40ee/wmake/rules/darwin64Clang/cgal). I have tried this and can report that OpenFOAM will build with CGAL 5 on macOS if this specific file is deleted.
Additional note: the `wmake/rules/darwin64Clang/cgal` rule seems to be written for CGAL 4 (i.e., before CGAL went header-only). ~~I'm aware that, as of the current `develop` branch, OpenFOAM won't build with CGAL 4.x anymore (at least on macOS), so this fix becomes more important for macOS users.~~ EDIT: this last part doesn't seem to be true as of v2212, but CGAL 4 is now an old version anywayMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2663surface noise writing blocks!2022-12-19T17:05:02ZMark OLESENsurface noise writing blocks!with changes from d69ac516e8062d875172c422fe7374a3eafdd911 - now have blocking when writing surfaces
reported by @Prashantwith changes from d69ac516e8062d875172c422fe7374a3eafdd911 - now have blocking when writing surfaces
reported by @PrashantMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2661Color for compiler errors2022-12-19T15:50:21ZGerasimos ChourdakisColor for compiler errorsWhen building OpenFOAM-based code, I notice that GCC does not use any color (which is the default behavior), making it sometimes difficult to read error messages. I am not sure which compilation rule could be overriding the default behav...When building OpenFOAM-based code, I notice that GCC does not use any color (which is the default behavior), making it sometimes difficult to read error messages. I am not sure which compilation rule could be overriding the default behavior or why, but I can get color if I pass `-fdiagnostics-color=always` to the compiler options.
Questions:
1. Is this explicitly disabled for some reason? I can imagine that some terminals don't interpret colors by default.
2. Where would it be the most appropriate to set this for:
- my system (globally)? An environment variable for extra compiler flags would be very useful.
- my OpenFOAM-based code? We typically have `EXE_INC` (meant for includes) and `LIB_LIBS` (meant for the libraries). Is there anything else?
3. If revisiting (1) is worth it: does it make sense enabling colorization by default in OpenFOAM for GCC?https://develop.openfoam.com/Development/openfoam/-/issues/2658BUG: 360af221fe causes instabilities in kEpsilon2022-12-19T14:53:18ZKutalmış BerçinBUG: 360af221fe causes instabilities in kEpsilonRun `$FOAM_TUTORIALS/incompressible/simpleFoam/turbulentFlatPlate/Allrun` with `kEpsilon` and `grading_vs_yp[10]=130`, `grading_vs_yp[100]=5` only.
360af221fe leads to failures for these yPlus={10,100} cases.
Related to #2642
@andy
E...Run `$FOAM_TUTORIALS/incompressible/simpleFoam/turbulentFlatPlate/Allrun` with `kEpsilon` and `grading_vs_yp[10]=130`, `grading_vs_yp[100]=5` only.
360af221fe leads to failures for these yPlus={10,100} cases.
Related to #2642
@andy
EDIT: Or the fix has just revealed the existing instability-prone behaviour in `kEpsilon`.
EDIT-2: The other tutorial that was affected: `incompressible/simpleFoam/windAroundBuildings`v2306https://develop.openfoam.com/Development/openfoam/-/issues/2657snappyMultiRegionHeaterImplicit does not constrain decomposition2022-12-23T13:52:22ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comsnappyMultiRegionHeaterImplicit does not constrain decomposition<!--
*** 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 -->
The heatTransfer/chtMultiRegionFoam/snappyMultiRegionHeaterImplicit does not use faceZones to constrain the decomposition. Hence it might lead to errors in the implicit solution (.. lduAssembly267 .. incorrect number of faces)
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Seems to depend on the scotch level. My version does not showcase problem.
### 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
-->
See tutorial case.
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v2206|v2112|v2106|v2012|v2006 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2206
### 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
-->
Use the faceZones generated by snappyHexMesh directly or have the topoSet step generate faceZones instead of currently faceSets.Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.com