openfoam issueshttps://develop.openfoam.com/Development/openfoam/-/issues2021-07-08T20:32:29Zhttps://develop.openfoam.com/Development/openfoam/-/issues/1823interCondensatingEvaporatingFoam: wrong temperature field inside vapour in ph...2021-07-08T20:32:29ZSebastian BorrmanninterCondensatingEvaporatingFoam: wrong temperature field inside vapour in phase-transition region near interface<!--
*** 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 initialized a vapor-bubble inside a rectangular liquid domain and set the heat conduction in the vapor to 0 (in order to visualize the problem). The condensation and evaporation coefficients are set to 0. The top wall is hot and the bottom wall cold, gravity is off. A temperature gradient emerges in the liquid as expected.
The wrong behavior occurs in the vapor-bubble near the interface, in the alpha-transition region, where 0 < alpha < 1. The temperature gradient that should only be present in the liquid phase also travels into this transition-region inside the vapor-phase (note that it is not smeared according to alpha in this region, but continued from the liquid) I discussed this problem with colleagues and we couldn't find a physical reason for this behavior. It seams that the temperature-field inside the vapor is only correct if alpha is exactly 0 (or at least smaller than 1e-8).
<!-- Summarize the bug encountered concisely -->
### Steps to reproduce
Run the attached testcase (Allrun), look at the alpha- and temperature-field in paraview and compare their size.
<!-- How one can reproduce the issue - this is very important -->
### Example case
[bugreport.tar.gz](/uploads/eeff365fc1b69b64c7e90888464536c9/bugreport.tar.gz)
<!--
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?
The temperature-field of the surrounding field is present in the alpha-transition region inside the bubble near the interface.
<!-- What actually happens -->
### What is the expected *correct* behavior?
The temperature should be constant everywhere in the bubble, due to heat conduction kappa = 0.
<!-- What you should see instead -->
### Relevant logs and/or images
![camparison](/uploads/adcc705a6dfd4cb5052fe553a860acc5/camparison.png "Temperature-field (left) and alpha-field (right)")
Temperature-field (left) and alpha-field (right)
![temperatureInAlphaClip05](/uploads/623224fc46a9de86cedce5b0a9b713b8/temperatureInAlphaClip05.png "Temperature field inside the bubble (clipped with alpha = 0.5)")
Temperature field inside the bubble (clipped with alpha = 0.5)
<!--
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 : tested in v1912 (fixed version with interface.correct()) and v2006
- Operating system : debian
- Hardware info :
- Compiler : gcc
### Possible fixes
Didn't find one yet.
<!--
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
-->v2112Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2126more consistent version output2021-09-09T16:16:25ZMark OLESENmore consistent version outputCurrently output the WM_PROJECT_VERSION in the top banner, but probably more reasonable to have the current API value instead.
Can recover the WM_PROJECT_VERSION in the "Build: ... " output.Currently output the WM_PROJECT_VERSION in the top banner, but probably more reasonable to have the current API value instead.
Can recover the WM_PROJECT_VERSION in the "Build: ... " output.v2112Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1846REQUEST: yPlus FO error message in "postProcess -func yPlus" mode2021-09-14T15:29:00ZChiara PesciREQUEST: yPlus FO error message in "postProcess -func yPlus" mode### Functionality to add/problem to solve
When executing the yPlus function object as "postProcess -func yPlus" the following warning is issued:
```
--> FOAM Warning :
From virtual bool Foam::functionObjects::yPlus::execute()
i...### Functionality to add/problem to solve
When executing the yPlus function object as "postProcess -func yPlus" the following warning is issued:
```
--> FOAM Warning :
From virtual bool Foam::functionObjects::yPlus::execute()
in file yPlus/yPlus.C at line 166
Unable to find turbulence model in the database: yPlus will not be calculated
```
while running the FO as
`<solverName> -postProcess -func yPlus`
or directly during run time works fine.
### Proposal
It would be nice to substitute the warning message with something like "yPlus function in postProcess mode not supported". The current message is misleading and the user would think there is an error in the turbulence model setup, even though the latter is correct.v2112Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2287mismatch in autoMap function?2021-12-10T13:05:39ZMark OLESENmismatch in autoMap function?Compiler warnings for newly added code:
```
filmPyrolysisRadiativeCoupledMixedFvPatchScalarField.H:222:26: warning: 'Foam::filmPyrolysisRadiativeCoupledMixedFvPatchScalarField::autoMap' hides overloaded virtual function [-Woverloaded-vi...Compiler warnings for newly added code:
```
filmPyrolysisRadiativeCoupledMixedFvPatchScalarField.H:222:26: warning: 'Foam::filmPyrolysisRadiativeCoupledMixedFvPatchScalarField::autoMap' hides overloaded virtual function [-Woverloaded-virtual]
virtual void autoMap
^
temperatureCoupledBase.H:205:22: note: hidden overloaded virtual function 'Foam::temperatureCoupledBase::autoMap' declared here: type mismatch at 1st parameter ('const Foam::FieldMapper &' vs 'const Foam::fvPatchFieldMapper &')
virtual void autoMap
^
filmPyrolysisRadiativeCoupledMixedFvPatchScalarField.H:228:26: warning: 'Foam::filmPyrolysisRadiativeCoupledMixedFvPatchScalarField::rmap' hides overloaded virtual function [-Woverloaded-virtual]
virtual void rmap
^
temperatureCoupledBase.H:211:22: note: hidden overloaded virtual function 'Foam::temperatureCoupledBase::rmap' declared here: type mismatch at 1st parameter ('const Foam::temperatureCoupledBase &' vs 'const fvPatchField<Foam::scalar> &' (aka 'const fvPatchField<double> &'))
virtual void rmap
^
```
There are a few more, but this is the gist of it. Warnings raised by clang-13v2112Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/2286support alternative location for build intermediate2021-12-10T13:05:51ZMark OLESENsupport alternative location for build intermediateCurrently build intermediates (eg, various `.dep` and `.o` files) are split out into a separate directory. For example,
```
project
|-- applications
|-- src
|-- build
| \-- linux64Gcc...
|-- platforms
| \-- linux64Gcc...
```
This g...Currently build intermediates (eg, various `.dep` and `.o` files) are split out into a separate directory. For example,
```
project
|-- applications
|-- src
|-- build
| \-- linux64Gcc...
|-- platforms
| \-- linux64Gcc...
```
This generally works well for intermediates (build) separated from final (platforms), however if we wish to rebuild portions of the code is can be a slight problem if the entire volume is readonly.
If the OpenFOAM directory is readonly, then we cannot writing into the project directory, but perhaps not into the source Make/ subdirectory either. For these cases (or maybe if we want to have the build intermediates land on faster disk), support `FOAM_BUILDROOT` and/or `wmake -build-root=...`.
Already made similar local changes to ThirdParty.v2112Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2283invert matching regex2021-12-05T14:33:35ZMark OLESENinvert matching regexIssue raised by @andy and @Mattijs - could be useful to have an inverted regex matching.
Eg,
```
"(?!).*processor.*"
```
to match anything that does not contain 'processor'
We already handle the PCRE-prefix "(?i)" - so relatively si...Issue raised by @andy and @Mattijs - could be useful to have an inverted regex matching.
Eg,
```
"(?!).*processor.*"
```
to match anything that does not contain 'processor'
We already handle the PCRE-prefix "(?i)" - so relatively simple to extend the prefix handling.
cross-ref: EP1748v2112Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2282no coded Function12021-12-05T14:33:43ZMark OLESENno coded Function1While discussing some solutions for fan remapping with @THO - we thought of using a CodedFunction1 for handling things, however there is only a CodedPatchFunction1. Seems to be an oversight, or wasn't needed so often.
cross-ref: EP1752While discussing some solutions for fan remapping with @THO - we thought of using a CodedFunction1 for handling things, however there is only a CodedPatchFunction1. Seems to be an oversight, or wasn't needed so often.
cross-ref: EP1752v2112Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2279inconsistent input parameters for fan BCs2021-12-05T14:33:52ZMark OLESENinconsistent input parameters for fan BCssome fan BCs have rpm as scalar, others as Function1. Some parameters (eg, fan efficiency) may be lost on copy and output.some fan BCs have rpm as scalar, others as Function1. Some parameters (eg, fan efficiency) may be lost on copy and output.v2112Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2276extend dictionary directives2021-11-26T12:27:23ZMark OLESENextend dictionary directivesOn [an issue raised on cfd-online](https://www.cfd-online.com/Forums/openfoam-programming-development/239595-possible-use-info-inside-calc-print-string.html), the user was attempting to use `#calc` to report dictionary values. For exampl...On [an issue raised on cfd-online](https://www.cfd-online.com/Forums/openfoam-programming-development/239595-possible-use-info-inside-calc-print-string.html), the user was attempting to use `#calc` to report dictionary values. For example,
```
myVariable 42;
#calc "Info << $myVariable << endl";
```
which supposed works somehow, but I cannot figure out how.
In a somewhat similar vein (in EP1742), they were misusing `#calc` to perform string concatenation. For example,
```
_foName #calc #{ "some_prefix_solverInfo_${application}" #};
$_foName
{
type solverInfo;
libs (utilityFunctionObjects);
fields (".*");
}
#remove _foName;
```
As both cases illustrate, there must be a better way to solve this.v2112Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2263noise model - enable user defined reference for dB calc2021-11-08T18:57:39ZAndrew Heathernoise model - enable user defined reference for dB calcCross ref EP 1689Cross ref EP 1689v2112Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/issues/2254update of third-party packages for v21122022-06-27T09:34:39ZMark OLESENupdate of third-party packages for v2112Currently:
- ADIOS2-2.6.0
- CGAL-4.12.2
- ParaView-v5.9.1
- boost_1_66_0
- fftw-3.3.7
- openmpi-4.0.3
- scotch_6.1.0
- kahip-2.12
My thoughts:
- ADIOS: could probably bump to 2.7.1 (Jan 2021)
- CGAL: @andy is conservative there (been b...Currently:
- ADIOS2-2.6.0
- CGAL-4.12.2
- ParaView-v5.9.1
- boost_1_66_0
- fftw-3.3.7
- openmpi-4.0.3
- scotch_6.1.0
- kahip-2.12
My thoughts:
- ADIOS: could probably bump to 2.7.1 (Jan 2021)
- CGAL: @andy is conservative there (been bitten badly in the past), but can try moving to the latest bugfix 4.x version (4.14.2 - Nov 2019). Cannot/should not move to 5.x since this requires c++14 and thus breaks installation on centos7, SUSE 12 etc.
- ParaView: definitely want paraview 5.10 which has our various changes in it. Currently in a release candidate stage and should be finished in time.
- boost: no opinion. openSUSE still ships with 1_66_0 as well
- fftw: 3.3.10 bugfix version
- openmpi: either 4.0.6 as bugfix for the 4.0.x or try with 4.1.1 (latest stable)
- scotch: no change
- kahip: currently at 3.11 - need to see what has improved.
@Development : Wanted to get people's opinions about updating what we bundle as _ThirdParty_.
Do we drop shipping paraview sources anytime soon?
EDITS:
- paraview now at 5.10.0-RC2 (22 Nov)v2112https://develop.openfoam.com/Development/openfoam/-/issues/2173Make precision adaptors modifiable2021-09-09T16:15:08ZMark OLESENMake precision adaptors modifiableCurrently the precision adaptors are fixed at construction time. However, if we use `refPtr` internally, we can make them adjustable after construction.
Eg,
```
labelList dummyAdj;
labelList dummyXAdj;
ConstPrecisionAdaptor<SCOTCH_Num...Currently the precision adaptors are fixed at construction time. However, if we use `refPtr` internally, we can make them adjustable after construction.
Eg,
```
labelList dummyAdj;
labelList dummyXAdj;
ConstPrecisionAdaptor<SCOTCH_Num, label, List> adjncy_param(adjncy);
if (adjcny.empty())
{
dummyAdj.resize(1, Zero);
dummyXAdj.resize(1, Zero);
adjncy_param.set(dummyAdj);
...
}
```v2112Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2170Add inGroups support for zones2021-09-09T16:15:20ZMark OLESENAdd inGroups support for zonesOne of the topics that has been discussed with @Mattijs is having overlapping zones. This would be convenient for many things, but would also violate a one-to-one mapping that zones currently have.
One possibility would to reuse/refacto...One of the topics that has been discussed with @Mattijs is having overlapping zones. This would be convenient for many things, but would also violate a one-to-one mapping that zones currently have.
One possibility would to reuse/refactor the patchIdentifier for zones and use its inGroup grouping.v2112Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2155FA reconstruct wrongly mapping FA fields after parallel run using parallel ma...2021-12-23T13:00:30ZSergio FerrarisFA reconstruct wrongly mapping FA fields after parallel run using parallel makeFaMeshWhen FA mesh is generated in parallel , the reconstructPart maps fa fields wrongly.
Run:
tutorials/finiteArea/liquidFilmFoam/cylinder/Allrun-parallel, then
reconstructPar
Creating faMesh is serial and decomposing it, the reconstruct f...When FA mesh is generated in parallel , the reconstructPart maps fa fields wrongly.
Run:
tutorials/finiteArea/liquidFilmFoam/cylinder/Allrun-parallel, then
reconstructPar
Creating faMesh is serial and decomposing it, the reconstruct fields are OK.v2112Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2132BUG: turbulenceFields: Local omega funcs are unused2021-08-04T13:32:32ZKutalmış BerçinBUG: turbulenceFields: Local omega funcs are unused<!--
*** 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 -->
- turbulenceFields.C#L185-188
```
case cfOmega:
{
processField<scalar>(f, omega(model));
break;
}
```
calls the `omega` of `turbulenceFields` rather than `model.omega()`.
- Another issue is that using `simulationType laminar;`, albeit unrealistic, unforgivingly throws fatal error - ceasing simulation.
- Also, the `nuTilda` expression of `turbulenceFields` is incorrect. `nuTilda` is not equal to `k/omega`:
```
template<class Model>
Foam::tmp<Foam::volScalarField>
Foam::functionObjects::turbulenceFields::nuTilda
(
const Model& model
) const
{
return tmp<volScalarField>::New
(
"nuTilda.tmp",
model.k()/omega(model)
);
}
```
### 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
-->
```
base1 = develop
api = 2106
patch = 0
HEAD = 3825c4ee95
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
```v2112Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2101BUG: atmBoundaryLayerInlet2021-09-16T12:21:53ZJunting ChenBUG: atmBoundaryLayerInlet<!--
*** 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 -->
Every write resets z0 value to 0 on atmBoundaryLayerInlet boundaries
It will create issue when restarting from certain time step. Found this issue in Openfoam v2012.
Junting Chen
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
1. in the 0 directory, use z0 of anything. Can be simplest cases.
2. run this simulation to a time step for example 200.
3. vim into the U file in the latest time stamp
4. You will see z0 on the inlet boundary has been reset to 0.
### 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 : v2012
Operating system : centos (i dont think it matters)
Hardware info : any info that may help?
Compiler : gcc
-->
- OpenFOAM version : v2012
- Operating system : centos (i dont think it matters)
- Hardware info : VM
- Compiler : gcc
### 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
-->v2112Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2048ccmToFoam -merge option leads to negative volume mesh2022-03-15T18:40:16ZYoujiang WangccmToFoam -merge option leads to negative volume mesh<!--
*** 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 use the option -merge with ccmToFoam, negative volume mesh will be generated near the merged interface. Without -merge option, there would be no problem. The reason has been found, and you might fix it in next version.
### 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 : v2012
- Operating system : openSUSE
- Hardware info :
- Compiler : gcc
### 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
-->
The probem is caused by the generation and usage of mergedPointMap in line 1937 and line 1953 of the file ccmReaderMesh.C. I added several lines to modify mergedPointMap between them, and then the problem vanished. The added lines look like
```
labelList pointRemap;
pointRemap.setSize(mergedPointMap.size());
pointRemap = -1;
forAll(mergedPointMap, i)
{
if (pointRemap[mergedPointMap[i]] < 0)
{
pointRemap[mergedPointMap[i]] = i;
}
}
forAll(mergedPointMap, i)
{
mergedPointMap[i] = pointRemap[mergedPointMap[i]];
}
```
I know it is absolutely not the best the solution, but may help you to know the reason better. Thank you!v2112Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1843BUG: nutLowReWallFunction: missing turbulent viscosity in yPlus func2021-09-14T15:28:26ZKutalmış BerçinBUG: nutLowReWallFunction: missing turbulent viscosity in yPlus func<!--
*** 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 -->
`nutLowReWallFunction` computes $`y^+`$ by (nutLowReWallFunctionFvPatchScalarField.C#L123):
```math
y^+ = \frac{ y \sqrt{\nu_w |\textbf{u}|_\textbf{n} } }{ \nu_w }
```
The generalisation of $`y^+`$ computation (see yPlus.C#L153) requires the $`\nu_w`$ in the numerator to be replaced by the effective viscosity on patch (fluid viscosity + turbulent viscosity):
```math
y^+ = \frac{ y \sqrt{\nu_{eff} |\textbf{u}|_\textbf{n} } }{ \nu_w }
```
Although effects of turbulent viscosity in the lower part of the viscous sublayer can be neglected, this simplification starts to break down towards the buffer layer.
### 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 : all supported versionsv2112Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1838BUG: nut{k,U}WallFunction: incorrect y+ estimations for viscous sublayer2021-09-14T15:29:21ZKutalmış BerçinBUG: nut{k,U}WallFunction: incorrect y+ estimations for viscous sublayer<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be re...<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be rendered on the platform by using the
"preview" tab above
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
<!-- Summarize the bug encountered concisely -->
In a nutWallFunction-simulation, when `yPlus` FO is called, the FO calls `yPlus()` of the nutWallFunction (unless the new commit 3e41c100 is in place).
`yPlus()` contains the y+ definition specific to the chosen nutWallFunction rather than the formal definition of y+ in order to ensure various consistencies.
`yPlus()` of some of the nutWallFunctions produces incorrect results for y+<10 (i.e. approximately viscous sublayer).
The affected items are:
- `yPlus` FO
- [compressible::alphatJayatillekeWallFunction#L239](https://develop.openfoam.com/Development/openfoam/-/blob/master/src/TurbulenceModels/compressible/turbulentFluidThermoModels/derivedFvPatchFields/wallFunctions/alphatWallFunctions/alphatJayatillekeWallFunction/alphatJayatillekeWallFunctionFvPatchScalarField.C#L239)
- [alphatJayatillekeWallFunction#L242](https://develop.openfoam.com/Development/openfoam/-/blob/master/src/TurbulenceModels/incompressible/turbulentTransportModels/derivedFvPatchFields/wallFunctions/alphatWallFunctions/alphatJayatillekeWallFunction/alphatJayatillekeWallFunctionFvPatchScalarField.C#L242)
### Minimal working example
<!-- How one can reproduce the issue - this is very important -->
See !381 for a MWE.
### Problem
<!-- What actually happens -->
Although each nutWallFunction correctly computes and blends nut predictions for viscous and inertial sublayers according to their definitions, `yPlus()` computes only the inertial sublayer y+.
Therefore, predictions for viscous sublayer y+ from `yPlus()` are incorrect.
### Environment
<!--
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 : 7be3092414/all maintained versions
- Operating system : opensuse
- Compiler : gcc/clang
### Possible fixes
<!--
If you can, link to the line of code that might be responsible for the
problem
The "/label ~bug" text is a gitlab flag that will add the "bug" label to this
issue
-->
- Compute viscous and inertial sublayer y+ **nominal** (theoretical?) predictions in `yPlus()`, and blend them according to the chosen blending method. The missing information = how can we compute the **nominal** y+ for the sub-inertial region from dependent variables, e.g. `k`.
- Extend the analytical expression of the inertial sublayer up to the boundary by covering the viscous sublayer by using Spalding's law of the wall.v2112Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1763columnAverage2021-07-07T08:56:50ZSeo Dong-HocolumnAverageLooking into a directory "controlDict" in a tutorial "periodicHill', to apply "columnAverage", patches is set "patches (front "proc.*throughfront");". By the way, I do not clearly understand what "proc.*throughfront" means. Actually, thi...Looking into a directory "controlDict" in a tutorial "periodicHill', to apply "columnAverage", patches is set "patches (front "proc.*throughfront");". By the way, I do not clearly understand what "proc.*throughfront" means. Actually, this case has two patches "front" and "back" at the ends of the spanwise direction. Please let me know this.
Moreover, do I have to include two patches "front" and "back" together to do the spanwise average?, otherwise, only one patch "front" or "back" should be included like "patches (front);"?
Thank you.v2112Kutalmış BerçinKutalmış Berçin