Development issueshttps://develop.openfoam.com/groups/Development/-/issues2023-01-24T20:50:07Zhttps://develop.openfoam.com/Development/openfoam/-/issues/2682Large time step continuity error in first time step with reactingFoam2023-01-24T20:50:07ZJan GärtnerLarge time step continuity error in first time step with reactingFoam### Summary
Large time step continuity error in reactingFoam due to missing old time in thermo::psi field.
When running the tutorial tutorials/combustion/reactingFoam/laminar/counterFlowFlame2D, a large time step continuity error appea...### Summary
Large time step continuity error in reactingFoam due to missing old time in thermo::psi field.
When running the tutorial tutorials/combustion/reactingFoam/laminar/counterFlowFlame2D, a large time step continuity error appears in the first iteration. This is independent if it starts from 0 or from a later time step.
The error could be traced back to the `thermo.correct()` function called in the energy equation. There the values of the fields, especially the compressibility psi, are overwritten with new values based on the newly calculated temperature and known pressure. Even though `GeometricField<>::primitiveFieldRef()` is called the old time field is **not** updated because no current old time pointer exists, see also `void Foam::GeometricField<Type, PatchField, GeoMesh>::storeOldTimes()`.
This can be prevented by forcing an oldTime pointer to exist by calling in thermo::correct() `this->psi_.oldTime()`, as had been done in e.g. OpenFOAM 5.x. Adding this line to the thermo::correct() function of hePsiThermo.C would reduce the observed error!
### Steps to reproduce
Run tutorials/combustion/reactingFoam/laminar/counterFlowFlame2D and observe the time continuity error in the first time step. Then add the line
```
this->psi_.oldTime
```
to hePsiThermo::correct() and the error is reduced. It is also possible to check by printing out the number of old time values stored of psi before the energy equation, after the energy equation and after the pressure equation. It clearly shows, that only after it is solved for in the pressure equation with `fvm::ddt(psi,p)` it has the old time fields.
### Relevant logs and/or images
#### Example output of the first time step
```
Starting time loop
Courant Number mean: 2.73409e-05 max: 0.00175681
deltaT = 1.19999e-06
Time = 1.19999e-06
diagonal: Solving for rho, Initial residual = 0, Final residual = 0, No Iterations 0
PIMPLE: iteration 1
DILUPBiCGStab: Solving for O2, Initial residual = 1, Final residual = 1.02704e-09, No Iterations 1
DILUPBiCGStab: Solving for H2O, Initial residual = 0, Final residual = 0, No Iterations 0
DILUPBiCGStab: Solving for CH4, Initial residual = 1, Final residual = 1.0339e-09, No Iterations 1
DILUPBiCGStab: Solving for CO2, Initial residual = 0, Final residual = 0, No Iterations 0
DILUPBiCGStab: Solving for h, Initial residual = 1, Final residual = 4.10484e-09, No Iterations 1
min/max(T) = 293, 2000
DICPCG: Solving for p, Initial residual = 1, Final residual = 0.0488686, No Iterations 5
diagonal: Solving for rho, Initial residual = 0, Final residual = 0, No Iterations 0
time step continuity errors : sum local = 0.000333765, global = -0.000330463, cumulative = -0.000330463
DICPCG: Solving for p, Initial residual = 0.0147831, Final residual = 6.72619e-07, No Iterations 12
diagonal: Solving for rho, Initial residual = 0, Final residual = 0, No Iterations 0
time step continuity errors : sum local = 0.000331263, global = -0.000331263, cumulative = -0.000661725
ExecutionTime = 0.04 s ClockTime = 0 s
```
### 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 : v2012
- Operating system : Ubuntu 22.04
- Hardware info : AMD Ryzen 7 2700X Eight-Core Processor
- Compiler : GCC 9.5.0
### Possible fixes
Change `hePsiThermo.C` to:
```
template<class BasicPsiThermo, class MixtureType>
void Foam::hePsiThermo<BasicPsiThermo, MixtureType>::correct()
{
DebugInFunction << endl;
// force old time
this->psi_.oldTime();
calculate
(
this->p_,
this->T_,
this->he_,
this->psi_,
this->mu_,
this->alpha_,
false // No need to update old times
);
DebugInFunction << "Finished" << endl;
}
```Kutalmış BerçinKutalmış Berçinhttps://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/2675OF2212 compilation error2023-06-14T12:34:33ZThibault XAVIEROF2212 compilation error<!--
*** 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
Hi everyone,
I have an error while compiling OpenFOAM2212 on cluster using icpc. I can't really understand why and would need a hand ! Thanks for your time :smile:
Log file [log.linux64IccDPInt32Opt](/uploads/3e1f54d91bb519f7230dfde86eeb2d53/log.linux64IccDPInt32Opt) from "Allwmake -l".
Edit : same procedure applied to OpenFOAM2106 does not generate any error.
### Environment information
gcc version 4.8.5 20150623 (Red Hat 4.8.5-44) (GCC)
icpc (ICC) 19.1.0.166 20191121
mpirun (Open MPI) 4.1.4
GNU Make 3.82
cmake version 2.8.12.2
wmake version 2212
m4 (GNU M4) 1.4.16
flex 2.5.37
OS Red Hat Enterprise Linux Server version 7.9 (Maipo)https://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/2673gmshToFoam docstring for seriously wrong2023-01-10T13:31:55Zwuyang leegmshToFoam docstring for seriously wrong### Summary
There is a note in the docstring of [gmshToFoam.c](https://develop.openfoam.com/Development/openfoam/-/blob/master/applications/utilities/mesh/conversion/gmshToFoam/gmshToFoam.C).
> Note: There is something seriously wrong ...### Summary
There is a note in the docstring of [gmshToFoam.c](https://develop.openfoam.com/Development/openfoam/-/blob/master/applications/utilities/mesh/conversion/gmshToFoam/gmshToFoam.C).
> Note: There is something seriously wrong with the ordering written in the .msh file.
Whether the wrong will happen or not? What should I do if I want to use gmshToFoam correctly?
It would be nice to show examples.
Thanks in advance.
### Example case
Actually, I created a .msh file using gmsh, and ran gmshToFoam and checkMesh without errors.
However, the result of solving always is divergent as I have applied the simpleFoam as the solver.
I don't know what happen and how to fix it.https://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/2660reconstructParMesh does not handle moving mesh cases with topology changes2023-06-28T10:39:49ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comreconstructParMesh does not handle moving mesh cases with topology changes<!--
*** 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 -->
Use reconstructParMesh on a (parallel) case with topo changes. It will crash when trying to recalculate the mesh.phi() before that field has been updated.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
### 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
-->
`tutorials/multiphase/compressibleInterDyMFoam/laminar/sphereDrop` and use the Allrun-parallel script.
### What is the current *bug* behaviour?
<!-- What actually happens -->
Crash with out-of-bounds error.
### 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.
-->
```
--> FOAM FATAL ERROR: (openfoam-2212)
index 2275 out of range [0,2275]
From void Foam::UList<T>::checkIndex(Foam::label) const [with T = double; Foam::label = int]
in file /home/pikachu2/mattijs/OpenFOAM/OpenFOAM-plus/work/develop/src/OpenFOAM/lnInclude/UListI.H at line 169.
FOAM aborting
#0 Foam::error::printStack(Foam::Ostream&) in ~/OpenFOAM/OpenFOAM-plus/work/develop/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so
#1 Foam::error::simpleExit(int, bool) in ~/OpenFOAM/OpenFOAM-plus/work/develop/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so
#2 Foam::error::exiting(int, bool) in ~/OpenFOAM/OpenFOAM-plus/work/develop/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so
#3 Foam::Ostream& Foam::operator<< <Foam::error>(Foam::Ostream&, Foam::errorManip<Foam::error>) at ~/OpenFOAM/OpenFOAM-plus/work/develop/src/OpenFOAM/lnInclude/errorManip.H:93 (discriminator 4)
#4 Foam::UList<double>::checkIndex(int) const at ~/OpenFOAM/OpenFOAM-plus/work/develop/src/OpenFOAM/lnInclude/UListI.H:169
#5 Foam::UList<double>::operator[](int) at ~/OpenFOAM/OpenFOAM-plus/work/develop/src/OpenFOAM/lnInclude/UListI.H:304
#6 Foam::fvGeometryScheme::setMeshPhi() const at ~/OpenFOAM/OpenFOAM-plus/work/develop/src/finiteVolume/fvMesh/fvGeometryScheme/fvGeometryScheme/fvGeometryScheme.C:103 (discriminator 2)
#7 Foam::fvGeometryScheme::movePoints() at ~/OpenFOAM/OpenFOAM-plus/work/develop/src/finiteVolume/fvMesh/fvGeometryScheme/fvGeometryScheme/fvGeometryScheme.C:159
#8 Foam::basicFvGeometryScheme::movePoints() in ~/OpenFOAM/OpenFOAM-plus/work/develop/platforms/linux64GccDPInt32Opt/lib/libfiniteVolume.so
#9 Foam::surfaceInterpolation::updateGeom() in ~/OpenFOAM/OpenFOAM-plus/work/develop/platforms/linux64GccDPInt32Opt/lib/libfiniteVolume.so
#10 Foam::primitiveMesh::faceCentres() const in ~/OpenFOAM/OpenFOAM-plus/work/develop/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so
#11 Foam::polyPatch::faceCentres() const in ~/OpenFOAM/OpenFOAM-plus/work/develop/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so
#12 Foam::cyclicAMIPolyPatch::calcTransforms() at ~/OpenFOAM/OpenFOAM-plus/work/develop/src/meshTools/AMIInterpolation/patches/cyclicAMI/cyclicAMIPolyPatch/cyclicAMIPolyPatch.C:472
#13 Foam::cyclicAMIPolyPatch::initGeometry(Foam::PstreamBuffers&) at ~/OpenFOAM/OpenFOAM-plus/work/develop/src/meshTools/AMIInterpolation/patches/cyclicAMI/cyclicAMIPolyPatch/cyclicAMIPolyPatch.C:497
#14 Foam::polyBoundaryMesh::calcGeometry() in ~/OpenFOAM/OpenFOAM-plus/work/develop/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so
#15 Foam::polyMesh::resetPrimitives(Foam::autoPtr<Foam::Field<Foam::Vector<double> > >&&, Foam::autoPtr<Foam::List<Foam::face> >&&, Foam::autoPtr<Foam::List<int> >&&, Foam::autoPtr<Foam::List<int> >&&, Foam::UList<int> const&, Foam::UList<int> const&, bool) in ~/OpenFOAM/OpenFOAM-plus/work/develop/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so
#16 Foam::polyTopoChange::changeMesh(Foam::polyMesh&, Foam::UList<int> const&, bool, bool, bool, bool) in ~/OpenFOAM/OpenFOAM-plus/work/develop/platforms/linux64GccDPInt32Opt/lib/libmeshTools.so
#17 Foam::polyTopoChange::changeMesh(Foam::polyMesh&, bool, bool, bool, bool) in ~/OpenFOAM/OpenFOAM-plus/work/develop/platforms/linux64GccDPInt32Opt/lib/libmeshTools.so
#18 Foam::fvMeshAdder::add(int, Foam::UPtrList<Foam::fvMesh>&, Foam::List<int> const&, Foam::List<Foam::List<int> > const&, Foam::List<Foam::List<int> > const&, Foam::List<Foam::List<int> > const&, Foam::List<Foam::List<int> >&, Foam::List<Foam::List<int> >&, Foam::List<Foam::List<int> >&, Foam::List<Foam::List<int> >&) in ~/OpenFOAM/OpenFOAM-plus/work/develop/platforms/linux64GccDPInt32Opt/lib/libdynamicMesh.so
#19 ? at ~/OpenFOAM/OpenFOAM-plus/work/develop/applications/utilities/parallelProcessing/reconstructParMesh/reconstructParMesh.C:1142
#20 __libc_start_main in /lib64/libc.so.6
#21 ? at /home/abuild/rpmbuild/BUILD/glibc-2.31/csu/../sysdeps/x86_64/start.S:122
```
### 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
-->
- problem is that the cyclicAMI triggers the fvMeshGemoetry::meshPhi() calculation when trying to find out the patch face correspondence and transformations
- not trigger fvGeometryScheme::setPhi before all is mapped? inside fvGeometryScheme?
- delete mesh.phi() before fvGeometryScheme::movePoints gets called (e.g. inside reconstructParMesh) (still should be reconstructed afterwards)
- can unset mesh.moving() inside reconstructParMesh but that also then gets rid of reconstruction of points0, meshPhi
- change tutorial to delete the points0, meshPhi files before running the reconstructParMesh (same problem)
- extend redistributePar -reconstruct to work on topology change cases.