Development issueshttps://develop.openfoam.com/groups/Development/-/issues2020-04-01T16:55:25Zhttps://develop.openfoam.com/Development/openfoam/-/issues/1643BUG: ddt FO throws warning message for legitimate input fields2020-04-01T16:55:25ZKutalmış BerçinBUG: ddt FO throws warning message for legitimate input fields<!--
*** 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
For a `volVectorField` input, say `U`, `ddt` FO throws a warning message:
```
--> FOAM Warning : functionObjects::ddt ddt1 cannot find required object U of type volScalarField
```
however in the subsequent line of log, reports the successful execution:
```
functionObjects::ddt ddt1 writing field: ddtU
```
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
`cd $FOAM_TUTORIALS/incompressible/pisoFoam/RAS/cavity`
Append the following to `controlDict`:
```
functions
{
ddt1
{
// Mandatory entries
type ddt;
libs (fieldFunctionObjects);
field U;
// Optional (inherited) entries
result ddtU;
}
}
```
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v1806|v1812|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : dev
- Operating system : osuse
- Compiler : clang7 && gcc4
### 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
-->
Another layer of type selection into `ddt:calc()` should solve the problem.v2006https://develop.openfoam.com/Development/openfoam/-/issues/1638BUG: Zero (complex) to the power of zero (label/scalar) does not follow Gcc/C...2020-03-19T16:33:55ZKutalmış BerçinBUG: Zero (complex) to the power of zero (label/scalar) does not follow Gcc/Clang<!--
*** 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
There is no agreed value for zero to the power of zero in C++ standard, but C99.
Despite this, `Gcc` and `Clang` implementations assume `Type(0)^0 = 1`.
In OpenFOAM, when `Type=complex`, the assumption is not followed even though `Foam::pow` is based on `std::pow`. When `Type=scalar`, the above assumption is followed.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
[Test-A.tar.gz](/uploads/abc926c1291683e8e861c5961d7edcbe/Test-A.tar.gz) produces the following:
```
# FOAM: complex(0)^0 #
Foam::pow(Foam::complex, label) = (-nan -nan)
Foam::pow(Foam::complex, scalar) = (-nan -nan)
std::pow(std::complex, label) = (-nan -nan)
std::pow(std::complex, scalar) = (-nan -nan)
# std: complex(0)^0 #
std::complex(scalar,scalar)^scalar = (1,0)
# FOAM: scalar(0)^0 #
Foam::pow(scalar, label) = 1
Foam::pow(scalar, scalar) = 1
# std: scalar(0)^0 #
std::pow(scalar, label) = 1
std::pow(scalar, scalar) = 1
```
### What is the expected *correct* behavior?
<!-- What you should see instead -->
`Foam::pow` should return whatever `std::pow` returns for complex types.
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v1806|v1812|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : dev
- Operating system : osuse
- Compiler : gcc 7v2006Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1635BUG: argList::noBanner silently suppresses foamDictionary -includes output2020-04-15T08:53:56ZKutalmış BerçinBUG: argList::noBanner silently suppresses foamDictionary -includes output<!--
*** 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
`foamDictionary -includes system/controlDict` does not return #include headers.
The reason is that even though `::Foam::infoDetailLevel` is initialised to 1, it is assigned to zero in `argList::noBanner()`. This converts `DetailInfo` macro to a no-op as is executed in `functionEntries::includeEntry::execute()`, therefore no call is made to `Info`.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
`cd $FOAM_TUTORIALS/incompressible/simpleFoam/motorBike`
`foamDictionary -includes system/controlDict`
which will return nothing unlike OFv1712 that returns the #include headers.
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v1806|v1812|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : dev
- Operating system : osuse
- Compiler : gccv2006Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1632objToVTK broken since v18122020-03-16T11:20:40ZThorsten ZirwesobjToVTK broken since v1812Since v1812, `objToVTK` does not work.
**How to reproduce:**
Convert any .obj file to .vtk, e.g.:
```
cp -r $FOAM_TUTORIALS/incompressible/icoFoam/cavity/cavity .
cd cavity
blockMesh -blockTopology
objToVTK blockTopology.obj test.vtk ...Since v1812, `objToVTK` does not work.
**How to reproduce:**
Convert any .obj file to .vtk, e.g.:
```
cp -r $FOAM_TUTORIALS/incompressible/icoFoam/cavity/cavity .
cd cavity
blockMesh -blockTopology
objToVTK blockTopology.obj test.vtk # fails
```
**Error message:**
```
--> FOAM FATAL IO ERROR:
Bad token - could not get word
file: input at line 0.
From function Foam::Istream& Foam::operator>>(Foam::Istream&, Foam::word&)
in file primitives/strings/word/wordIO.C at line 48.
```
Versions up to (and including) v1806 work fine. v1812, v1906 and v1912 exhibit the error. The generated `blockTopology.obj` is the same among all versions, so the culprit seems to be `objToVTK`.v2006Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/issues/1630Possible inconsistency in documentation2020-06-12T17:35:40ZMathieu OlivierPossible inconsistency in documentationThis is not a critical issue, but I feel it deserves some attention.
In file src/TurbulenceModels/turbulenceModels/derivedFvPatchFields/wallFunctions/omegaWallFunctions/omegaWallFunction/omegaWallFunctionFvPatchScalarField.H, it is stat...This is not a critical issue, but I feel it deserves some attention.
In file src/TurbulenceModels/turbulenceModels/derivedFvPatchFields/wallFunctions/omegaWallFunctions/omegaWallFunction/omegaWallFunctionFvPatchScalarField.H, it is stated in the documentation (at the beginning of the file) that the default value of the "blended" switch is set to "false". However, by looking at the constructors in omegaWallFunctionFvPatchScalarField.C, it seems that the default value is rather set to "true". Am I missing something?
Thank you!
Mathieu Olivierv2006Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1617BUG: circular call to write for gradientEnergyFvPatchScalarField.C2020-03-13T14:55:36ZAndrew HeatherBUG: circular call to write for gradientEnergyFvPatchScalarField.CIn the virtual `::write(Ostream& os)` function the call to
```
os.writeEntry("value", *this)
```
uses the field `<<` operator to write the value field, which in turn (via `fvPatchField`) calls the `::write(Ostream&)` function again and g...In the virtual `::write(Ostream& os)` function the call to
```
os.writeEntry("value", *this)
```
uses the field `<<` operator to write the value field, which in turn (via `fvPatchField`) calls the `::write(Ostream&)` function again and gets locked in an infinite loop.
Current remedy: fields cannot be written to stream using the `os.writeEntry(<name>, <field>)` form---instead use `<field>.writeEntry(<name>, os)`. For the future, look to update the `Ostream::writeEntry` function.
Note: need to check other boundary condition `::write(Ostream&)` functions
~bugv2006https://develop.openfoam.com/Development/openfoam/-/issues/1603waveAlpha in v19122024-01-11T17:17:49ZKarim RakhawaveAlpha in v1912waveAlpha is not recognized in v1912 and works on v1906.waveAlpha is not recognized in v1912 and works on v1906.v2006Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1597v1912 over*DyMFoam tutorials fail on multi-node parallel2020-10-06T21:23:24ZGreg Burgreenv1912 over*DyMFoam tutorials fail on multi-node parallelDo the v1912 tutorial cases overInterDyMFoam/floatingBody and overPimpleDyMFoam/simpleRotor work for you guys for a multi-node parallel run?
They both work fine for me serial and on a single parallel node. Once I try multi-node parallel...Do the v1912 tutorial cases overInterDyMFoam/floatingBody and overPimpleDyMFoam/simpleRotor work for you guys for a multi-node parallel run?
They both work fine for me serial and on a single parallel node. Once I try multi-node parallel processing, I am getting either scrambled garbage for the field variables (floatingBody) or returns segFault or sigFpe on a random iteration (simpleRotor). It appears that data is not being properly transferred across compute nodes.
I am using Scotch decomposition and OpenMPI-4.0.0.
```
PIMPLE: iteration 1
[2] [5] #0 #0 Foam::error::printStack(Foam::Ostream&)Foam::error::printStack(Foam::Ostream&) at at ??:?
[2] #1 Foam::sigFpe::sigHandler(int)??:?
[5] #1 Foam::sigFpe::sigHandler(int) at ??:?
[2] #2 ? at ??:?
[5] #2 ? in /lib64/libc.so.6
[2] #3 Foam::divide(Foam::Field<double>&, double const&, Foam::UList<double> const&) in /lib64/libc.so.6
[5] #3 Foam::divide(Foam::Field<double>&, double const&, Foam::UList<double> const&) at ??:?
[2] #4 void Foam::divide<Foam::fvPatchField, Foam::volMesh>(Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh>&, Foam::dimensioned<double> const&, Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh> const&) at ??:?
[5] #4 at ??:?
```v2006Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1594columeAverage2020-06-12T17:30:26Zzein elserfycolumeAverageI am using openFoam version 1906 on ubuntu 14.06 operating system and i have tried to use one of the new functions (columnAverage) but it seems that something is wrong with it. I used it in order to perform a spatial average in the span-...I am using openFoam version 1906 on ubuntu 14.06 operating system and i have tried to use one of the new functions (columnAverage) but it seems that something is wrong with it. I used it in order to perform a spatial average in the span-wise direction (z-direction) but the results are not correct.
The function is added to controlDict
``
` columnAverage
{
type columnAverage;
libs ("libfieldFunctionObjects.so");
writeControl writeTime;
patches (front);
fields (p pPrime2Mean wallShearStressMean);
}`
I have the front plane is normal to z-direction,so i choose the front plane as a patches in the columnAverage function
The result of pPrime2Mean wallShearStressMean are shown below
pPrime
![Pprime](/uploads/4175845d08a3119c7d8cc4916ee98c84/Pprime.JPG)
WallShearStressMean
![wallshear_stress_mean](/uploads/724adad7592a0392735afdf6232f5e5c/wallshear_stress_mean.JPG)
The columnAverage results seems to be incorrect
![Pprimecolumn](/uploads/10773ccda50dac9c5cb81dc4d8100eb1/Pprimecolumn.JPG)
![wallshear_stress_meancolumn](/uploads/41fe99af62f8a59dfc2b1e7aff6cff33/wallshear_stress_meancolumn.JPG)v2006Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1584link to the verification of the tutorial case surfaceMounrtedCube2020-02-12T17:31:43ZSon Volink to the verification of the tutorial case surfaceMounrtedCubeThe link to the verification of the case surfaceMountedCube is stated here:
https://develop.openfoam.com/Development/openfoam/blob/develop/tutorials/incompressible/pimpleFoam/LES/surfaceMountedCube/README
The link is
openfoam.com/docu...The link to the verification of the case surfaceMountedCube is stated here:
https://develop.openfoam.com/Development/openfoam/blob/develop/tutorials/incompressible/pimpleFoam/LES/surfaceMountedCube/README
The link is
openfoam.com/documentation/cpp-guide/html/verification-validation-turbulent-surface-mounted-cube.html
but cannot be found in the internet.
Son.v2006Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1579improvements foamToEnsightParts2020-06-22T10:10:10ZMark OLESENimprovements foamToEnsightPartsCurrently foamToEnsight and foamToEnsightParts perform somewhat differently.
- foamToEnsight works in serial/parallel, but does not handle cellZones
- foamToEnsightParts handles cellZone, but only works in serial
Desirable to retain ce...Currently foamToEnsight and foamToEnsightParts perform somewhat differently.
- foamToEnsight works in serial/parallel, but does not handle cellZones
- foamToEnsightParts handles cellZone, but only works in serial
Desirable to retain cellZone information in parallel as well, which implies making foamToEnsightParts parallel-aware. Explore the possibility of merging some foamToEnsightParts aspects into ensightMesh (ie, foamToEnsight) and enabling/disabling on a switch.
Cross-ref: EP1109v2006Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1573Add support for automatically reading "fileName.orig" files if the correspond...2020-01-29T03:40:36ZAlberto PassalacquaAdd support for automatically reading "fileName.orig" files if the corresponding "fileName" is absentCurrently, .orig files are used to back files up before performing initialization with utilities such as setFields.
However, the .orig files either
1. Need to be rename with rm or a script
2. The utility foamRestoreFiles -method orig...Currently, .orig files are used to back files up before performing initialization with utilities such as setFields.
However, the .orig files either
1. Need to be rename with rm or a script
2. The utility foamRestoreFiles -method orig -withZero must be executed, which renames the .orig files on the 0 directory instead of renaming a copy of the same files, effectively destroying the .orig file
The .org version has implemented a feature to read the .orig files automatically if the corresponding "non .orig" file is missing: https://github.com/OpenFOAM/OpenFOAM-dev/commit/df6e2da2dd89227cee05c0bc0c1bf4f9b80849d5 This feature would make the process of preserving .orig files a lot simpler and transparent to the user.v2006https://develop.openfoam.com/Development/openfoam/-/issues/1568waveModel.C fails in debug mode2020-12-10T19:25:20ZPer JørgensenwaveModel.C fails in debug mode<!--
*** 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
In debug mode a size check failing in src/waveModels/waveModel/waveModel.C
### Steps to reproduce
just run a waves tutorial in debug mode.
It fails in
const vectorField CfLocal(Rgl_ & Cf);
### Example case
e.g. the stokesV tutorial
### What is the current *bug* behaviour?
I don't know what happens and if it matters, but you can't run wave generation in debug mode.
### What is the expected *correct* behavior?
that size should be equal
### Relevant logs and/or images
<!--
Paste any relevant logs - please use code blocks (```) to format console
output, logs, and code as it's very hard to read otherwise.
-->
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v1806|v1812|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version :1906
- Operating system :ubuntu 1804
- Hardware info :intel i7-8700K
- Compiler :gcc 7.4
### 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
-->v2006Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1560BUG: extra nu term in kEpsilonPhitF's normalised wall-normal fluctuating velo...2020-01-23T09:44:02ZKutalmış BerçinBUG: extra nu term in kEpsilonPhitF's normalised wall-normal fluctuating velocity scaleRelated to https://develop.openfoam.com/Community/Documentation/issues/94
@chiRelated to https://develop.openfoam.com/Community/Documentation/issues/94
@chiv2006Kutalmış BerçinKutalmış Berçin2020-01-31https://develop.openfoam.com/Development/openfoam/-/issues/1559BUG: Some of the tutorial links in the web and PDF guides are broken2020-01-17T10:04:36ZKutalmış BerçinBUG: Some of the tutorial links in the web and PDF guides are brokenRelated to #975
For instance, the link at the beginning of the `Lid-driven cavity flow` is broken due to the repo migration:
https://www.openfoam.com/documentation/tutorial-guide/tutorialse2.php#x6-60002.1
**Fix:** Changing `OpenFOAM-...Related to #975
For instance, the link at the beginning of the `Lid-driven cavity flow` is broken due to the repo migration:
https://www.openfoam.com/documentation/tutorial-guide/tutorialse2.php#x6-60002.1
**Fix:** Changing `OpenFOAM-plus` to `openfoam`, e.g.
https://develop.openfoam.com/Development/OpenFOAM-plus/tree/master/tutorials/incompressible/icoFoam/cavity/cavity
https://develop.openfoam.com/Development/openfoam/tree/master/tutorials/incompressible/icoFoam/cavity/cavityv2006Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/issues/1552ReactingOneDim model diffusion number calculation not parallel consistent2020-02-02T17:18:48ZAndrew HeatherReactingOneDim model diffusion number calculation not parallel consistentThe `DiNum` value computed in the `solidRegionDiffNo` function is not parallel consistent and can lead to run failures, see:
https://develop.openfoam.com/Development/openfoam/blob/master/src/regionModels/pyrolysisModels/reactingOneD...The `DiNum` value computed in the `solidRegionDiffNo` function is not parallel consistent and can lead to run failures, see:
https://develop.openfoam.com/Development/openfoam/blob/master/src/regionModels/pyrolysisModels/reactingOneDim/reactingOneDim.C#L609v2006Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/issues/1550BUG: compressible/rhoCentralFoam/LadenburgJet60psi always returns 0 residual ...2020-01-13T07:35:13ZKutalmış BerçinBUG: compressible/rhoCentralFoam/LadenburgJet60psi always returns 0 residual for rho*```
cd $FOAM_TUTORIALS/compressible/rhoCentralFoam/LadenburgJet60psi
blockMesh
rhoCentralFoam > log
```
Inspection of `log`, the first iteration:
```
diagonal: Solving for rho, Initial residual = 0, Final residual = 0, No Iterations 0...```
cd $FOAM_TUTORIALS/compressible/rhoCentralFoam/LadenburgJet60psi
blockMesh
rhoCentralFoam > log
```
Inspection of `log`, the first iteration:
```
diagonal: Solving for rho, Initial residual = 0, Final residual = 0, No Iterations 0
diagonal: Solving for rhoUx, Initial residual = 0, Final residual = 0, No Iterations 0
diagonal: Solving for rhoUy, Initial residual = 0, Final residual = 0, No Iterations 0
diagonal: Solving for rhoUz, Initial residual = 0, Final residual = 0, No Iterations 0
smoothSolver: Solving for Ux, Initial residual = 2.72671585531381e-10, Final residual = 5.52189393354249e-17, No Iterations 2
smoothSolver: Solving for Uy, Initial residual = 8.9793398319517e-10, Final residual = 3.88308482399956e-17, No Iterations 2
smoothSolver: Solving for Uz, Initial residual = 2.46779639576239e-05, Final residual = 4.26968989376592e-17, No Iterations 2
diagonal: Solving for rhoE, Initial residual = 0, Final residual = 0, No Iterations 0
smoothSolver: Solving for e, Initial residual = 5.10620283617839e-10, Final residual = 2.0953930462529e-16, No Iterations 2
ExecutionTime = 0.04 s ClockTime = 0 s
```
Last iteration:
```
deltaT = 2.63043719245516e-09
Time = 2e-05
diagonal: Solving for rho, Initial residual = 0, Final residual = 0, No Iterations 0
diagonal: Solving for rhoUx, Initial residual = 0, Final residual = 0, No Iterations 0
diagonal: Solving for rhoUy, Initial residual = 0, Final residual = 0, No Iterations 0
diagonal: Solving for rhoUz, Initial residual = 0, Final residual = 0, No Iterations 0
smoothSolver: Solving for Ux, Initial residual = 5.96253571018462e-09, Final residual = 6.04621493842968e-17, No Iterations 2
smoothSolver: Solving for Uy, Initial residual = 1.94043363575857e-08, Final residual = 4.05549649159743e-17, No Iterations 2
smoothSolver: Solving for Uz, Initial residual = 1.22670886698518e-07, Final residual = 3.52512229257255e-17, No Iterations 2
diagonal: Solving for rhoE, Initial residual = 0, Final residual = 0, No Iterations 0
smoothSolver: Solving for e, Initial residual = 1.12199018788273e-08, Final residual = 2.11044025910839e-16, No Iterations 2
ExecutionTime = 78.01 s ClockTime = 78 s
```
@Prashant , would you please mind to run this tutorial in one of the old versions, if you have an installation, e.g. 1706? It runs fairly quickly.
#1531v2006Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1522Add OpenQBMM2020-02-10T15:21:01ZMark OLESENAdd OpenQBMMAs per discussions with @andy and @albertop - aim to add OpenQBMM in as a submodule for 1912.
Alberto has rejiged some bits to compile will 1906 (only some deprecation warnings for dimensionedType that can be safely ignored). I've recom...As per discussions with @andy and @albertop - aim to add OpenQBMM in as a submodule for 1912.
Alberto has rejiged some bits to compile will 1906 (only some deprecation warnings for dimensionedType that can be safely ignored). I've recompiled his branch with the 1912 develop and nothing came up with gcc-7.4.
May need to recheck with gcc-4.8.5, but probably not too bad.
As soon as we get a _mostly_ finalized branch (even better, tagged) can add the submodule.
Q: The subdirectory name as under modules/OpenQBMM, modules/open-qbmm ...? We are flexible.v2006Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/647ENH: turbulentMixingLengthDissipationRateInlet Cmu lookup for realizableKE2020-06-12T17:35:58ZAdminENH: turbulentMixingLengthDissipationRateInlet Cmu lookup for realizableKEIn turbulentMixingLengthDissipationRateInletFvPatchScalarField.C Cmu appears to be looked up or defaulted to a constant of 0.09...
```c
// Lookup Cmu corresponding to the turbulence model selected
const turbulenceModel& turbModel = ...In turbulentMixingLengthDissipationRateInletFvPatchScalarField.C Cmu appears to be looked up or defaulted to a constant of 0.09...
```c
// Lookup Cmu corresponding to the turbulence model selected
const turbulenceModel& turbModel = db().lookupObject<turbulenceModel>
(
IOobject::groupName
(
turbulenceModel::propertiesName,
internalField().group()
)
);
const scalar Cmu =
turbModel.coeffDict().lookupOrDefault<scalar>("Cmu", 0.09);
```
It looks like Cmu is being looked up from the turbulence dictionary in turbulenceProperties. However, for turbulence models like realizableKE where Cmu is not constant, I think Cmu should be looked up from the turbulence model itself. Am I reading this correctly? Thoughts?
\## Reattaching the author to the issue ticket: @graups ##v2006Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/939Negative Normal Components in UPrime2Mean Patch Fields - channel395DFSEM2020-06-16T16:22:58ZKutalmış BerçinNegative Normal Components in UPrime2Mean Patch Fields - channel395DFSEMHi,
**Problem**: I observed **negative** values in the normal components of UPrime2Mean, e.g. u'u', on *patch fields* (not internal fields) in a tutorial as well as in-house case. These components, however, are by definition positive.
...Hi,
**Problem**: I observed **negative** values in the normal components of UPrime2Mean, e.g. u'u', on *patch fields* (not internal fields) in a tutorial as well as in-house case. These components, however, are by definition positive.
**MWE**: Please run `OpenFOAM-v1712/channel395DFSEM` tutorial with `UPrime2Mean` on. For an arbitrary instant of solution, executing
`postProcess -func minMaxComponents'(UPrime2Mean)' -latestTime` yields:
```
...
Executing functionObjects
fieldMinMax minMaxComponents(UPrime2Mean) write:
min(UPrime2Mean) = (-110.6187451010895 -71.67069008796911 -57.02833388170411 -15.05621144511252 -12.23325724312694 -8.60988994091587) in cell 17517 at location (0 1.869010129293147 3.122436600824001)
max(UPrime2Mean) = (6.906486416596863 1.071684114359736 0.9375168777607903 0.7322488089670033 0.1589319170416081 1.301374985649687) in cell 1529601 at location (50.83096913508285 1.891711244092694 0.3256528970184543)
...
```
As can be seen, negative values appear in the UPrime2Mean normal components. Manual inspection showed me that these negative values exist in patch fields, rather than internal fields.
Kind regards,v2006Kutalmış BerçinKutalmış Berçin