Development issueshttps://develop.openfoam.com/groups/Development/-/issues2022-04-26T16:10:38Zhttps://develop.openfoam.com/Development/openfoam/-/issues/1458nearWallFields does not run with #includeFunc since "field" and "fields" keyw...2022-04-26T16:10:38ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comnearWallFields does not run with #includeFunc since "field" and "fields" keyword are reservedfunctionObject reading in functionObjectList::readFunctionObject assumes that 'field' and 'fields' entries are straight wordlists.
nearWallFields uses 'field' for a List of word tuple. The workaround is to use it in a #include file (so ...functionObject reading in functionObjectList::readFunctionObject assumes that 'field' and 'fields' entries are straight wordlists.
nearWallFields uses 'field' for a List of word tuple. The workaround is to use it in a #include file (so the nearWallFields dictionary is a subdictionary) and not in a #includeFunc context.v2206Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1471Potentially redundant set of computations for G object within eddy-viscosity ...2022-04-26T16:10:39ZKutalmış BerçinPotentially redundant set of computations for G object within eddy-viscosity turbulence modelsSome of the eddy-viscosity-based turbulence models compute G (the turbulent kinetic energy production rate due to the anisotropic part of the stress tensor). For example, in kEpsilon:
```
volScalarField::Internal G
(
thi...Some of the eddy-viscosity-based turbulence models compute G (the turbulent kinetic energy production rate due to the anisotropic part of the stress tensor). For example, in kEpsilon:
```
volScalarField::Internal G
(
this->GName(),
nut.v()*(dev(twoSymm(tgradU().v())) && tgradU().v())
);
tgradU.clear();
```
Here, we compute a deviatoric-symmetric tensor (`(dev(twoSymm(tgradU().v()))`) with a full tensor `tgradU().v()`.
**Any tensor** can be divided into its symmetric and anti-symmetric parts. And any double-inner product of a symmetric tensor and an anti-symmetric tensor is zero.
Therefore, the above double-inner product can be reduced between two symmetric tensors without losing any level of accuracy in the final outcome.
Such reduction seems to be carried out in the more recently implemented turbulence models, e.g. v2f.
The simpler, cheaper-to-run alternative can be:
```
tmp<volTensorField> tgradU = fvc::grad(U);
const volScalarField::Internal G
(
this->GName(),
nut.v()*2*magSqr(dev(symm(tgradU.cref().v())))
);
tgradU.clear();
```
PS: Asked the question in CFD-Online: [here](https://www.cfd-online.com/Forums/openfoam-solving/229596-potentially-redundant-set-computations-g-object-within-turbulence-models.html).v2206Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1456sampledSet 'uniform' does not produce same output in parallel2022-04-27T10:28:01ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comsampledSet 'uniform' does not produce same output in parallel<!--
*** 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 ...<!--
*** 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 -->
different number of samples when run in parallel.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Take pitzDaily tutorial. Use decomposeParDict with
```
//- The total number of domains (mandatory)
numberOfSubdomains 2;
////- The decomposition method (mandatory)
method random;
```
There will be 10 tracks when running in parallel but only 1 when running in parallel.
### 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 : develop (but probably also v1906)
- Operating system : openSUSE
- 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
-->v2206Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2647readFields function object is sticky in postProcess mode2023-06-23T09:05:09ZAndrew HeatherreadFields function object is sticky in postProcess modeThe `readFields` function object only reads from file if the field is not already found in the database. Using `postProcess` this leads to fields being initially read but not updated at the new times.The `readFields` function object only reads from file if the field is not already found in the database. Using `postProcess` this leads to fields being initially read but not updated at the new times.v2212Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/issues/2524construct faMesh fails with distributed roots2022-06-24T11:12:08ZMark OLESENconstruct faMesh fails with distributed rootsNoticed during testing of #2523 - needs more attention
Running `checkFaMesh` with distributed roots:
```
[0] --> FOAM FATAL ERROR: (openfoam-2206)
[0] Cannot find file "faceLabels" in directory "faMesh" in times "0" down to constant
[...Noticed during testing of #2523 - needs more attention
Running `checkFaMesh` with distributed roots:
```
[0] --> FOAM FATAL ERROR: (openfoam-2206)
[0] Cannot find file "faceLabels" in directory "faMesh" in times "0" down to constant
[0]
[0] From virtual Foam::IOobject Foam::fileOperation::findInstance(const Foam::IOobject &, const Foam::scalar, const Foam::word &) const
[0] in file global/fileOperations/fileOperation/fileOperation.C at line 1139
```v2212https://develop.openfoam.com/Development/openfoam/-/issues/2402slow writing of (ensight) surfaces2022-11-22T11:26:19ZMark OLESENslow writing of (ensight) surfacesObserved in EP1819. The point merging now appears to be the main bottleneck.
@chiaraObserved in EP1819. The point merging now appears to be the main bottleneck.
@chiarav2212Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2272surface file reader for ftr and off files2021-12-10T13:06:38ZBas Nieuwboersurface file reader for ftr and off files<!--
*** 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
I've come across two issues with surface files:
- surfaceTransformPoints does not support ftr file.
- off files are read without reading the region (patch) information. While it seems to be present in the file.
Both these issues are non-essential for me, since I never use these file types. I've created this bug-report to let you know the inconsistency in the use of these files. Therefore a result of this report could be that it is not worth the time to look into this.
### Steps to reproduce
I found the issue in creating a tool, described in: In https://develop.openfoam.com/Development/openfoam/-/issues/2239#note_54832
The test.sh file in this post, illustrates both issues. @mark already commented on the issues in this post: https://develop.openfoam.com/Development/openfoam/-/issues/2239#note_54835
### 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
OpenFOAM version : v2106v2212https://develop.openfoam.com/Development/openfoam/-/issues/2491lagrangian/coalChemistryFoam/simplifiedSiwek is finding librunTimePostProces...2022-12-23T14:57:31ZSergio Ferrarislagrangian/coalChemistryFoam/simplifiedSiwek is finding librunTimePostProcessing.so--> FOAM Warning :
From void *Foam::dlLibraryTable::openLibrary(const Foam::fileName &, bool)
in file db/dynamicLibrary/dlLibraryTable/dlLibraryTable.C at line 188
Could not load "librunTimePostProcessing.so"
librunTimePostP...--> FOAM Warning :
From void *Foam::dlLibraryTable::openLibrary(const Foam::fileName &, bool)
in file db/dynamicLibrary/dlLibraryTable/dlLibraryTable.C at line 188
Could not load "librunTimePostProcessing.so"
librunTimePostProcessing.so: cannot open shared object file: No such file or directory
--> FOAM Warning :
Unknown function type runTimePostProcessingv2306Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/issues/2457BUG: isoAdvection not conserving volume of fluid across cyclic boundaries2022-12-20T13:21:10ZJohan RoenbyBUG: isoAdvection not conserving volume of fluid across cyclic boundaries<!--
*** 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
isoAdvection not conserving volume of fluid across cyclic boundaries.
### Steps to reproduce
1. Execute the `Allrun` script in `$FOAM_TUTORIALS/multiphase/interIsoFoam/discInConstantFlowCyclicBCs`
2. Extract "Phase-1" volume from log:
` grep "Phase-1" log.interIsoFoam | cut -d' ' -f5 > Phase1`
3. Run gnuplot in the terminal and show data:
`plot "Phase1"`
In the figure you will see the Phase-1 content in the domain change when the blob travels through the cyclic boundaries
### Possible fixes
Reason for wrong behaviour:
IsoAdvection creates a surfaceScalarField dVf which is the Phase-1 volume crosing a face in the time deltaT.
dVf on a face uses the isoface information in its UPWIND cell.
This also goes for boundary faces where fluid flows OUT of the domain.
For boundary faces on which fluid flows INTO the domain isoAdvection does nothing because it assumes that the alpha1 boundary condition specifies how much of the incoming fluid that is Phase-1 and Phase-2, respectively.
Solution:
At [this point](https://develop.openfoam.com/Development/openfoam/-/blob/master/src/transportModels/geometricVoF/advectionSchemes/isoAdvection/isoAdvection.C#L400) in the code - i.e. after havng set dVf on a downwind boundary face - check if the face is on a cyclic patch. If it is, set the same dVf value on the corresponding face of the coupled patch.
To solve this, I need to do a little digging into the functionality of cyclic related code. I will definitely do this before v2206. But if someone is up for fixing it before then, be my guest.v2306Johan RoenbyJohan Roenbyhttps://develop.openfoam.com/Development/openfoam/-/issues/2240FPE handling for OSX arm642024-01-11T15:06:56ZMark OLESENFPE handling for OSX arm64Mentioned in cfd-online and refers to this gitrepo :
https://github.com/ttsyshmz/howtoFoam/blob/main/codes/feexceptErsatz-v2106/feexceptErsatz.HMentioned in cfd-online and refers to this gitrepo :
https://github.com/ttsyshmz/howtoFoam/blob/main/codes/feexceptErsatz-v2106/feexceptErsatz.Hv2306Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2139BUG: DMD: FOAM_SETNAN=true causes implementation-dependent FATALs2022-12-23T14:58:27ZKutalmış BerçinBUG: DMD: FOAM_SETNAN=true causes implementation-dependent FATALs### Summary
`FOAM_SETNAN=false` (default) masks various vulnerabilities in `DMD`.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
- For `bash`, set `export FOAM_SETNAN=true`.
- Run `$FOAM_TUT...### Summary
`FOAM_SETNAN=false` (default) masks various vulnerabilities in `DMD`.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
- For `bash`, set `export FOAM_SETNAN=true`.
- Run `$FOAM_TUTORIALS/incompressible/pimpleFoam/laminar/cylinder2D`
- Will throw the following (or similar) FATAL (implementation/environment dependent):
```
Expanding orthonormal basis for field: U
Compressing orthonormal basis for field: U
[0]
[0]
[0] --> FOAM FATAL ERROR: (openfoam-2106)
[0] List size (1) incompatible with Matrix diagonal
[0]
[0] From void Foam::Matrix<Foam::SquareMatrix<double>, double>::diag(const UList<Type> &) [Form = Foam::SquareMatrix<double>, Type = double]
```
### Relevant logs and/or images
- Compiled the `functionObjects/field/` library with `-DFULLDEBUG -g -O0` (by @Mattijs):
[processor0.log.gz](/uploads/b46023b062520e2361a229de4c11b3be/processor0.log.gz)
### 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 = 2106
patch = 0
HEAD = 6595429f53
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
```v2306Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1867Bound does not work in some boundaryFields2022-12-23T15:04:58ZSantiago Marquez DamianBound does not work in some boundaryFieldsHello folks we've found an issue with the bound method, particularly in the line,
vsf.boundaryFieldRef() = max(vsf.boundaryField(), lowerBound.value());
Line 58 here,
https://www.openfoam.com/documentation/guides/latest/api/bound_8C_s...Hello folks we've found an issue with the bound method, particularly in the line,
vsf.boundaryFieldRef() = max(vsf.boundaryField(), lowerBound.value());
Line 58 here,
https://www.openfoam.com/documentation/guides/latest/api/bound_8C_source.html
In the attached case (run it with pimpleFoam, v2006) an inletOutlet BC is set in the outlet for omega with inletValue 0.
Bound should override this value with 1E-5 as set in constant/turbulenceProperties and in fact that happens in the RHS of line 58, but after "=" operator evaluation the original BC inletValue = 0 is set (or left). Due to this 0 value in omega solver crashes immediately after bound.
Regards!
[boundBug.tgz](/uploads/15e1fed8e6f04e5eac24bfa7d4dfc84a/boundBug.tgz)v2306Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1837rhoCentralDyMFoam + Turbulence Model = Crash2022-12-23T15:05:24ZMartin HeinrichrhoCentralDyMFoam + Turbulence Model = Crash### Summary
I tried to simulate a transonic compressor with `rhoCentralDyMFoam` with cyclicAMIs between a rotating and stationary mesh. However, `rhoCentralDyMFoam` crashes on the first time step at the turbulence model. The error indic...### Summary
I tried to simulate a transonic compressor with `rhoCentralDyMFoam` with cyclicAMIs between a rotating and stationary mesh. However, `rhoCentralDyMFoam` crashes on the first time step at the turbulence model. The error indicates that it has something to do with the orientation of the surfaceScalarFields.
### Steps to reproduce
I have attached a sample case, which is based on the propeller tutorial case [propeller_rhoCentralDyMFoam.tar.gz](/uploads/2bb046dca85cadef2e311ba5addfc9db/propeller_rhoCentralDyMFoam.tar.gz) adjusted for a compressible flow and `rhoCentralDyMFoam`.
### What is the current *bug* behaviour?
The solver crashes.
### What is the expected *correct* behavior?
The solver should run smoothly.
### Relevant logs and/or images
The error message is pointing towards the `fvc::absolute` function, which is called within the `kOmegaSSTBase` class:
--> FOAM FATAL ERROR:
Operator + is undefined for unoriented and oriented types
From Foam::orientedType Foam::operator+(const Foam::orientedType&, const Foam::orientedType&)
in file orientedType/orientedType.C at line 479.
FOAM aborting
#0 Foam::error::printStack(Foam::Ostream&) at ??:?
#1 Foam::error::exitOrAbort(int, bool) at ??:?
#2 Foam::operator+(Foam::orientedType const&, Foam::orientedType const&) at ??:?
#3 void Foam::add<double, double, Foam::fvsPatchField, Foam::surfaceMesh>(Foam::GeometricField<Foam::typeOfSum<double,
double>::type, Foam::fvsPatchField, Foam::surfaceMesh>&, Foam::GeometricField<double, Foam::fvsPatchField,
Foam::surfaceMesh> const&, Foam::GeometricField<double, Foam::fvsPatchField, Foam::surfaceMesh> const&) at ??:?
#4 Foam::tmp<Foam::GeometricField<Foam::typeOfSum<double, double>::type, Foam::fvsPatchField, Foam::surfaceMesh> >
Foam::operator+<double, double, Foam::fvsPatchField, Foam::surfaceMesh>(Foam::tmp<Foam::GeometricField<double,
Foam::fvsPatchField, Foam::surfaceMesh> > const&, Foam::tmp<Foam::GeometricField<double, Foam::fvsPatchField,
Foam::surfaceMesh> > const&) at ??:?
#5 Foam::fvc::absolute(Foam::tmp<Foam::GeometricField<double, Foam::fvsPatchField, Foam::surfaceMesh> > const&,
Foam::GeometricField<Foam::Vector<double>, Foam::fvPatchField, Foam::volMesh> const&) at ??:?
#6 Foam::kOmegaSSTBase<Foam::eddyViscosity<Foam::RASModel<Foam::EddyDiffusivity<Foam::ThermalDiffusivity<Foam::CompressibleTurbulenceModel<Foam::fluidThermo> > > > > >::correct() at ??:?
#7 ? at ??:?
#8 __libc_start_main in /lib/x86_64-linux-gnu/libc.so.6
#9 ? at ??:?
### 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 : v2006
- Operating system : Debian 10
- Compiler : GCC 9.1.0
### Possible fixes
Maybe it has something to do with the `setOriented(true)` call missing in said function, but that's a guess.v2306Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1392Capillary Courant Number for reducing spurious velocities2022-12-23T14:57:10ZAdminCapillary Courant Number for reducing spurious velocities### Functionality to add/problem to solve
Spurious (unphysical) velocities are often a problem in volume of fluid simulations. Dozens of papers are written about techniques to reduce them.
As surface tension is implemented explicitly i...### Functionality to add/problem to solve
Spurious (unphysical) velocities are often a problem in volume of fluid simulations. Dozens of papers are written about techniques to reduce them.
As surface tension is implemented explicitly in interFoam, the time step needs to be limited. It should be limited by the capillary Courant number.
### Target audience
A Capillary Courant number will be useful for everyone who uses interFoam or multiphaseInterFoam, and is working with surface tension. It will be especially usefull when simulating instabilities, because before the instability appears there should usually not be any flow in the fluid.
### Proposal
A Capillary Courant Number should be added to interFoam and multiphaseInterFoam.
### What does success look like, and how can we measure that?
The simplest test case would consist of two fluids, one over another. There should not be any flow. Of course, spurious velocities will appear - however, they will be much smaller when using a Capillary Courant number.
### Links / references
Personnettaz, P.; Beckstein, P.; Landgraf, S.; Köllner, T.; Nimtz, M.; Weber, N.; Weier, T.: Thermally driven convection in Li||Bi liquid metal batteries, Journal of Power Sources 401(2018) 362-374
The capillary time step is provided at [page 36, equation A.1 of the arXiv version.](https://arxiv.org/pdf/1805.11521.pdf)
### Funding
I can provide the source code for interFoam and multiphaseInterFoam.
\## Reattaching the author to the issue ticket: @dl6tud ##v2306Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1219writeDictionary FO only prints after first iteration2022-12-23T14:56:42ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comwriteDictionary FO only prints after first iterationIt should print before the first iteration.It should print before the first iteration.v2306Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1285keepParticle is ignored by postPatch2022-12-23T14:56:06ZAdminkeepParticle is ignored by postPatchI'm not sure if this is an actual issue or if I missed something in the code, but consider the following:
The cloudFunctionObjects have a hook "postPatch" to allow users to run code if a particle hits a patch:
https://develop.openfoam....I'm not sure if this is an actual issue or if I missed something in the code, but consider the following:
The cloudFunctionObjects have a hook "postPatch" to allow users to run code if a particle hits a patch:
https://develop.openfoam.com/Development/OpenFOAM-plus/blob/master/src/lagrangian/intermediate/submodels/CloudFunctionObjects/CloudFunctionObject/CloudFunctionObject.H#L160
This hook has a parameter "keepParticle" if the user wants to remove the particle due to e.g. some custom model.
The hook is called here:
https://develop.openfoam.com/Development/OpenFOAM-plus/blob/master/src/lagrangian/intermediate/parcels/Templates/KinematicParcel/KinematicParcel.C#L385
The value of "keepParticle" is not used. Right after the hook, the standard patch interaction code is called. Let's say the user chose "rebound". Then the following code is called:
https://develop.openfoam.com/Development/OpenFOAM-plus/blob/master/src/lagrangian/intermediate/submodels/Kinematic/PatchInteractionModel/LocalInteraction/LocalInteraction.C#L260
Here, the value of keepParticle is uconditionally set to "true", ignoring the previous value.
To summarize: postPatch may set "keepParticle" to false, but this value is not used until the patch interaction models overwrite this value. Therefore postPatch has no effect on removing particles and the parameter "keepParticle" in postPatch seems to be ignored.
\## Reattaching the author to the issue ticket: @g3 ##v2306Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1279fieldToCell does not use lookup; always reads from disk2022-12-23T14:55:17ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comfieldToCell does not use lookup; always reads from disk### Functionality to add/problem to solve
fieldToCell currently always reads from disk. Hence it cannot be used in e.g. a functionObject to select some cells during the run (). Would be nice if it would try lookup first instead.
### Pr...### Functionality to add/problem to solve
fieldToCell currently always reads from disk. Hence it cannot be used in e.g. a functionObject to select some cells during the run (). Would be nice if it would try lookup first instead.
### Proposal
- add database lookup first and loading from disk only if that fails
- move fieldToCell to finiteVolume and use proper fields
Example of desired use: plot all cells where the pressure is between 5 and 1000.
```
vtkWrite1
{
type vtkWrite;
libs ("libutilityFunctionObjects.so");
timeStart 10;
writeControl timeStep;
writeInterval 1;
format binary;
legacy false;
decompose false;
fields (p U);
selection
{
threshold
{
action use;
source fieldToCell;
field p;
min 5;
max 1000;
}
}
}
```
There is currently also a bug in that it searches for the last valid p,U instead of loading them from the current time (and failing).v2306Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/3018pTraits for complex looks incorrect2023-11-13T13:53:25ZMark OLESENpTraits for complex looks incorrectThe complex type is defined to have two components (ie, real, imag) but has cmptType as "complex" - doesn't really make sense, and has labelType as label anyhow.
It doesn't seem to be used anywhere but could be interesting with different...The complex type is defined to have two components (ie, real, imag) but has cmptType as "complex" - doesn't really make sense, and has labelType as label anyhow.
It doesn't seem to be used anywhere but could be interesting with different backends (eg ADIOS).
@andy @kutiv2406Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2958Add -ffp-contract=off for Clang 14 and later2024-03-19T15:07:40ZGuanyang XueAdd -ffp-contract=off for Clang 14 and later### Summary
Clang 14 changed its floating-point behavior. Now the default is `-ffp-contract=on` even with `-O0`
### Steps to reproduce
FMA is enabled by default for Clang 14 and later. This doesn't seem like an issue for x86 (because ...### Summary
Clang 14 changed its floating-point behavior. Now the default is `-ffp-contract=on` even with `-O0`
### Steps to reproduce
FMA is enabled by default for Clang 14 and later. This doesn't seem like an issue for x86 (because of different CPU instructions to do FMA), but for arm64 things like `libsampling` can easily fail.
### Example case
`tutorials/incompressible/simpleFoam/backwardFacingStep2D` leads to infinite loop when running the `sample` function.
### What is the current *bug* behaviour?
A lot of tutorial cases using `libsampling` will be trapped in infinite loop. Any code related to computational geometry may get unexpected results.
### What is the expected *correct* behavior?
The floating-point calculation should strictly follow IEEE-754 to avoid any potential bug that is almost impossible to debug.
### Relevant logs and/or images
https://releases.llvm.org/14.0.0/tools/clang/docs/ReleaseNotes.html#floating-point-support-in-clang
### Environment information
- OpenFOAM version : Any
- Operating system : Any
- Hardware info : Most likely affecting arm64
- Compiler : Clang 14 and later
### Possible fixes
I don't know if it's possible to add flags in wmake rules based on compiler version. I would propose add `-ffp-contract=off` explicitly to the general Clang wmake rule as it doesn't change anything before Clang 13. For `Arm` and `Fujitsu`, it should be added automatically.v2406Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/3128ENH: allow frozenFlow option for icoReactingMultiphaseInterFoam2024-03-28T15:10:21ZPrashant SonakarENH: allow frozenFlow option for icoReactingMultiphaseInterFoamSimilar to CHT solvers, please extend the frozenFlow option for the solver icoReactingMultiphaseInterFoam
corss reference: EP#2286Similar to CHT solvers, please extend the frozenFlow option for the solver icoReactingMultiphaseInterFoam
corss reference: EP#2286Andrew HeatherAndrew Heather