Development issueshttps://develop.openfoam.com/groups/Development/-/issues2021-09-14T15:29:21Zhttps://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/1839floatingBodyWithSpring2020-09-12T11:43:46ZRouzbeh BertonfloatingBodyWithSpring<!--
*** 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
<!-- This is my first time using this webtool so please bear with me. I modified the floatingBodyWithSpring case. All steps worked fine except the last part, i.e. "overInterDyMFoam" solver. It happened with the floating object case as well. It seems that dynamicCode cannot be generated properly for oversetMesh cases.
--> FOAM FATAL IO ERROR:
Failed wmake "dynamicCode/_93c6c0c911bd9d43ecd43c7eeed7521aa9a7515d/platforms/linux64GccDPInt32Opt/lib/libcodeStream_93c6c0c911bd9d43ecd43c7eeed7521aa9a7515d.so"
-->
### 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?
<!-- It does not let the solver to run -->
### What is the expected *correct* behavior?
<!-- Solver should run[log.overInterDyMFoam](/uploads/16ace50b7cf365682bc2186fe2149b77/log.overInterDyMFoam) -->
### 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 : v1912
- Operating system : ubuntu
- Hardware info : DELL XPS
- Compiler : intel CORE i7 8th Gen
### 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/1840Execution error (buoyantPipleFoam + rPolynomial (thermoType) )2024-01-11T18:03:00Zsariew8Execution error (buoyantPipleFoam + rPolynomial (thermoType) )<!--
*** 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
On v2006, This combination, buoyantPimpleFoam + rPolynomial thermoType, of cases is not executed.
### Steps to reproduce
Two sample cases are attached. One is a feasible case and the other is an infeasible case. The only difference is "constant/thermophysicalProperties".
### Example case
See attached file.
[NoGoodCase.zip](/uploads/1164f6321e5e05d1719745ee534c74eb/NoGoodCase.zip)
[GoodCase.zip](/uploads/3c02b6953830842b419f79228674ce08/GoodCase.zip)
### 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 : v1806|v1812|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : 18.04
- Operating system : ubuntu
- Hardware info :
- Compiler : gcc (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0
### 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/1841gradingDescriptors ignore negative expansion2020-09-24T14:22:00ZMark OLESENgradingDescriptors ignore negative expansionReading from Istream does not correct for negative (inverse) expansion ratios.Reading from Istream does not correct for negative (inverse) expansion ratios.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/113BUG/ENH: incomplete installtion check with foamInstallationTest2017-03-16T08:30:19ZPrashant SonakarBUG/ENH: incomplete installtion check with foamInstallationTestThe utility performs check for basic installation and confirms success.
However if some of the dependencies are not resolved (e.g. CGAL, boost,...) few utilities will not be installed (e.g. surfaceFeatureExtract, snappyHexMesh,...) bu...The utility performs check for basic installation and confirms success.
However if some of the dependencies are not resolved (e.g. CGAL, boost,...) few utilities will not be installed (e.g. surfaceFeatureExtract, snappyHexMesh,...) but rest would be OK
I think foamInstallationTest should check overall picture and report
- missing dependencies (including any third-party)
- failed libraries/applications
etc...
@Mattijs
AdminAdminhttps://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/1844REVIEW: laplacianFoam2021-07-07T09:56:34ZKutalmış BerçinREVIEW: laplacianFoamKutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1845add dispatch tags2024-01-11T18:07:45ZMark OLESENadd dispatch tagsfor some places such as `refPtr` it would be useful to support construct read/write as well as construct read-only. However, there is no convenient or reliable means to do so.
Eg,
```
volScalarField fld(...);
refPtr someRef(fld);
```
Sh...for some places such as `refPtr` it would be useful to support construct read/write as well as construct read-only. However, there is no convenient or reliable means to do so.
Eg,
```
volScalarField fld(...);
refPtr someRef(fld);
```
Should this be a const reference or a non-const reference? Currently we only have construct from const-ref since relying on the constness of the supplied argument is fragile at best, or simply wrong.
Propose adding a tagged dispatch constructor. Eg,
```
//- Construct for a non-const reference to an object.
inline refPtr(T& obj, stdFoam::output_t) noexcept;
```
I think that `input_t` and `output_t` might be reasonable enough names (vs read/write) that might be possibly to use elsewhere as well. Would declare in stdFoam.H to make globally available.Mark 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/1847REQUEST: snGrad field function object2020-09-21T07:59:30ZChiara PesciREQUEST: snGrad field function object### Functionality to add/problem to solve
It would be nice to have a field function object which computes the surface normal gradient (snGrad) at a boundary patch/patches, with patch name provided as input by the user.
### Proposal
Th...### Functionality to add/problem to solve
It would be nice to have a field function object which computes the surface normal gradient (snGrad) at a boundary patch/patches, with patch name provided as input by the user.
### Proposal
The field FO could look like the div or grad FOs.
Cheers,
ChiaraKutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1848runTimePostProcessing unavailable in ubuntu/debian packages2024-01-11T18:09:09ZJohannes KneerrunTimePostProcessing unavailable in ubuntu/debian packages<!--
*** 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 runTimePostProcessing (vtk/images) is unavailable in the ubuntu package (openfoam2006-default).
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Install the ubuntu package and try to run any case that includes the visualization function object example.
### Example case
$FOAM_TUTORIALS/incompressible/pisoFoam/LES/motorBike
<!--
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 -->
When the solver is run, it shows a warning concerning the runTimePostProcessing: VTK was not compiled in. No output images are created.
### What is the expected *correct* behavior?
runTimePostProcessing working, creating output images.
<!-- 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.
-->
> ...
> Starting time loop
>
> streamLine streamLines:
> Employing velocity field U
> automatic track length specified through number of sub cycles : 5`
>
> Sampled surface:
> yNormal -> none, store on registry (samples.yNormal)
>
> --> FOAM Warning :
> ####
> runTimePostProcessing not available
> ####
> VTK libraries were not available at compilation time
>
> From bool Foam::functionObjectList::read()
> in file db/functionObjects/functionObjectList/functionObjectList.C at line 895
>
> --> while loading function object 'postPro1'
>
> forceCoeffs forces:
> rho: rhoInf
> Freestream density (rhoInf) set to 1
> Not including porosity effects
> ...
### Environment information
- OpenFOAM version : v2006
- Operating system : ubuntu focal (Linux version 4.19.76-linuxkit)
- Hardware info : custom docker image (dockerhub: JohK/toolchain-of:of_v2006 )
- Compiler : gcc
### Possible fixes
Have VTK Libraries available at compile time of the ubuntu package.
<!--
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
-->Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1850Overset with hybrid mesh components2020-09-22T07:43:06ZMohamedOverset with hybrid mesh componentsHello everyone,
I have noticed that all overset openfoam tutorial cases use Cartesian/block structured meshes.
Is this a limitation of the current overset implementation?
I tried using component meshes with hyprid meshes ( mixed quadrila...Hello everyone,
I have noticed that all overset openfoam tutorial cases use Cartesian/block structured meshes.
Is this a limitation of the current overset implementation?
I tried using component meshes with hyprid meshes ( mixed quadrilateral and triangles) but the simulation keeps crashing with floating point divide by zero error ( from what I understand)
While I could me making some sort of mistake ( although I just followed the same tutorial of the cylinder for overpimpledymfoam) but as 3D case with with hybrid component mesh.
So to confirm did any one confirm that openfoam overset works with hybrid mesh ( mixed hexa and tetrahedral) components?
Thankshttps://develop.openfoam.com/Development/openfoam/-/issues/1851Wrong link in build guide on webpage2020-09-22T16:28:12ZJohan RoenbyWrong link in build guide on webpageThe build guide on the webpage here:
[https://www.openfoam.com/code/build-guide.php](https://www.openfoam.com/code/build-guide.php)
contains a link to:
[https://develop.openfoam.com/Development/openfoam/-/wikis/page-build-code](https:...The build guide on the webpage here:
[https://www.openfoam.com/code/build-guide.php](https://www.openfoam.com/code/build-guide.php)
contains a link to:
[https://develop.openfoam.com/Development/openfoam/-/wikis/page-build-code](https://develop.openfoam.com/Development/openfoam/-/wikis/page-build-code)
which has no content.https://develop.openfoam.com/Development/openfoam/-/issues/1853BUG: volFieldValue: writes empty fields2020-12-16T18:16:52ZKutalmış BerçinBUG: volFieldValue: writes empty 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 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 -->
`volFieldValue` FO writes empty fields when the input entry is `writeFields=true`.
It is due to the `weightField` being empty when there are no weights, which caused the entire output to be empty instead of simply being unweighted.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
- Download/extract [cavity.zip](/uploads/bc44ba559eeaeb8d8f704038ab1bdf70/cavity.zip)
- ./Allrun
- Inspect `p_all` in the time directories.
### What is the expected *correct* behavior?
<!-- What you should see instead -->
`volFieldValue` FO should write non-empty fields.
### 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 : 18c68e6b74v2012Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1855expression bcs ignore zero fractionExpr2020-09-24T14:22:00ZMark OLESENexpression bcs ignore zero fractionExprAs noted by @orgogozo - a zero-value for fractionExpr is being ignoredAs noted by @orgogozo - a zero-value for fractionExpr is being ignoredMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1856profiling csv2020-11-17T13:15:23ZHenning Scheuflerprofiling csvProfiling your application is an important step in development. The new profiling feature drastically simplifies this process by just adding profiling triggers or macros in the relevant function or classes. When writing a test applicatio...Profiling your application is an important step in development. The new profiling feature drastically simplifies this process by just adding profiling triggers or macros in the relevant function or classes. When writing a test application using the profiling feature the timings can be written to a specific file by adding:
`profiling::print(fileName)`
However, the current format is hard to parse with another tool/language e.g. python:
```
profiling
{
trigger0
{
id 0;
description "application::main";
calls 1;
totalTime 2.50246;
childTime 2.41516;
active true;
}
trigger1
{
id 1;
parentId 0;
description "trigger";
calls 56;
totalTime 2.39554;
childTime 1.21259;
maxMem 260780;
active true;
}
.....
}
```
Would it be possible to add an alternative write format such as csv:?
trigger,id,parentId,description,calls,totalTime,childTime,maxMem,active
trigger0,0,application::main,1,2.50246,2.41516,true
The documentation of the profiling feature is very helpful but could be improved by adding the default write the location of the profiling file:
```
Detailed Description
Code profiling.
This is typically activated from within the system/controlDict as follows (defaults shown):
profiling
{
active true;
cpuInfo false;
memInfo false;
sysInfo false;
}
or simply using all defaults:
profiling
{}
The default output is timeName/uniform/profiling // added
```Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1857SprayParcel::calcBreakup function can create parcel with existing origId and ...2022-06-03T13:21:46ZDavid LudlowSprayParcel::calcBreakup function can create parcel with existing origId and origProc<!--
*** 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 -->
At line 295 in the calcBreakup function of SprayParcel.C, a new child parcel is created. Whilst
`child->origId()` is reset using `this->getNewParticleID()`, there is no similar reset for `child->origProc()`. This could
potentially result in two particles with the same origId and origProc.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
If the parent parcel has moved to a different processor since being created, this will mean the origProc of the child parcel is incorrect.
### 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
-->
No example, this is purely a code observation.
### 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 : v1806|v1812|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version :v2006 and earlier
- Operating system :any
- Hardware info :any
- Compiler :any
### 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
-->
Add the following line
child->origProc() = Pstream::myProcNo();v2206Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1858a missing fractionExpr should not always automatically equal 12020-09-24T14:22:00ZMark OLESENa missing fractionExpr should not always automatically equal 1mixed expression bcs are defined with up to three expressions:
- valueExpr
- gradientExpr
- fractionExpr
Missing values:
- missing valueExpr treated as zero
- missing gradientExpr treated as zero
- missing fractionExpr treated as one
T...mixed expression bcs are defined with up to three expressions:
- valueExpr
- gradientExpr
- fractionExpr
Missing values:
- missing valueExpr treated as zero
- missing gradientExpr treated as zero
- missing fractionExpr treated as one
Treating a missing fractionExpr like "1" makes sense for handling value expressions (when gradientExpr is missing), but does not really make sense when valueExpr itself is missing. For example,
```
{
gradientExpr " .... ";
}
```
The user would rightly expect that the gradient expression should be used, not ignored.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1859Force calculation depends on number of ranks2024-01-11T18:14:19ZDavidForce calculation depends on number of ranksWe currently face an issue with the force functionObject: depending on the total number of ranks in parallel runs the obtained forces differ.
We use `pimpleFoam` in combination with dynamic meshes to perform our simulations. The issue a...We currently face an issue with the force functionObject: depending on the total number of ranks in parallel runs the obtained forces differ.
We use `pimpleFoam` in combination with dynamic meshes to perform our simulations. The issue appeared originally in a rather complex application case and the best guess for the rank dependency there was the FV mesh motion solver itself. The behavior can be reproduced using the tutorial case `movingCone` of the latest release v2006. The tutorial includes a uniform mesh motion in x-direction, which is solved by the `velocityComponentLaplacian` solver of the `dynamicMotionSolverFvMesh` dynamic mesh. The force is evaluated at the moving interface with the `libforces.so` library, as usual. Since `wedge` type patches cannot be partitioned as expected with the latest OpenFOAM version, the out-of-plane patches have been switched from type `wedge` to the type `patch`.
We performed the simulation on a various number of ranks and looked at the resulting force at the moving interface. Comparing a serial run with a simulation on 5 x 5 = 25 ranks shows on the first time level a deviation around O(10^{-5}). At the final time level 3e-3s, a deviation of around O(10^{-6}) can be observed. Both measures are absolute deviations, so that the accuracy is clearly below machine accuracy. The force diff for all time steps is also attached `diff_serial_25_procs.log`.
[diff_serial_25_procs.log](/uploads/bee9f77b954044c5b458aee5375098c6/diff_serial_25_procs.log)
In a second step, the mesh movement has been removed. Since the non-zero fluid velocity is entirely triggered by the moving obstacle, a uniform inlet flow velocity of strength 1 is placed on the left side and an outlet is placed on the right side of the domain. Again, the force for a serial run and a 5 x 5 = 25 rank parallel run is considered. The deviation of the calculated force values is initially around O(10^{-6}) and at the final time level around O(10^{-9}). Thus, the differences do not disappear in case the mesh motion is deactivated. The complete log is also attached `diff_serial_25_procs_no_motion.log`.
[diff_serial_25_procs_no_motion.log](/uploads/baf0046cec48522b11295f4588df53e1/diff_serial_25_procs_no_motion.log)
I'm a bit puzzled about the reason. Although the attached log files contain only the `force.dat` file comparison, I also checked the console output for more than the default write precision in order to exclude round-off errors while creating the `force.dat` file. Also, selecting very (too) strict residual controls doesn't affect the observed differences.
Are there any hints for these differences?
Background:
We are performing black-box coupled FSI simulations with OpenFOAM using the [openfoam-adapter](https://github.com/precice/openfoam-adapter) and these differences can lead to severe differences for coupled simulations so that the entire coupled system converges to different states. In contrast to the tutorial setup, as described above, our original problem setup applies the displacement based FV mesh motion solver with time varying boundary conditions.Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1860chtMultiRegionTwoPhaseEulerFoam, Population Balance2020-12-28T11:46:27ZRobin KamenickychtMultiRegionTwoPhaseEulerFoam, Population Balance<!--
*** 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
Population balance (PPB) is not calculated when
`solveOnFinalIterOnly true;
`
is used for the PPB in fvSolution of chtMultiRegionTwoPhaseEulerFoam solver.
<!-- Summarize the bug encountered concisely -->
### Steps to reproduce
Use $FOAM_TUTORIALS/heatTransfer/chtMultiRegionTwoPhaseEulerFoam/solidQuenching2D.
Go in constant/water/phaseProperties setup to use predefined PPB:
Change following lines of code from:
````
type thermalPhaseChangeTwoPhaseSystem;
phases (gas liquid);
// phase change in the bulk of the fluid.
phaseChange off;
//populationBalances (bubbles);
gas {
type purePhaseModel;
diameterModel isothermal;
isothermalCoeffs
{
d0 5e-3;
p0 1e5;
}
Sc 0.7;
velocityGroupCoeffs
{
populationBalance bubbles;
formFactor 0.5235987756;
sizeGroups
(
f0 {d 0.5e-4; value 0 ;}
f1 {d 1.040e-3; value 0 ;}
f2 {d 1.640e-3; value 0 ;}
f3 {d 2.265e-3; value 0 ;}
f4 {d 2.889e-3; value 0 ;}
f5 {d 3.512e-3; value 0 ;}
f6 {d 4.141e-3; value 0 ;}
f7 {d 4.771e-3; value 1 ;}
f8 {d 5.402e-3; value 0 ;}
f9 {d 6.033e-3; value 0 ;}
f10 {d 6.665e-3; value 0 ;}
f11 {d 7.297e-3; value 0 ;}
f12 {d 7.929e-3; value 0 ;}
f13 {d 8.562e-3; value 0 ;}
f14 {d 9.194e-3; value 0 ;}
f15 {d 1.194e-2; value 0 ;}
f16 {d 2.400e-2; value 0 ;}
f17 {d 2.700e-2; value 0 ;}
f18 {d 3.000e-2; value 0 ;}
);
}
residualAlpha 1e-4;
}
````
into
````
type thermalPhaseChangePopulationBalanceTwoPhaseSystem;
phases (gas liquid);
// phase change in the bulk of the fluid.
phaseChange off;
populationBalances (bubbles);
gas
{
type purePhaseModel;
diameterModel velocityGroup;
velocityGroupCoeffs
{
populationBalance bubbles;
formFactor 0.5235987756;
sizeGroups
(
f0 {d 0.5e-4; value 0 ;}
f1 {d 1.040e-3; value 0 ;}
f2 {d 1.640e-3; value 0 ;}
f3 {d 2.265e-3; value 0 ;}
f4 {d 2.889e-3; value 0 ;}
f5 {d 3.512e-3; value 0 ;}
f6 {d 4.141e-3; value 0 ;}
f7 {d 4.771e-3; value 1 ;}
f8 {d 5.402e-3; value 0 ;}
f9 {d 6.033e-3; value 0 ;}
f10 {d 6.665e-3; value 0 ;}
f11 {d 7.297e-3; value 0 ;}
f12 {d 7.929e-3; value 0 ;}
f13 {d 8.562e-3; value 0 ;}
f14 {d 9.194e-3; value 0 ;}
f15 {d 1.194e-2; value 0 ;}
f16 {d 2.400e-2; value 0 ;}
f17 {d 2.700e-2; value 0 ;}
f18 {d 3.000e-2; value 0 ;}
);
}
residualAlpha 1e-4;
}
````
further change lines
````
coalescenceModels
(
PrinceBlanch
{
C1 0.05;
h0 1e-4;
hf 1e-8;
turbulentCollisions true;
buoyantCollisions false;
laminarShearCollisions false;
}
);
````
into
````
coalescenceModels
(
PrinceBlanch
{
C1 0.05;
h0 1e-4;
hf 1e-8;
turbulence true;
buoyancy false;
laminarShear false;
}
);
````
and
````
driftModels
(
phaseChange
{
pairNames (gasAndLiquid);
}
densityChange{}
);
````
into
````
driftModels
(
phaseChange
{
pairs ((gas and liquid));
}
densityChange{}
);
````
Then change following line in constant/water/turbulenceProperties.liquid from
````
simulationType laminar;
````
into
````
simulationType RAS;
````
Then run
````
$./Allrun
````
When you have a look at the log.chtMultiRegionTwoPhaseEulerFoam you will see that no PPB is calculated during any iteration.
Change following lines in system/water/fvSolution
````
solveOnFinalIterOnly true;
````
into
````
solveOnFinalIterOnly false;
````
run
````
$./Allclean
$./Allrun
````
in the log.chtMultiRegionTwoPhaseEulerFoam, you can see the PPB being calculated each iteration.
<!-- How one can reproduce the issue - this is very important -->
### Example case
Mentioned in the step to reproduce. Shown at a tutorial 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?
No PPB is calculated if chosen to run only during the last iteration.
<!-- What actually happens -->
### What is the expected *correct* behavior?
User should be able to choose when the PPB runs. User might think that the PPB runs during the last iteration even though it is not apparent in the log. However, the true is it does not run at all. Explanation in the fix section.
<!-- 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 : v1806|v1812|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v1906
- Operating system : Ubuntu 16.04.6 LTS
- Hardware info :
- Compiler : gcc
Most probably, the same issue will be also with v2006.
### Possible fixes
The problem is that chtMultiRegionTwoPhaseEulerFoam does not cunstruct object of pimpleControl class and does not use it. It is rather "hard coded" in the solver to be able to do the iterations based on the user choice. However, populationBalanceModel class uses the pimpleControl class. Then it comes to line populationBalanceModel.C:1236
````
if (!solveOnFinalIterOnly || pimple_.finalIter())
````
where it decides whether to calculate the PPB. If the `solveOnFinalIterOnly true`, it means that this if condition should evaluate true only when `pimple_.finalIter() = true`, but that never happen because the function pimple_.finalIter() gives false
````
inline bool Foam::pimpleControl::finalIter() const
{
return converged_ || (corr_ == nCorrPIMPLE_);
}
````
because the corr_ is always equal to zero.
Some time ago, I worked on the same solver using the version of OpenFOAM Foundation. There is available class called pimpleMultiRegionControl, which manages the pimple logic for multiregion solvers. Having that, I only made a copy of populationBalanceModel class and changed the costructer to use pimpleMultiRegionControl instead of pimpleControl. Certainly, this leads to code duplication because majority of lines for populationBalanceModel are same. Further more if pimpleMultiRegionControl is used in ESI group version then other multiregion solvers should be adjusted adequatly.
Certainly, there might be some other ways how to pass the information about the last iteration to populationBalanceModel class.
<!--
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
-->