Development issueshttps://develop.openfoam.com/groups/Development/-/issues2023-10-17T15:06:11Zhttps://develop.openfoam.com/Development/openfoam/-/issues/2760LESRegion computed wrongly when using kOmegaSSTIDDES turbulence model2023-10-17T15:06:11ZWojciech SadowskiLESRegion computed wrongly when using kOmegaSSTIDDES turbulence model### Functionality to add/problem to solve
The `LESRegion()` function in the `kOmegaSSTIDDES` turbulence model is not implemented.
Instead the implementation from the base class `kOmegaSSTDES` is used:
```cpp
template<class BasicTurbulen...### Functionality to add/problem to solve
The `LESRegion()` function in the `kOmegaSSTIDDES` turbulence model is not implemented.
Instead the implementation from the base class `kOmegaSSTDES` is used:
```cpp
template<class BasicTurbulenceModel>
tmp<volScalarField> kOmegaSSTDES<BasicTurbulenceModel>::LESRegion() const
{
const volScalarField& k = this->k_;
const volScalarField& omega = this->omega_;
const volVectorField& U = this->U_;
const volScalarField CDkOmega
(
(2*this->alphaOmega2_)*(fvc::grad(k) & fvc::grad(omega))/omega
);
const volScalarField F1(this->F1(CDkOmega));
return tmp<volScalarField>::New
(
IOobject::scopedName("DES", "LESRegion"),
neg(dTilda(mag(fvc::grad(U)), CDES(F1)) - lengthScaleRAS())
);
}
```
leading to LES region indicator computed with
different equation than the one actually used in the model:
```cpp
template<class BasicTurbulenceModel>
tmp<volScalarField> kOmegaSSTIDDES<BasicTurbulenceModel>::dTilda
(
const volScalarField& magGradU,
const volScalarField& CDES
) const
{
const volScalarField lRAS(this->lengthScaleRAS());
const volScalarField lLES(this->lengthScaleLES(CDES));
const volScalarField alpha(this->alpha());
const volScalarField expTerm(exp(sqr(alpha)));
tmp<volScalarField> fB = min(2*pow(expTerm, -9.0), scalar(1));
const volScalarField fdTilda(max(1 - fdt(magGradU), fB));
if (fe_)
{
/*
...
*/
}
// Simplified formulation from Gritskevich et al. paper (2011) where fe = 0
return max
(
fdTilda*lRAS + (1 - fdTilda)*lLES,
dimensionedScalar(dimLength, SMALL)
);
}
```
While writing this issue, I became aware that outputting `fd` is also possible now, as of v2212.
It seems that for IDDES model it is actually equivalent to the way `fdTilda` is computed in the code,
and `1-fdTilda` multiplies the LES length scale in both versions of blending, so it serves the same purpose (as far as I understand it).
Perhaps one option to resolve this would be implementing a virtual `LESRegion()` that throws `FatalError` telling the user to
output `fd` instead and subtract it from 1?
### Target audience
Target audience are the users of hybrid RANS/LES turbulence models.
Proper indication in which region the model works in a LES mode is important for
debugging and setting up cases with those models properly.
### Proposal
I have made a quick solution for myself in an out-of-repository copy of kOmegaSSTIDDES.
1. Added a protected member function, to refactor computation of `fdTilda`.
Header:
```cpp
//- Return the fdTilda function (moved to a function for
// LESRegions function)
tmp<volScalarField> fdTilda
(
const volScalarField &magGradU,
const volScalarField &expTerm
) const;
```
Implementation:
```cpp
template <class BasicTurbulenceModel>
tmp<volScalarField> kOmegaSSTIDDES<BasicTurbulenceModel>::fdTilda
(
const volScalarField &magGradU,
const volScalarField &expTerm
) const
{
tmp<volScalarField> fB = min(2 * pow(expTerm, -9.0), scalar(1));
return max(1 - fdt(magGradU), fB);
}
```
2. Added the `LESRegion()`:
Header:
```cpp
//- Return the LES field indicator
virtual tmp<volScalarField> LESRegion() const;
```
Implementation:
```cpp
template <class BasicTurbulenceModel>
tmp<volScalarField> kOmegaSSTIDDES<BasicTurbulenceModel>::LESRegion() const
{
const volScalarField magGradU(mag(fvc::grad(this->U_)));
const volScalarField expTerm(exp(sqr(this->alpha())));
tmp<volScalarField> tLESRegion
(
new volScalarField
(
IOobject::scopedName("IDDES", "LESRegion"),
1 - this->fdTilda(magGradU, expTerm)
)
);
// Solver is in RANS mode next to the wall.
// i have no clue if this can cause problems
tLESRegion.ref().boundaryFieldRef() == 0.0;
return tLESRegion;
}
```
### What does success look like, and how can we measure that?
The LES region computed with unchanged code from a sample test case:
![obraz](/uploads/a22e4dfdec687fb767946f36a9d49de9/obraz.png)
The LES region computed with the code above, using `fdTilda` as it is computed in `dTilda` function:
![obraz](/uploads/38fd2950b035e2469c5353acd245a400/obraz.png)
### Links / references
Reference from KOmegaSSTIDDES model:
Gritskevich, M.S., Garbaruk, A.V., Schuetze, J., Menter, F.R. (2011)
Development of DDES and IDDES Formulations for the k-omega
Shear Stress Transport Model, Flow, Turbulence and Combustion,
pp. 1-19Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2759Unable to install openfoam2023-04-14T10:32:47ZSaurav ChaudhariUnable to install openfoamI am unable to install OpenFOAM CFD Module on my Windows. It's showing some error at line 47.
![OpenFOAM](/uploads/ef7b5578c108aa4ca39db7c73fac4c7f/OpenFOAM.jpg)I am unable to install OpenFOAM CFD Module on my Windows. It's showing some error at line 47.
![OpenFOAM](/uploads/ef7b5578c108aa4ca39db7c73fac4c7f/OpenFOAM.jpg)https://develop.openfoam.com/Development/openfoam/-/issues/2758explicit calculations for triSurface fields2023-04-21T07:43:21ZMark OLESENexplicit calculations for triSurface fieldsThe triSurface fields are a slightly dodgy construct, they use triSurface for mesh sizes/relationship but the fields cannot be registered on triSurface. Instead, some other source of objectRegistry is used (in some cases this is whatever...The triSurface fields are a slightly dodgy construct, they use triSurface for mesh sizes/relationship but the fields cannot be registered on triSurface. Instead, some other source of objectRegistry is used (in some cases this is whatever the IOobject provides).
As a result, the relationship `field.mesh().thisDb()` does not work.
In places using triSurface fields, they should be expanded out (ie, expressed as calculations of the primitive fields) to ensure that none of the `mesh().thisDb()` code is used.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2757Precompiled packages openfoam2212-tutorials shows incorrect latest version fo...2023-05-08T22:21:03ZShinji NakagawaPrecompiled packages openfoam2212-tutorials shows incorrect latest version for Ubuntu 20.04 focalOS: Ubuntu 20.04 focal
Version: OpenFOAM v2212
Precompiled packages (Ubuntu) openfoam2212-tutorials is not installed with apt-get install command because of the dependency problem.
The latest version of openfoam2212-tutorials is 2212.0...OS: Ubuntu 20.04 focal
Version: OpenFOAM v2212
Precompiled packages (Ubuntu) openfoam2212-tutorials is not installed with apt-get install command because of the dependency problem.
The latest version of openfoam2212-tutorials is 2212.0~rc2-1 in Package. The version of other packages like openfoam2212-common is now version 2212.230110-1.
The repository for Ubuntu 22.04 jammy has no problem.https://develop.openfoam.com/Development/openfoam/-/issues/2741faceAgglomerate not robust2023-06-26T10:33:01ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comfaceAgglomerate not robust<!--
*** 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 -->
- faceAgglomerate utility can hang
- sharp angles are not detected as features
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
in tutorials/heatTransfer/chtMultiRegionFoam/externalSolarLoad specify some agglomeration for air:
[viewFactorsDict](/uploads/22120b2cc9b482b1c69a71026772f5b7/viewFactorsDict)
### 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 -->
Hangs since agglomerated-face-forms-single-loop check does not count whether any new restraints have been added.
### What is the expected *correct* behavior?
<!-- What you should see instead -->
Agglomeration not getting stuck. It might not be able to agglomerate down to the wanted level because of topological constraints but it should not hang.
### 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 :
- 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
-->Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/2740Heat imbalance at multiregional boundary in chtMultiRegionFoam2023-05-07T23:39:54ZShinji TakeharaHeat imbalance at multiregional boundary in chtMultiRegionFoam<!--
*** 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 specific heat has a temperature dependence, heat flux imbalance occurs at the multiregional boundary.
I confirmed this phenomenon using wall heat flux in Field function objects.
※This imbalance occurs in not only *compressible::turbulentTemperatureRadCoupledMixed* but also in * externalWallHeatFluxTemperature*
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
1. Download the attached file(one is constant Cp, another is temperature dependent Cp)
2. run `chtMultiReigonFoam` in each directory
3. compare postprocessing/l/wallHeatFlux1/0.0/wallHeatFlux.dat and postprocessing/r/wallHeatFlux1/0.0/wallHeatFlux.dat
### 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
-->
[imbalancedHeatFluxWhenTemperatureDependentCp.tar.gz](/uploads/1c54286d2349419bc05c4e2427e4ac8b/imbalancedHeatFluxWhenTemperatureDependentCp.tar.gz)
[balancedHeatFluxWhenTemperatureIndependentCp.tar.gz](/uploads/ba90fb0986ad3c1248a4996f19f7c9bd/balancedHeatFluxWhenTemperatureIndependentCp.tar.gz)
### What is the current *bug* behaviour?
<!-- What actually happens -->
Heat flux imbalance occurs at the multiregional boundary.
### What is the expected *correct* behavior?
<!-- What you should see instead -->
Heat flux is balanced at the multiregional boundary.
### Relevant logs and/or images
<!--
Paste any relevant logs - please use code blocks (```) to format console
output, logs, and code as it's![image](/uploads/67b582ce7e531a3cdca56cceb8e209aa/image.png) 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 :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
-->
I thought that the bug was caused by robin boundary condition.
Three parameters(*valueFraction*, *refValue*, *refGrad*) related robin boundary condition is calculated in *turbulentTemperatureRadCoupledMixedFvPatchScalarField.C*.
After that, since these are based on temperature, it is converged to an enthalpy based value at *mixedEnergyFvPatchScalarField.C*.
The conversion of *valueFraction* seems to assume constant specific heat. When I modified like below, the heat flux at multiregional boundary can be balanced.
original :
*turbulentTemperatureRadCoupledMixedFvPatchScalarField.C*
valueFraction() = KDeltaNbr/(KDeltaNbr + alpha);
modified :
*turbulentTemperatureRadCoupledMixedFvPatchScalarField.C*
valueFraction() = KDeltaNbr/(KDeltaNbr + alpha) * myThermo->Cp(pp, Tp, patchi) *(TcNbr-Tc)/(myThermo->he(pcn, TcNbr, samplePatchi) - myThermo->he(pc, Tc, patchi));Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2739multiLevel at the scotch level2023-05-09T13:04:47ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.commultiLevel at the scotch level### Functionality to add/problem to solve
multiLevel decomposition can be used to minimise 'expensive' cuts. scotch can support this natively using SCOTCH_archTleaf.
### Target audience
multi-node runs
### Proposal
E.g. start from ...### Functionality to add/problem to solve
multiLevel decomposition can be used to minimise 'expensive' cuts. scotch can support this natively using SCOTCH_archTleaf.
### Target audience
multi-node runs
### Proposal
E.g. start from the extended multiLevel input:
```
numberOfSubdomains 1024;
method multiLevel;
multiLevelCoeffs
{
method scotch
domains (2 8); //< inferred as domains (64 2 8);
}
```
Just needs additional spec of the individual cut weights.
### What does success look like, and how can we measure that?
Would be nice to have stats about cuts*weights on the individual levels...
@mark @andyhttps://develop.openfoam.com/Development/openfoam/-/issues/2738Binaries fail to install on Ubuntu 20.04 LTS2023-05-08T11:51:24ZAdam EricksonBinaries fail to install on Ubuntu 20.04 LTS<!--
*** 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
Binaries fail to install on Ubuntu 20.04 LTS (focal).
### Steps to reproduce
```bash
pubkey_url='https://dl.openfoam.com/pubkey.gpg'
repos_url='https://dl.openfoam.com/repos/deb'
apt_pubkey_path='/etc/apt/trusted.gpg.d/openfoam.gpg'
apt_source_path='/etc/apt/sources.list.d/openfoam.list'
ARCH='amd64'
DISTRIB_CODENAME='focal'
echo "deb [arch=${ARCH}] ${repos_url} ${DISTRIB_CODENAME} main" | sudo tee "${apt_source_path}"
curl -L "${pubkey_url}" | gpg --dearmor | sudo tee "${apt_pubkey_path}"
sudo apt update
sudo apt install openfoam2212-default
Reading package lists... Done
Building dependency tree
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:
The following packages have unmet dependencies:
openfoam2212-default : Depends: openfoam2212-tutorials (= 2212.230110-1) but it is not going to be installed
E: Unable to correct problems, you have held broken packages.
```
### Example case
See above.
### What is the current *bug* behaviour?
Fails to install.
### What is the expected *correct* behavior?
Installs.
### 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 : Ubuntu 20.04 LTS
- Hardware info : amd64, x86_64
- Compiler : gcc, clang
### Possible fixes
It looks like `openfoam2212-tutorials` depends on a release candidate for `openfoam2212-common` that is unavailable:
```bash
openfoam2212-tutorials : Depends: openfoam2212-common (= 2212.0~rc2-1) but 2212.230110-1 is to be installed
```https://develop.openfoam.com/Development/openfoam/-/issues/2737parProfling for large core counts2023-06-13T11:40:06ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comparProfling for large core counts### Functionality to add/problem to solve
`parProfiling`
Setup:
- have a large number of cores
- have a large number of masters in `masterCoarsest`
Questions:
- where is the bottleneck
- is it due to 'coarsest level' solution
- is it...### Functionality to add/problem to solve
`parProfiling`
Setup:
- have a large number of cores
- have a large number of masters in `masterCoarsest`
Questions:
- where is the bottleneck
- is it due to 'coarsest level' solution
- is it due to reductions or halo-swaps
Ideas on how to get this information out of `parProfiling` FO
- have a per-processor output (or only min/max processor?)
- split off all-to-all from wait times
- add number of invocations. Why? Number of reductions is synchronised - only difference is between master and non-master processors. 2) halo swaps are determined by the number of processor boundaries which can be obtained from the boundary file. 3) Interesting is the number of linear-solver sweeps though.
### Target audience
### Proposal
### What does success look like, and how can we measure that?
### Links / references
### FundingMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2736dynamicMesh failure restarting using CrankNicholson2024-01-04T10:56:23ZJamie MacLeoddynamicMesh failure restarting using CrankNicholson<!--
*** 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 restarting a case using dynamic meshing the first step fails with an error:
```
--> FOAM FATAL IO ERROR: (openfoam-2212 patch=230110)
size 77961 is not equal to the expected length 78325
file: 0.002/ddt0(rho,U).internalField at line 21.
From void Foam::Field<Type>::assign(const Foam::entry&, Foam::label) [with Type = Foam::Vector<double>; Foam::label = int]
in file ./src/OpenFOAM/lnInclude/Field.C at line 241.
FOAM exiting
```
This occurs regardless of whether dynamicMeshDict is altered or not (it may work sometimes if it is set to not refine every step, and happens to not align with the restart step, as previous tests have found that it works this way).
Almost certainly this associated with the 2nd order time scheme (which I would certainly strongly prefer to use), as Euler has no issues with the restart vs CN.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Run attached case until a new time, in this instance 0.002, and then try to restart.
### 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
-->
[dynMfail.zip](/uploads/384f0ef04572001fa268baf4d8ffcea3/dynMfail.zip)
### What is the current *bug* behaviour?
<!-- What actually happens -->
Restarting when using dynamic meshing fails with size error when using Crank Nicholson timeScheme.
### What is the expected *correct* behavior?
<!-- What you should see instead -->
The simulation restarts as a normal timestep would.
### 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
-->
```
Build : _c9081d5d-20230220 OPENFOAM=2212 patch=230110 version=2212
Arch : "LSB;label=32;scalar=64"
Exec : interFoam1
```
- Operating system : WSL Ubuntu 22.04
- Hardware info : Tested on Ryzen 5 2600 and Intel X chip
- Compiler : gcc?https://develop.openfoam.com/Development/openfoam/-/issues/2735BUG: function object: Failed to store pointer: grad(U). Risk of memory leakage2023-04-05T14:45:47ZJuan SalazarBUG: function object: Failed to store pointer: grad(U). Risk of memory leakage<!--
*** 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 running grad function object on U field, the following error is issued (occurs with postProcess option and/or during simulation):
"Failed to store pointer: grad(U). Risk of memory leakage"
Possibly related to Development/openfoam#2381, recommendation of including `useNamePrefix true;` in function object did not make the bug go away.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Run grad function object on turbulentFlatPlate tutorial (solver simpleFoam). I ran it on the setup with kOmegaSST with y plus = 1.
`postProcess -func "grad(U)"`
or
`simpleFoam -postProcess -latestTime`
with FO grad included in controlDict.
### 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
-->
As explained above. Below is modified controlDict from standard turbulentFlatPlateTutorial.
```
/*--------------------------------*- C++ -*----------------------------------*\
| ========= | |
| \\ / F ield | OpenFOAM: The Open Source CFD Toolbox |
| \\ / O peration | Version: v2206 |
| \\ / A nd | Website: www.openfoam.com |
| \\/ M anipulation | |
\*---------------------------------------------------------------------------*/
FoamFile
{
version 2.0;
format ascii;
class dictionary;
object controlDict;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
application simpleFoam;
startFrom startTime;
startTime 0;
stopAt endTime;
endTime 5000;
deltaT 1;
writeControl timeStep;
writeInterval 100;
purgeWrite 1;
writeFormat ascii;
writePrecision 8;
writeCompression off;
timeFormat general;
timePrecision 8;
runTimeModifiable true;
functions
{
minMax
{
type fieldMinMax;
libs ("libfieldFunctionObjects.so");
writeControl timeStep;
fields (U);
}
yPlus
{
type yPlus;
libs ("libfieldFunctionObjects.so");
patches (fixedWall);
writeControl writeTime;
}
#includeFunc "writeCellCentres"
#includeFunc "wallShearStress"
#include "FOgrad"
}
```
The file "FOgrad" is in system folder.
```
/*--------------------------------*- C++ -*----------------------------------*\
| ========= | |
| \\ / F ield | OpenFOAM: The Open Source CFD Toolbox |
| \\ / O peration | Version: v2212 |
| \\ / A nd | Website: www.openfoam.com |
| \\/ M anipulation | |
\*---------------------------------------------------------------------------*/
grad1
{
// Mandatory entries
type grad;
libs ("libfieldFunctionObjects.so");
field U;
// Optional (inherited) entries
useNamePrefix true;
//result gradientU;
log true;
writeControl outputTime;
}
grad2
{
// Mandatory entries
type grad;
libs ("libfieldFunctionObjects.so");
field phi;
// Optional (inherited) entries
result gradPhi;
log true;
writeControl outputTime;
}
// ************************************************************************* //
```
### What is the current *bug* behaviour?
Error `Failed to store pointer: grad(U). Risk of memory leakage` is issued.
<!-- What actually happens -->
### What is the expected *correct* behavior?
<!-- What you should see instead -->
gradient of U field should be computed and file created in time folder. Tested on v2212, v2206, v2112. Works as expected with version v1706.
### 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.
-->
OpenFOAM v2206
```
--> FOAM Warning :
From bool Foam::regIOobject::store()
in file /Users/jsalazar/openfoam/OpenFOAM-v2206/src/OpenFOAM/lnInclude/regIOobjectI.H at line 51
Refuse to store unregistered object: grad(U)
--> FOAM FATAL ERROR: (openfoam-2206)
Failed to store pointer: grad(U). Risk of memory leakage
From static Type &Foam::regIOobject::store(Type *) [Type = Foam::GeometricField<Foam::Tensor<double>, Foam::fvPatchField, Foam::volMesh>]
in file /Users/jsalazar/openfoam/OpenFOAM-v2206/src/OpenFOAM/lnInclude/regIOobjectI.H at line 73.
FOAM aborting
#0 Foam::error::printStack(Foam::Ostream&) in /Volumes/OpenFOAM/OpenFOAM-v2206/platforms/darwinARM64ClangDPInt32Opt/lib/libOpenFOAM.dylib
#1 Foam::error::simpleExit(int, bool) (.cold.2) in /Volumes/OpenFOAM/OpenFOAM-v2206/platforms/darwinARM64ClangDPInt32Opt/lib/libOpenFOAM.dylib
#2 Foam::error::simpleExit(int, bool) in /Volumes/OpenFOAM/OpenFOAM-v2206/platforms/darwinARM64ClangDPInt32Opt/lib/libOpenFOAM.dylib
#3 Foam::error::exiting(int, bool) in /Volumes/OpenFOAM/OpenFOAM-v2206/platforms/darwinARM64ClangDPInt32Opt/lib/libOpenFOAM.dylib
#4 Foam::GeometricField<Foam::Tensor<double>, Foam::fvPatchField, Foam::volMesh>& Foam::regIOobject::store<Foam::GeometricField<Foam::Tensor<double>, Foam::fvPatchField, Foam::volMesh> >(Foam::GeometricField<Foam::Tensor<double>, Foam::fvPatchField, Foam::volMesh>*) in /Volumes/OpenFOAM/OpenFOAM-v2206/platforms/darwinARM64ClangDPInt32Opt/lib/libfieldFunctionObjects.dylib
#5 bool Foam::functionObjects::regionFunctionObject::store<Foam::GeometricField<Foam::Tensor<double>, Foam::fvPatchField, Foam::volMesh> >(Foam::word&, Foam::tmp<Foam::GeometricField<Foam::Tensor<double>, Foam::fvPatchField, Foam::volMesh> > const&, bool) in /Volumes/OpenFOAM/OpenFOAM-v2206/platforms/darwinARM64ClangDPInt32Opt/lib/libfieldFunctionObjects.dylib
#6 bool Foam::functionObjects::grad::calcGrad<Foam::Vector<double> >() in /Volumes/OpenFOAM/OpenFOAM-v2206/platforms/darwinARM64ClangDPInt32Opt/lib/libfieldFunctionObjects.dylib
#7 Foam::functionObjects::fieldExpression::execute() in /Volumes/OpenFOAM/OpenFOAM-v2206/platforms/darwinARM64ClangDPInt32Opt/lib/libfieldFunctionObjects.dylib
#8 Foam::functionObjects::timeControl::execute() in /Volumes/OpenFOAM/OpenFOAM-v2206/platforms/darwinARM64ClangDPInt32Opt/lib/libOpenFOAM.dylib
#9 Foam::functionObjectList::execute() in /Volumes/OpenFOAM/OpenFOAM-v2206/platforms/darwinARM64ClangDPInt32Opt/lib/libOpenFOAM.dylib
#10 main in /Volumes/OpenFOAM/OpenFOAM-v2206/platforms/darwinARM64ClangDPInt32Opt/bin/simpleFoam
#11 start in /usr/lib/dyld
zsh: abort simpleFoam -postProcess -latestTime
```
OpenFOAM v2212
```
--> FOAM Warning :
From bool Foam::regIOobject::store()
in file /Volumes/OpenFOAM-v2212/src/OpenFOAM/lnInclude/regIOobjectI.H at line 51
Refuse to store unregistered object: grad(U)
--> FOAM FATAL ERROR: (openfoam-2212)
Failed to store pointer: grad(U). Risk of memory leakage
From static Type &Foam::regIOobject::store(Type *) [Type = Foam::GeometricField<Foam::Tensor<double>, Foam::fvPatchField, Foam::volMesh>]
in file /Volumes/OpenFOAM-v2212/src/OpenFOAM/lnInclude/regIOobjectI.H at line 73.
FOAM aborting
#0 Foam::error::printStack(Foam::Ostream&) in /Volumes/OpenFOAM-v2212/platforms/darwin64ClangDPInt32Opt/lib/libOpenFOAM.dylib
#1 Foam::error::simpleExit(int, bool) (.cold.2) in /Volumes/OpenFOAM-v2212/platforms/darwin64ClangDPInt32Opt/lib/libOpenFOAM.dylib
#2 Foam::error::simpleExit(int, bool) in /Volumes/OpenFOAM-v2212/platforms/darwin64ClangDPInt32Opt/lib/libOpenFOAM.dylib
#3 Foam::error::exiting(int, bool) in /Volumes/OpenFOAM-v2212/platforms/darwin64ClangDPInt32Opt/lib/libOpenFOAM.dylib
#4 Foam::GeometricField<Foam::Tensor<double>, Foam::fvPatchField, Foam::volMesh>& Foam::regIOobject::store<Foam::GeometricField<Foam::Tensor<double>, Foam::fvPatchField, Foam::volMesh> >(Foam::GeometricField<Foam::Tensor<double>, Foam::fvPatchField, Foam::volMesh>*) in /Volumes/OpenFOAM-v2212/platforms/darwin64ClangDPInt32Opt/lib/libfieldFunctionObjects.dylib
#5 bool Foam::functionObjects::regionFunctionObject::store<Foam::GeometricField<Foam::Tensor<double>, Foam::fvPatchField, Foam::volMesh> >(Foam::word&, Foam::tmp<Foam::GeometricField<Foam::Tensor<double>, Foam::fvPatchField, Foam::volMesh> > const&, bool) in /Volumes/OpenFOAM-v2212/platforms/darwin64ClangDPInt32Opt/lib/libfieldFunctionObjects.dylib
#6 bool Foam::functionObjects::grad::calcGrad<Foam::Vector<double> >() in /Volumes/OpenFOAM-v2212/platforms/darwin64ClangDPInt32Opt/lib/libfieldFunctionObjects.dylib
#7 Foam::functionObjects::fieldExpression::execute() in /Volumes/OpenFOAM-v2212/platforms/darwin64ClangDPInt32Opt/lib/libfieldFunctionObjects.dylib
#8 Foam::functionObjects::timeControl::execute() in /Volumes/OpenFOAM-v2212/platforms/darwin64ClangDPInt32Opt/lib/libOpenFOAM.dylib
#9 Foam::functionObjectList::execute() in /Volumes/OpenFOAM-v2212/platforms/darwin64ClangDPInt32Opt/lib/libOpenFOAM.dylib
#10 main in /Volumes/OpenFOAM-v2212/platforms/darwin64ClangDPInt32Opt/bin/simpleFoam
#11 start in /usr/lib/dyld
Abort trap: 6
```
OpenFOAM v2112
```
--> FOAM FATAL ERROR: (openfoam-2112)
Failed to store pointer: grad(U). Risk of memory leakage
From static Type &Foam::regIOobject::store(Type *) [Type = Foam::GeometricField<Foam::Tensor<double>, fvPatchField, Foam::volMesh>]
in file /Users/jsalazar/openfoam/OpenFOAM-v2112/src/OpenFOAM/lnInclude/regIOobjectI.H at line 67.
FOAM aborting
#0 Foam::error::printStack(Foam::Ostream&) in /Volumes/OpenFOAM/OpenFOAM-v2112/platforms/darwin64ClangDPInt32Opt/lib/libOpenFOAM.dylib
#1 Foam::error::simpleExit(int, bool) (.cold.2) in /Volumes/OpenFOAM/OpenFOAM-v2112/platforms/darwin64ClangDPInt32Opt/lib/libOpenFOAM.dylib
#2 Foam::error::simpleExit(int, bool) in /Volumes/OpenFOAM/OpenFOAM-v2112/platforms/darwin64ClangDPInt32Opt/lib/libOpenFOAM.dylib
#3 Foam::error::exiting(int, bool) in /Volumes/OpenFOAM/OpenFOAM-v2112/platforms/darwin64ClangDPInt32Opt/lib/libOpenFOAM.dylib
#4 Foam::GeometricField<Foam::Tensor<double>, Foam::fvPatchField, Foam::volMesh>& Foam::regIOobject::store<Foam::GeometricField<Foam::Tensor<double>, Foam::fvPatchField, Foam::volMesh> >(Foam::GeometricField<Foam::Tensor<double>, Foam::fvPatchField, Foam::volMesh>*) in /Volumes/OpenFOAM/OpenFOAM-v2112/platforms/darwin64ClangDPInt32Opt/lib/libfieldFunctionObjects.dylib
#5 bool Foam::functionObjects::regionFunctionObject::store<Foam::GeometricField<Foam::Tensor<double>, Foam::fvPatchField, Foam::volMesh> >(Foam::word&, Foam::tmp<Foam::GeometricField<Foam::Tensor<double>, Foam::fvPatchField, Foam::volMesh> > const&, bool) in /Volumes/OpenFOAM/OpenFOAM-v2112/platforms/darwin64ClangDPInt32Opt/lib/libfieldFunctionObjects.dylib
#6 bool Foam::functionObjects::grad::calcGrad<Foam::Vector<double> >() in /Volumes/OpenFOAM/OpenFOAM-v2112/platforms/darwin64ClangDPInt32Opt/lib/libfieldFunctionObjects.dylib
#7 Foam::functionObjects::fieldExpression::execute() in /Volumes/OpenFOAM/OpenFOAM-v2112/platforms/darwin64ClangDPInt32Opt/lib/libfieldFunctionObjects.dylib
#8 Foam::functionObjects::timeControl::execute() in /Volumes/OpenFOAM/OpenFOAM-v2112/platforms/darwin64ClangDPInt32Opt/lib/libOpenFOAM.dylib
#9 Foam::functionObjectList::execute() in /Volumes/OpenFOAM/OpenFOAM-v2112/platforms/darwin64ClangDPInt32Opt/lib/libOpenFOAM.dylib
#10 main in /Volumes/OpenFOAM/OpenFOAM-v2112/platforms/darwin64ClangDPInt32Opt/bin/simpleFoam
#11 start in /usr/lib/dyld
```
### 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 or v2206 or v2112
- Operating system : macOS. Also tested with OpenFOAM v2112 on docker container (Ubuntu 20.04)
- Hardware info : MacBookPro Apple M1 Max 2021.
- Compiler : clang (gcc on docker container)
### 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/2734Dockerhub containers for v2206 and above2023-06-19T13:37:22ZTimofey MukhaDockerhub containers for v2206 and aboveDear all,
I'm testing some CI tools for compiling OpenFOAM applications, and managed to get Cirrus CI to work nicely.
I currently have 2 workflows: one which installs OpenFOAM via apt-get and the other using an OpenCFD docker container f...Dear all,
I'm testing some CI tools for compiling OpenFOAM applications, and managed to get Cirrus CI to work nicely.
I currently have 2 workflows: one which installs OpenFOAM via apt-get and the other using an OpenCFD docker container from Dockerhub:
```
v2212_task:
container:
image: ubuntu:jammy
test_script:
- apt-get update
- apt-get install -y wget
- wget -q -O - https://dl.openfoam.com/add-debian-repo.sh | bash
- apt-get install -qq openfoam2212-dev
- /usr/bin/openfoam2212 wmake
v2112_task:
container:
image: opencfd/openfoam2112-dev
test_script:
- /usr/bin/openfoam2112 wmake
```
The one in the OpenCFD container runs 5 seconds and the other one about a minute, so it seems there is quite some benefit in using Dockerhub.
Which leads to the question: what is the status of the [Dockerhub repository](https://hub.docker.com/u/opencfd/)? The latest container seems to be 2112, so the two latest versions are missing. There is, however, a version-less container, which was updated 3 months ago. Is this a snapshot of the `develop` branch? I am aware of the new `openfoam-docker` script, which is very nice. But I don't think I can use it in the CI, since it will be launching Docker inside Docker. It seems that ideally one would like to have the containers on Dockerhub.
Best,
Timofeyhttps://develop.openfoam.com/Development/openfoam/-/issues/2733XiFoam tutorial moriyoshiHomogeneous fails with sigfpe2024-01-04T10:07:26ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comXiFoam tutorial moriyoshiHomogeneous fails with sigfpe<!--
*** 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 -->
combustion/XiFoam/RAS/moriyoshiHomogeneous tutorial does not run
### Steps to reproduce
cd combustion/XiFoam/RAS/moriyoshiHomogeneous
foamRunTutorials
### 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 above
### What is the current *bug* behaviour?
<!-- What actually happens -->
sigfpe when obtaining `psiu()` in the first iteration.
### 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 : v2212https://develop.openfoam.com/Development/openfoam/-/issues/2732An error occurred with the reconstructPar command2024-01-04T10:57:34Zliu haoAn error occurred with the reconstructPar command<!--
*** 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
An error occurred when executing the reconstructPar command with parallel computation
### Steps to reproduce
Run the example case
### 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
-->
Use Case From [https://turbmodels.larc.nasa.gov/naca0012_val.html](url) and https://github.com/tomrobin-teschner/OpenFOAMCaseGenerator [](url)
[Naca0012_number_of_processors_2_number_of_corrector_steps_3.zip](/uploads/174a417be398fc0c7f7af5d1ac8084fb/Naca0012_number_of_processors_2_number_of_corrector_steps_3.zip)
### 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.
-->
```
Reconstructing fields
region=region0
Time = 0.01
Reconstructing FV fields
Reconstructing volScalarFields
cp
--> FOAM FATAL IO ERROR: (openfoam-2206)
size 110 is not equal to the expected length 64
file: processor0/0.01/cp.boundaryField.farfield at line 7214 to 7215.
From Foam::Field<Type>::Field(const Foam::word&, const Foam::dictionary&, Foam::label) [with Type = double; Foam::label = int]
in file ./src/OpenFOAM/lnInclude/Field.C at line 218.
FOAM exiting
```
### 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 :v2206
- Operating system :windows
- Hardware info :N/A
- Compiler :gcc(Ubuntu on WSL)https://develop.openfoam.com/Development/openfoam/-/issues/2731Clarification on Lambda2 function object2023-09-29T12:54:35ZYannClarification on Lambda2 function object### Functionality to add/problem to solve
The description of the Lambda2 function object states:
> The Lambda2 function object computes the second largest eigenvalue of the sum of the square of the symmetrical and anti-symmetrical par...### Functionality to add/problem to solve
The description of the Lambda2 function object states:
> The Lambda2 function object computes the second largest eigenvalue of the sum of the square of the symmetrical and anti-symmetrical parts of the velocity gradient tensor.
But it seems the function actually computes the opposite value: -Lambda2
`return store
(
resultName_,
-eigenValues(SSplusWW)().component(vector::Y)
);`
This is a bit confusing, since negative Lambda2 values are supposed to indicate vortex cores while in OpenFOAM you need to look for positive values to get vortex cores.
### Target audience
Anyone using Lambda2 to visualize vortex structures
### Proposal
Two possible solutions:
1. writing the actual Lambda2 rather than -Lambda2
2. updating the function description to clearly mention the opposite value of Lambda2 is written
I don't really have a preference between these solutions, as long as the description matches the code to avoid misleading users.
### Links / references
This old thread put me on track: https://www.cfd-online.com/Forums/openfoam-post-processing/117005-lambda2-openfoam-utilities.htmlKutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2730faceAreaWeightAMI more verbose error2023-06-12T14:31:12ZRegő SimonfaceAreaWeightAMI more verbose error### Functionality to add/problem to solve
If the faceAreaWeightAMI class cannot find a target, it'll print the source face ID in the error which isn't that helpful.
### Target audience
AMI users
### Proposal
The current code in fa...### Functionality to add/problem to solve
If the faceAreaWeightAMI class cannot find a target, it'll print the source face ID in the error which isn't that helpful.
### Target audience
AMI users
### Proposal
The current code in faceAreaWeightAMI.C at line 363
```
FatalErrorInFunction
<< "Unable to set target face for source face " << srcFacei
<< abort(FatalError);
```
could be changed to:
```
FatalErrorInFunction
<< "Unable to set target face for source face " << srcFacei
<< " with centre: " << srcPatch0().faceCentres()[srcFacei] << abort(FatalError);
```
And instead of an error for example:
`Unable to set target face for source face 84468`
the user can find the problematic area immediately with the following tiny extra info:
`Unable to set target face for source face 84468 with centre: (0.138558 0.724811 1.9799)`v2306Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2729The calculation using slip velocity boundary condition on the wall in chtMult...2023-03-27T19:34:40ZLEI WANGThe calculation using slip velocity boundary condition on the wall in chtMultiRegionFoam can not converge<!--
*** 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 -->
### 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
-->
### What is the current *bug* behaviour?
<!-- What actually happens -->
### 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 :Ubuntu-18.04
- 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/2728fvGeometryScheme parallel does not handle transformations2023-03-23T14:15:07ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comfvGeometryScheme parallel does not handle transformations<!--
*** 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 parallel fvGeometryScheme does not handle transformations.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
- switch in system/fvSchemes the geometry scheme to use parallel
- in annularCombustor tutorial use ./Allrun.pre to run snappyHexMesh
- it will fail reporting a problem about hexRef8 anchors.
- works fine with `basic` scheme
### 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
### 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/2727New sigma turbulence model not included for compressible LES2023-04-13T10:14:13ZJulius BergmannNew sigma turbulence model not included for compressible LES<!--
*** 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
The new 'sigma' turbulence model introduced in v2206 for LES is not applicable for compressible simulations, but only for incompressible simulations. Maybe it was forgotten to be implemented in commit 54806ea7 , as the file [/src/TurbulenceModels/incompressible/turbulentTransportModels/turbulentTransportModels.C](https://develop.openfoam.com/Development/openfoam/-/blob/master/src/TurbulenceModels/incompressible/turbulentTransportModels/turbulentTransportModels.C) was altered but not [/src/TurbulenceModels/compressible/turbulentFluidThermoModels/turbulentFluidThermoModels.C](https://develop.openfoam.com/Development/openfoam/-/blob/master/src/TurbulenceModels/compressible/turbulentFluidThermoModels/turbulentFluidThermoModels.C).
### Possible fixes
Add the following lines to line 134 of the file [/src/TurbulenceModels/compressible/turbulentFluidThermoModels/turbulentFluidThermoModels.C](https://develop.openfoam.com/Development/openfoam/-/blob/master/src/TurbulenceModels/compressible/turbulentFluidThermoModels/turbulentFluidThermoModels.C):
```
#include "sigma.H"
makeLESModel(sigma);
```Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2726createPatch removes newly added patches2023-03-22T11:23:39ZDarren GarveycreatePatch removes newly added patchesI am using [CfdOf](https://github.com/jaheyns/CfdOF) to which in my use-case creates an empty patch using `createPatch` before extruding it with `extrudeMesh`. This approach appears to have broken between v2106 and v2206. I think the com...I am using [CfdOf](https://github.com/jaheyns/CfdOF) to which in my use-case creates an empty patch using `createPatch` before extruding it with `extrudeMesh`. This approach appears to have broken between v2106 and v2206. I think the commit ad6d3a088eb5bfeab806e159f25526a102deb3bc changed the behaviour, specifically with the removal of
```
void filterPatches(polyMesh& mesh, const wordHashSet& addedPatchNames)
```
Where `addPatchNames` was there to make sure that `createPatch` doesn't remove newly created patches when they have no faces.
The `system/createPatchDict` to reproduce this is simple:
```
pointSync false;
patches
(
{
name patch_0_1_back;
patchInfo
{
type patch;
}
constructFrom patches;
patches ();
}
);
```
The newer versions of `createPatch` (since v2206) add then remove this patch:
```
Removed zero-sized patch patch_0_1_back type patch at position 9
```
It is possible that this use-case isn't supported and/or there is a Better Way to do it. Is there a good reason this feature should not be added back into `createPatch` (before I look at doing that)?