Development issueshttps://develop.openfoam.com/groups/Development/-/issues2022-09-29T13:23:23Zhttps://develop.openfoam.com/Development/openfoam/-/issues/2594useImplicit in chtMultiRegionFoam where temperature equation exists2022-09-29T13:23:23Zt RockuseImplicit in chtMultiRegionFoam where temperature equation exists### Functionality to add/problem to solve
I have ported `compressibleInterFoam` into the fluid section of `chtMultiRegionFoam` to have a two-phase VoF solver with conjugated heat transfer.
The solver will work with explicit boundary cou...### Functionality to add/problem to solve
I have ported `compressibleInterFoam` into the fluid section of `chtMultiRegionFoam` to have a two-phase VoF solver with conjugated heat transfer.
The solver will work with explicit boundary coupling. However, it would be nice to have the `useImplicit` feature available when working with `T` instead of `he`.
Is there any reason for restring the use of implicit coupling to the `he` field?
### Target audience
All people interested in using `TEqn` for conjugated heat transfer instead of `EEqn`
### Proposal
(How are we going to solve the problem?)
Since boundary conditions are specified for the temperature field, solve for T on the background and allow the direct use of TEqn in the coupled approach?https://develop.openfoam.com/Development/openfoam/-/issues/2593Cut2022-09-26T14:42:26Zomar SallamCutDear all, I am new to this version of OpenFOAM.
Any advice how I can simulate stokes wave with underwater current.
Basically, I am simulating floating structure in waves and underwater current.
Thanks in advance.Dear all, I am new to this version of OpenFOAM.
Any advice how I can simulate stokes wave with underwater current.
Basically, I am simulating floating structure in waves and underwater current.
Thanks in advance.https://develop.openfoam.com/Development/openfoam/-/issues/2592questionable handling of finite-area edge and Le normals2022-12-23T16:52:52ZMark OLESENquestionable handling of finite-area edge and Le normalsAs noted by @kuti with an industrial case, failures in the geometry sanity check occur in `processorFaPatch::calcGeometry()` with complaints that neighbour edge lengths deviate from the expected (local) edge lengths.
FYI: @swapnilsalokheAs noted by @kuti with an industrial case, failures in the geometry sanity check occur in `processorFaPatch::calcGeometry()` with complaints that neighbour edge lengths deviate from the expected (local) edge lengths.
FYI: @swapnilsalokheMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2591add finite-area support to setFields2022-10-26T07:16:47ZMark OLESENadd finite-area support to setFieldscross-ref EP1960cross-ref EP1960Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2590tabulated thermophysicalProperties not working2022-09-23T16:24:25Zmieszkotabulated thermophysicalProperties not working<!--
*** 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
tabulated thermophysicalProperties such as: tabulated, IcoTabulated, hTabulated,
seems to be not compiled because cannot be used and are not listed among possible choices in
Valid rhoReactionThermo types :
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
### Example case
<!--
If possible, please create a SMALL example and attach it to your report
If you are using an older version of OpenFOAM this will also determine
whether the bug has been fixed in a more recent version
-->
### What is the current *bug* behaviour?
<!-- What actually happens -->
### What is the expected *correct* behavior?
<!-- What you should see instead -->
### Relevant logs and/or images
<!--
Paste any relevant logs - please use code blocks (```) to format console
output, logs, and code as it's very hard to read otherwise.
-->
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v2206|v2112|v2106|v2012|v2006 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version :
- Operating system :
- Hardware info :
- Compiler :
### Possible fixes
<!--
If you can, link to the line of code that might be responsible for the
problem
The "/label ~bug" text is a gitlab flag that will add the "bug" label to this
issue
-->https://develop.openfoam.com/Development/openfoam/-/issues/2589BUG: mergePatchPairs fails with edge shared patches2022-10-31T07:29:03ZPrashant SonakarBUG: mergePatchPairs fails with edge shared patches<!--
*** 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 merging blocks inside blockMesh, we get failure cross ref EP#1999
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
### Example case
Attached 3 cells (1 cell in each block) blockMesh example works when we don't merge any/single patchPair. However when using both patchPairs, it fails.
[blockMeshDict-test](/uploads/997a8630db320303e76e6ba77addbb3d/blockMeshDict-test)
<!--
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
-->Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2588propellerInfo function object cannot find MRFProperties file2022-09-20T16:52:59ZNikola MajksnerpropellerInfo function object cannot find MRFProperties file
### Summary
When using `rotationMode MRF;` in `propellerInfo` function object `MRFProperties` file is not found even if it exists in `constant/MRFProperties`
### Steps to reproduce
1. Modify propellerInfo file to use `MRFProperties`...
### Summary
When using `rotationMode MRF;` in `propellerInfo` function object `MRFProperties` file is not found even if it exists in `constant/MRFProperties`
### Steps to reproduce
1. Modify propellerInfo file to use `MRFProperties` and run `simpleFoam -postProcess`
2. It produces an error below.
### What is the current *bug* behaviour?
Running for example `simpleFoam -postProcess` produces error below.
```
--> FOAM FATAL IO ERROR: (openfoam-2206)
Unable to find MRFProperties in the database. Is this an MRF case?
```
### What is the expected *correct* behavior?
No errors and function object executed successfully.
### Environment information
- OpenFOAM version : v2206|v2112
- Operating system : ubuntu 22.04
### Possible fixes
```
const auto* MRFZones =
new IOMRFZoneList(mesh_);
```
Using this code instead of the code below fixes the issue, but I think there might be a better way to do it, as I'm not OpenFOAM programming expert.
```
const auto* MRFZones =
mesh_.cfindObject<IOMRFZoneList>("MRFProperties");
```
https://develop.openfoam.com/Development/openfoam/-/blob/master/src/functionObjects/forces/propellerInfo/propellerInfo.C#L82
https://develop.openfoam.com/Development/openfoam/-/blob/master/src/functionObjects/forces/propellerInfo/propellerInfo.C#L148https://develop.openfoam.com/Development/openfoam/-/issues/2587Build OpenFoam with MPICH2022-10-26T07:19:00ZSebastian GutierrezBuild OpenFoam with MPICHHello, <br>
I have been trying to install OpenFoam from source by using MPICH instead of OpenMPI, I am using a Linux machine and I already installed MPICH from "sudo apt-get install mpich" but when I try to build OpenFoam using the comma...Hello, <br>
I have been trying to install OpenFoam from source by using MPICH instead of OpenMPI, I am using a Linux machine and I already installed MPICH from "sudo apt-get install mpich" but when I try to build OpenFoam using the command Allwmake I got an error like this:
```
Compile OpenFOAM libraries
ln: OpenFOAM/lnInclude
ln: OSspecific/POSIX/lnInclude
wmake libo (POSIX)
wmake dummy (mpi=SYSTEMOPENMPI)
wmake dummy
wmake mpi (mpi=SYSTEMOPENMPI:sys-openmpi)
wmake mpi
gcc: error: unrecognized command-line option '--showme:compile'
g++ -std=c++11 -m64 -pthread -DOPENFOAM=2206 -DWM_DP -DWM_LABEL_SIZE=32 -Wall -Wextra -Wold-style-cast -Wnon-virtual-dtor -Wno-unused-parameter -Wno-invalid-offsetof -Wno-attributes -Wno-unknown-pragmas -O3 -DNoRepository -ftemplate-depth-100 -DMPICH_SKIP_MPICXX -DOMPI_SKIP_MPICXX -Wno-old-style-cast -Wno-unused-local-typedefs -Wno-array-bounds -Wno-deprecated-declarations -fpermissive -iquote. -IlnInclude -I/opt/openfoam/OpenFOAM-v2206/src/OpenFOAM/lnInclude -I/opt/openfoam/OpenFOAM-v2206/src/OSspecific/POSIX/lnInclude -fPIC -c PstreamGlobals.C -o /opt/openfoam/OpenFOAM-v2206/build/linux64GccDPInt32OptSYSTEMOPENMPI/src/Pstream/mpi/PstreamGlobals.o
In file included from PstreamGlobals.C:28:
PstreamGlobals.H:42:10: fatal error: mpi.h: No such file or directory
42 | #include <mpi.h>
| ^~~~~~~
compilation terminated.
make: *** [/opt/openfoam/OpenFOAM-v2206/wmake/rules/General/transform:35: /opt/openfoam/OpenFOAM-v2206/build/linux64GccDPInt32OptSYSTEMOPENMPI/src/Pstream/mpi/PstreamGlobals.o] Error 1
```
I do not know what I am doing wrong, I want to know if I need to change something inside the configuration files.
Thank youhttps://develop.openfoam.com/Development/openfoam/-/issues/2586Potential bug while using multiple solvers with dynamicOversetFvMesh2022-09-20T16:52:40Zsuyash vermaPotential bug while using multiple solvers with dynamicOversetFvMesh<!--
*** 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 -->
I am trying to use two motion solvers simultaneously with dynamicOversetFvMesh. One of the solver "displacementLaplacian" morphs the mesh based on the linear oscillation defined in the pointDisplacement Boundary condition file. The other solver moves the overset mesh using solidBodyMotionSolver or multiSolidBodyMotionSolver functionality.
Now, While running the simulation, I am noticing that the second solver seems to function only on every alternate time steps rather than executing every timestep. The displacementLaplacian solver appears to function at every timestep.
While using multiSolidBodyMotionSolver with tabulated6DoFMotion function, it can also be noticed that the overset mesh actually returns to it's t_0 position at every alternate timestep.
I have seen the tutorial for floatingBodyWithSpring, where the application of two different solvers is pretty much the same as my case. But I am not sure why I am getting such an issue.
### 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
-->
I have attached my example case of a Translating flat plate with overPimpleDyMFoam solver, to reproduce the exact behaviour.
Just need to run "overPimpleDyMFoam".[HeavePlate_Issue.zip](/uploads/2548f0052021a0baa4a06f6f587da570/HeavePlate_Issue.zip)
### What is the current *bug* behaviour?
<!-- What actually happens -->
The overset mesh return to its t_0 position at every alternate time step. The mesh morphing, however, seems to update nicely at every time-step.
If we remove the displacementLaplacian solver, and just use the solidBodyMotionSolver or multiSolidBodyMotionSolver functionality, there is no issue.
### What is the expected *correct* behavior?
<!-- What you should see instead -->
The overset mesh should not return to its t_0 position at every alternate time step. It should update to the new position from the last time-step position.
### 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|v1912
Operating system : ubuntu
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2012|v1912
- Operating system : ubuntu
- Hardware info :
- Compiler :
### Possible fixes
<!--
If you can, link to the line of code that might be responsible for the
problem
The "/label ~bug" text is a gitlab flag that will add the "bug" label to this
issue
-->https://develop.openfoam.com/Development/openfoam/-/issues/2584'value' entry in bc not consistent in fvPatchField vs pointPatchField2022-09-24T09:22:30ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.com'value' entry in bc not consistent in fvPatchField vs pointPatchField### Functionality to add/problem to solve
There is inconsistency between pointPatchField, fvPatchField:
pointPatchField : use 'value' field if it is there. Look at valueRequired only if it isn't there.
fvPatchField : use 'value' field ...### Functionality to add/problem to solve
There is inconsistency between pointPatchField, fvPatchField:
pointPatchField : use 'value' field if it is there. Look at valueRequired only if it isn't there.
fvPatchField : use 'value' field only if valueRequired flag sethttps://develop.openfoam.com/Development/openfoam/-/issues/2583viewFactorsGen S2S radiation can cause divide by zero2024-01-05T16:47:48ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comviewFactorsGen S2S radiation can cause divide by zero<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be re...<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be rendered on the platform by using the
"preview" tab above
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
<!-- Summarize the bug encountered concisely -->
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
### Example case
<!--
If possible, please create a SMALL example and attach it to your report
If you are using an older version of OpenFOAM this will also determine
whether the bug has been fixed in a more recent version
-->
### What is the current *bug* behaviour?
<!-- What actually happens -->
### What is the expected *correct* behavior?
<!-- What you should see instead -->
### Relevant logs and/or images
<!--
Paste any relevant logs - please use code blocks (```) to format console
output, logs, and code as it's very hard to read otherwise.
-->
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v2206|v2112|v2106|v2012|v2006 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2212
- Operating system :
- Hardware info :
- Compiler :
### Possible fixes
<!--
If you can, link to the line of code that might be responsible for the
problem
The "/label ~bug" text is a gitlab flag that will add the "bug" label to this
issue
-->https://develop.openfoam.com/Development/openfoam/-/issues/2582Parallel run in Ubuntu 22.042024-01-10T10:45:27Zcarlo fiorinaParallel run in Ubuntu 22.04We seem to have problems running applications in parallel in Ubuntu 22.04.
For instance, the motorBike tutorial displays the following error:
--> FOAM FATAL ERROR: (openfoam-2112 patch=220610)
attempt to run parallel on 1 processor
...We seem to have problems running applications in parallel in Ubuntu 22.04.
For instance, the motorBike tutorial displays the following error:
--> FOAM FATAL ERROR: (openfoam-2112 patch=220610)
attempt to run parallel on 1 processor
From static bool Foam::UPstream::init(int&, char**&, bool)
in file UPstream.C at line 297.
FOAM abortinghttps://develop.openfoam.com/Development/openfoam/-/issues/2581Wrong CdRe in sphereDragForce.C2022-11-16T14:21:34ZMaximWrong CdRe in sphereDragForce.CHello,
While investigating the particleFoam algorithm I notice a possible mistake.
The calculation of CdRe in sphereDragForce.C reads:
"
if (Re > 1000.0)
{
return 0.424*Re;
}
else
{
return 24.0*(1.0 + 1.0/6.0*pow(Re, 2.0/3.0));...Hello,
While investigating the particleFoam algorithm I notice a possible mistake.
The calculation of CdRe in sphereDragForce.C reads:
"
if (Re > 1000.0)
{
return 0.424*Re;
}
else
{
return 24.0*(1.0 + 1.0/6.0*pow(Re, 2.0/3.0));
}
"
But according to the paper:
Liu, A.B., Mather, D., and Reitz, R.D. 1993. “Modeling the Effects of Drop Drag and Breakup on Fuel Sprays”, SAE Paper 930072.
it should be:
if (Re > 1000.0)
{
return 0.424;
}
else
{
return 24.0/Re*(1.0 + 1.0/6.0*pow(Re, 2.0/3.0));
}
Greetings,
Maxim V.C.https://develop.openfoam.com/Development/openfoam/-/issues/2580tetDecomposer produces incorrect tet2023-05-30T18:47:07ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comtetDecomposer produces incorrect tet<!--
*** 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 -->
Using the tetDecomposer class to decompose a mesh with refinement produces illegal mesh.
### 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
-->
[cavity.tgz](/uploads/5f3e1d0e0da22f5daa166d4606495e7a/cavity.tgz)
- blockMesh
- topoSet
- refineHexMesh
- split cells into tets
### What is the current *bug* behaviour?
<!-- What actually happens -->
Produces illegal mesh. checkMesh -alllTopology reports open cells.
### 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 : v2206|v2112|v2106|v2012|v2006 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2206
- Operating system :
- Hardware info :
- Compiler :
### Possible fixes
<!--
If you can, link to the line of code that might be responsible for the
problem
The "/label ~bug" text is a gitlab flag that will add the "bug" label to this
issue
-->https://develop.openfoam.com/Development/openfoam/-/issues/2579possible regression in noise utility2022-09-09T10:14:37ZMark OLESENpossible regression in noise utilityReported by @Prashant - appears to block when reading the ensight surfaces.
Perhaps related to changes from #2535 or #2532. Possible suspect may be handling of `undef` value.Reported by @Prashant - appears to block when reading the ensight surfaces.
Perhaps related to changes from #2535 or #2532. Possible suspect may be handling of `undef` value.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2578Bug in wave absorption for interFoam2022-11-03T09:20:53ZBrecht DevolderBug in wave absorption for interFoam### Summary
There seems to be a bug in the active wave absorption at the wave generation patch in interFoam.
### Steps to reproduce
Modify one of the waves tutorials (I tested with Cnoidal) to a shorter domain (to speed up the simulat...### Summary
There seems to be a bug in the active wave absorption at the wave generation patch in interFoam.
### Steps to reproduce
Modify one of the waves tutorials (I tested with Cnoidal) to a shorter domain (to speed up the simulation) and a fully reflective outlet (wall) to have large reflected waves propagating back to the inlet.
./0.orig/U:
outlet
{
type fixedValue;
value uniform (0 0 0);
}
./system/blockMeshDict
vertices
(
( 0.0 0.0 0.0)
( 3.0 0.0 0.0)
( 3.0 0.04 0.0)
( 0.0 0.04 0.0)
( 0.0 0.0 0.7)
( 3.0 0.0 0.7)
( 3.0 0.04 0.7)
( 0.0 0.04 0.7)
);
blocks
(
hex (0 1 2 3 4 5 6 7) (75 1 70) simpleGrading (1 1 1)
);
Run the case and it will crash at 11.2949 s due to large velocities and volume fractions larger than 1.
### What is the current *bug* behaviour?
The reflected wave is not fully absorbed at the wave generation patch when the activeLevel[paddlei] is higher than the calculatedLevel[paddlei] (positive reflected wave). There seems to be an incompatibility in volume fraction between the values on the inlet patch and the values in the first rows of cells next to it. You can clearly see this at t = 10.989 s (use [layout001.pvsm](/uploads/22baf835bb98135e1bd9290367182cc6/layout001.pvsm) in which the inlet patch values are shown next to the internal field values of the volume fraction)
### What is the expected *correct* behavior?
The volume fraction (alpha.water) must be set to 1 (or zero gradient) in between the activeLevel[paddlei] and the calculatedLevel[paddlei] instead of 0. Then you have a volume fraction equal to 1 between the bottom of the domain and the activeLevel[paddlei].
This makes sense as the correction velocity UCorr is also set between the bottom of the domain and the activeLevel[paddlei], see $FOAM_SRC/waveModels/waveModel/waveModel.C (line 379-400)
https://develop.openfoam.com/Development/openfoam/-/blob/master/src/waveModels/waveModel/waveModel.C#L379
```c
if (activeAbsorption_)
{
const scalarField activeLevel(this->waterLevel());
forAll(U_, facei)
{
const label paddlei = faceToPaddle_[facei];
if (zMin_[facei] - zMin0_ < activeLevel[paddlei])
{
scalar UCorr =
(calculatedLevel[paddlei] - activeLevel[paddlei])
*sqrt(mag(g_)/activeLevel[paddlei]);
U_[facei].x() += UCorr;
}
else
{
U_[facei].x() = 0;
}
}
}
```
This has also been published in https://doi.org/10.1016/j.coastaleng.2012.07.002 [Higuera__Lara__Losada_-_2013_-_Realistic_wave_generation_and_active_wave_absorption_for_Navier-Stokes_models._Application_to_OpenFOAM.pdf](/uploads/925290803fa6d6c3f5f696e02a2a4f52/Higuera__Lara__Losada_-_2013_-_Realistic_wave_generation_and_active_wave_absorption_for_Navier-Stokes_models._Application_to_OpenFOAM.pdf)
### Environment information
OpenFOAM-v2206
### Possible fixes
Change the boundary condition for the volume fraction between the activeLevel[paddlei] and the calculatedLevel[paddlei].Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2577maxIter with PPCR,PPCG not working in parallel2022-09-07T14:33:08ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.commaxIter with PPCR,PPCG not working in parallel<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be 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 -->
Sometimes using coarsest level inside GAMG with PPCR or PPCG in combination with maxIter gives a crash. Issue seems to be the combination of
- maxIter
- parallel running
- PPCR,PPCG (i.e. any linear solver using non-blocking reductions)
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Set up pressure solver to use PPCR or PPCG. Set maxIter to a very low level, e.g. 1. Run parallel.
### 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?
Crashes with `stack-smashing' error on some machines.
<!-- 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 : v2206|v2112|v2106|v2012|v2006 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : any version with PPCR,PPCG
### 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
-->
Make sure to clean up outstanding non-blocking request before exiting the solver loop inside PPCR,PPCG. This happens for 'normal' exits (convergence reached) but not for `maxIter` exits.Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/2576forceCoeffs << operator defined in incorrect namespace2022-09-07T14:33:08ZMark OLESENforceCoeffs << operator defined in incorrect namespaceCompilation error reported in https://github.com/mathLab/ITHACA-FV/issues/505#issuecomment-1238279763
It looks to me that forceCoeffs.H should have this instead:
```
} // End namespace functionObjects
// * * * * * * * * * * * * * * * *...Compilation error reported in https://github.com/mathLab/ITHACA-FV/issues/505#issuecomment-1238279763
It looks to me that forceCoeffs.H should have this instead:
```
} // End namespace functionObjects
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
Ostream& operator<<(Ostream& os, const functionObjects::forceCoeffs::coeffDesc& coeff)
{
os << coeff.desc_.c_str() << ": " << coeff.name_;
return os;
}
} // End namespace Foam
```
Otherwise it will define `Foam::functionObjects::operator<<` instead of `Foam::operator<<`
@andyhttps://develop.openfoam.com/Development/openfoam/-/issues/2575Inconsistency of function objects folder names with mesh regions2022-09-06T19:04:17ZRiccardo RossiInconsistency of function objects folder names with mesh regionsWHen using solver like the chtMultiRegionFoam some functions objects, such as surfaceFieldValue, are written to postProcessing/<regionName> whereas others, like sampling, are written directly into postProcessing even though they are only...WHen using solver like the chtMultiRegionFoam some functions objects, such as surfaceFieldValue, are written to postProcessing/<regionName> whereas others, like sampling, are written directly into postProcessing even though they are only applied to a particular region.https://develop.openfoam.com/Development/openfoam/-/issues/2574redistributePar fails with area fields when there are no edge boundaries2022-09-07T14:33:08ZMark OLESENredistributePar fails with area fields when there are no edge boundariesOdd failure reported on EP1371 (item 4) - caused by a programming oversight in redistributePar.
As the image below shows, it is quite possible to have a fully enclosed finiteArea patch without any physical boundary edges (only processor ...Odd failure reported on EP1371 (item 4) - caused by a programming oversight in redistributePar.
As the image below shows, it is quite possible to have a fully enclosed finiteArea patch without any physical boundary edges (only processor ones).
![Plates_p1](/uploads/56eb1879bad523afdf58fe58c1bdbbff/Plates_p1.png)
@kutiMark OLESENMark OLESEN