OpenFOAM-plus issueshttps://develop.openfoam.com/Development/OpenFOAM-plus/-/issues2019-04-12T21:27:06Zhttps://develop.openfoam.com/Development/OpenFOAM-plus/-/issues/1281fv::convectionScheme does not accept all schemes2019-04-12T21:27:06ZThorsten Zirwesfv::convectionScheme does not accept all schemesThe reacting solvers like the combustion solvers, Lagrangian solvers or heat transfer solvers use a fv::convectionScheme object for the convection term of species mass fraction and energy instead of fvm::div:
https://develop.openfoam.co...The reacting solvers like the combustion solvers, Lagrangian solvers or heat transfer solvers use a fv::convectionScheme object for the convection term of species mass fraction and energy instead of fvm::div:
https://develop.openfoam.com/search?utf8=%E2%9C%93&search=fv%3A%3AconvectionScheme&group_id=&project_id=5&search_code=true&repository_ref=develop#L1
This prevents the use of certain discretization schemes like "linear". For example, in the $FOAM_TUTORIALS/combustion/reactingFoam/laminar/counterFlowFlame2D case, replace
div(phi,Yi_h) Gauss limitedLinear 1;
with
div(phi,Yi_h) Gauss linear;
The error will read:
--> FOAM FATAL IO ERROR:
Unknown discretisation scheme linear
Valid schemes are :
12
(
Gamma
MUSCL
Minmod
SuperBee
limitedCubic
limitedLimitedLinear
limitedLinear
limitedLinear01
multivariateIndependent
multivariateSelection
upwind
vanLeer
)
Is this the intended behavior? Having the ability to choose schemes like "linear" or "cubic" might be advantageous for very fine meshes or DNS-like simulations.https://develop.openfoam.com/Development/OpenFOAM-plus/-/issues/1279fieldToCell does not use lookup; always reads from disk2019-04-11T08:34:11ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comfieldToCell does not use lookup; always reads from disk### Functionality to add/problem to solve
fieldToCell currently always reads from disk. Hence it cannot be used in e.g. a functionObject to select some cells during the run (). Would be nice if it would try lookup first instead.
### Pr...### Functionality to add/problem to solve
fieldToCell currently always reads from disk. Hence it cannot be used in e.g. a functionObject to select some cells during the run (). Would be nice if it would try lookup first instead.
### Proposal
- add database lookup first and loading from disk only if that fails
- move fieldToCell to finiteVolume and use proper fields
Example of desired use: plot all cells where the pressure is between 5 and 1000.
```
vtkWrite1
{
type vtkWrite;
libs ("libutilityFunctionObjects.so");
timeStart 10;
writeControl timeStep;
writeInterval 1;
format binary;
legacy false;
decompose false;
fields (p U);
selection
{
threshold
{
action use;
source fieldToCell;
field p;
min 5;
max 1000;
}
}
}
```
There is currently also a bug in that it searches for the last valid p,U instead of loading them from the current time (and failing).
https://develop.openfoam.com/Development/OpenFOAM-plus/-/issues/1275faceCorrected snGrad needs update on surface field orientation2019-04-08T22:41:21ZSergio FerrarisfaceCorrected snGrad needs update on surface field orientationfaceCorrected used in the laplacian lacks oriented flag for +=faceCorrected used in the laplacian lacks oriented flag for +=https://develop.openfoam.com/Development/OpenFOAM-plus/-/issues/1272adjustTimeStep/writeInterval conflict2019-08-28T12:48:22ZRiccardo RossiadjustTimeStep/writeInterval conflictI'm running a very simple test case using interPhaseChangeFoam and found out that monitors written every writeInterval based on adjustableRunTime conflict with the adjustTimeStep option.
For example, if monitors are not used and a max C...I'm running a very simple test case using interPhaseChangeFoam and found out that monitors written every writeInterval based on adjustableRunTime conflict with the adjustTimeStep option.
For example, if monitors are not used and a max Courant of 0.5 is specified, the solver runs fine with a time step size of the order of 1e-4 after an initial transient regime from the specified time step size of 1e-6.
If monitors are activated with a writeInterval of 1e-3, the case runs initially fine but then the time step size drops suddenly to 1e-28.Prashant SonakarPrashant Sonakarhttps://develop.openfoam.com/Development/OpenFOAM-plus/-/issues/1264Memory leak2019-04-17T13:59:54ZMohamed AhmedMemory leaksuspecting a memory leak in openfoam-dev when compiled on a cluster using gcc 4.9.3 and openmpi 1.8.6
```
==39345== LEAK SUMMARY:
==39345== definitely lost: 0 bytes in 0 blocks
==39345== indirectly lost: 0 bytes in 0 blocks
==39345...suspecting a memory leak in openfoam-dev when compiled on a cluster using gcc 4.9.3 and openmpi 1.8.6
```
==39345== LEAK SUMMARY:
==39345== definitely lost: 0 bytes in 0 blocks
==39345== indirectly lost: 0 bytes in 0 blocks
==39345== possibly lost: 538 bytes in 12 blocks
==39345== still reachable: 2,056 bytes in 3 blocks
==39345== suppressed: 0 bytes in 0 blocks
==39345== Reachable blocks (those to which a pointer was found) are not shown.
==39345== To see them, rerun with: --leak-check=full --show-reachable=yes
==39345==
==39345== For counts of detected and suppressed errors, rerun with: -v
==39345== ERROR SUMMARY: 12 errors from 12 contexts (suppressed: 8 from 6)
```https://develop.openfoam.com/Development/OpenFOAM-plus/-/issues/1259Discrepancy in results - Running with "laminar" turbulence model, and running...2019-04-01T10:22:41ZPhilippose RajanDiscrepancy in results - Running with "laminar" turbulence model, and running with RAS + "turbulence off"<!--
*** 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
-->
<!--
All text between these marker...<!--
*** 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
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
Results obtained by running a simulation using the turbulence model **laminar** does not match with results obtained by running with the option **RAS** coupled with **turbulence off**
### Steps to reproduce
Run the simulation case attached with:
* Allrun.lam
* Allrun.turbOff
This can be generalized to running any incompressible (tested only for incompressible cases) first with **laminar** and compare with results obtained by running with **RAS** and **turbulence off**
### Example case
[002_turbOff_Laminar_Discrepancy.tar.gz](/uploads/8902a95221088d0abf756ce80c90075b/002_turbOff_Laminar_Discrepancy.tar.gz)
### What is the current *bug* behaviour?
The result obtained by running the case with **laminar** is different from the result obtained by running the case with **RAS** + **turbulence off**
### What is the expected *correct* behavior?
The results obtained from both configurations should be the same.
### Relevant logs and/or images
-NA-
### 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 : 1812
Operating system : CentOS 7
Compiler : GCC 4.8.5
### Possible fixes
The problem comes from the initialization of the **nut** field.
When the case is run using **laminar**, the viscosity is taken from the transport properties. However, when the case is run using **RAS** with **turbulence off**, the **nut** field is initialised using the initial values of **k** and **omega** / **epsilon**, but not updated anymore during the simulation.
This results in a different effective viscosity being used for cases run with **turbulence off**.
Is this something intentional? Was the switch **turbulence on/off** implemented with some other intention in mind other than to give a simple method to switch between **laminar** and **turbulent** simulations?Matej FormanMatej Formanhttps://develop.openfoam.com/Development/OpenFOAM-plus/-/issues/1257Error in compiling solver in OpenFOAM-v1806 on windows2019-03-29T04:12:19ZDela QuarmeError in compiling solver in OpenFOAM-v1806 on windowsDear all,
I have tried to compile a solver on a newly installed OpenFOAM-v1806 on windows without success. I have installed make, build-essentials, all to no avail. This happened on two different computers. As a test case, I decided to r...Dear all,
I have tried to compile a solver on a newly installed OpenFOAM-v1806 on windows without success. I have installed make, build-essentials, all to no avail. This happened on two different computers. As a test case, I decided to recompile the original reactingTwoPhaseEulerFoam without modifying it but alwyas gets the error below:
g++ -std=c++11 -m64 -DOPENFOAM=1806 -Dlinux64 -DWM_ARCH_OPTION=64 -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 -ItwoPhaseSystem/lnInclude -I../phaseSystems/lnInclude -I../interfacialModels/lnInclude -I../interfacialCompositionModels/lnInclude -ItwoPhaseCompressibleTurbulenceModels/lnInclude -I/opt/OpenFOAM/OpenFOAM-v1806/src/thermophysicalModels/basic/lnInclude -I/opt/OpenFOAM/OpenFOAM-v1806/src/transportModels/compressible/lnInclude -I/opt/OpenFOAM/OpenFOAM-v1806/src/TurbulenceModels/turbulenceModels/lnInclude -I/opt/OpenFOAM/OpenFOAM-v1806/src/TurbulenceModels/compressible/lnInclude -I/opt/OpenFOAM/OpenFOAM-v1806/src/TurbulenceModels/phaseCompressible/lnInclude -I/opt/OpenFOAM/OpenFOAM-v1806/src/finiteVolume/lnInclude -I/opt/OpenFOAM/OpenFOAM-v1806/src/meshTools/lnInclude -I/opt/OpenFOAM/OpenFOAM-v1806/src/sampling/lnInclude -IlnInclude -I. -I/opt/OpenFOAM/OpenFOAM-v1806/src/OpenFOAM/lnInclude -I/opt/OpenFOAM/OpenFOAM-v1806/src/OSspecific/POSIX/lnInclude -fPIC -c reactingTwoPhaseEulerFoam.C -o /opt/OpenFOAM/OpenFOAM-v1806/build/linux64Gcc63DPInt32Opt/applications/solvers/multiphase/reactingEulerFoam/reactingTwoPhaseEulerFoam/reactingTwoPhaseEulerFoam.o
In file included from /opt/OpenFOAM/OpenFOAM-v1806/src/OpenFOAM/lnInclude/scalar.H:39:0,
from /opt/OpenFOAM/OpenFOAM-v1806/src/OpenFOAM/lnInclude/IOstream.H:49,
from /opt/OpenFOAM/OpenFOAM-v1806/src/OpenFOAM/lnInclude/Ostream.H:39,
from /opt/OpenFOAM/OpenFOAM-v1806/src/OpenFOAM/lnInclude/OSstream.H:39,
from /opt/OpenFOAM/OpenFOAM-v1806/src/OpenFOAM/lnInclude/messageStream.H:244,
from /opt/OpenFOAM/OpenFOAM-v1806/src/OpenFOAM/lnInclude/error.H:51,
from /opt/OpenFOAM/OpenFOAM-v1806/src/OpenFOAM/lnInclude/UListI.H:26,
from /opt/OpenFOAM/OpenFOAM-v1806/src/OpenFOAM/lnInclude/UList.H:532,
from /opt/OpenFOAM/OpenFOAM-v1806/src/OpenFOAM/lnInclude/List.H:43,
from /opt/OpenFOAM/OpenFOAM-v1806/src/OpenFOAM/lnInclude/labelList.H:60,
from /opt/OpenFOAM/OpenFOAM-v1806/src/OpenFOAM/lnInclude/UPstream.H:42,
from /opt/OpenFOAM/OpenFOAM-v1806/src/OpenFOAM/lnInclude/Pstream.H:42,
from /opt/OpenFOAM/OpenFOAM-v1806/src/OpenFOAM/lnInclude/parRun.H:38,
from /opt/OpenFOAM/OpenFOAM-v1806/src/finiteVolume/lnInclude/fvCFD.H:4,
from reactingTwoPhaseEulerFoam.C:39:
**/opt/OpenFOAM/OpenFOAM-v1806/src/OpenFOAM/lnInclude/floatScalar.H:54:1: internal compiler error: Illegal instruction
constexpr floatScalar floatScalarGREAT = 1.0e+6;**
^~~~~~~~~
0xac5ddf crash_signal
/home/pgh/OpenFOAM/ThirdParty-1706/gcc-6.3.0/gcc/toplev.c:333
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
/opt/OpenFOAM/OpenFOAM-v1806/wmake/rules/General/transform:34: recipe for target '/opt/OpenFOAM/OpenFOAM-v1806/build/linux64Gcc63DPInt32Opt/applications/solvers/multiphase/reactingEulerFoam/reactingTwoPhaseEulerFoam/reactingTwoPhaseEulerFoam.o' failed
make: *** [/opt/OpenFOAM/OpenFOAM-v1806/build/linux64Gcc63DPInt32Opt/applications/solvers/multiphase/reactingEulerFoam/reactingTwoPhaseEulerFoam/reactingTwoPhaseEulerFoam.o] Error 1https://develop.openfoam.com/Development/OpenFOAM-plus/-/issues/1255snappyHexMesh with sloppy patch following2019-03-27T16:18:23ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comsnappyHexMesh with sloppy patch following### Functionality to add/problem to solve
snappyHexMesh will try to merge co-planar faces on a single cell into a single, large face. This minimises the individual distortion and generates more layers. It will not merge faces belonging ...### Functionality to add/problem to solve
snappyHexMesh will try to merge co-planar faces on a single cell into a single, large face. This minimises the individual distortion and generates more layers. It will not merge faces belonging to different patches. Occasionally it would be nice to merge across patches (saving the effort of merging the regions in the surface)Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/OpenFOAM-plus/-/issues/1253missing -dict on some utilities2019-03-27T10:40:41ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.commissing -dict on some utilities### Functionality to add/problem to solve
Some utilities are still missing the -dict option to specify an alternative location.
E.g. extrudeMesh.### Functionality to add/problem to solve
Some utilities are still missing the -dict option to specify an alternative location.
E.g. extrudeMesh.Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/OpenFOAM-plus/-/issues/1239paraFoam needs 0/ directory2019-03-14T14:32:54ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comparaFoam needs 0/ directory### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
lid driven cavity
mv 0 0.orig
ln -s 0.001 0.orig
paraFoam now complains about no mesh.### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
lid driven cavity
mv 0 0.orig
ln -s 0.001 0.orig
paraFoam now complains about no mesh.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/OpenFOAM-plus/-/issues/1236Gauss CoBlended scheme fails for div(phi,alpha) in interFoam2019-03-13T16:11:28ZLydia SchulzeGauss CoBlended scheme fails for div(phi,alpha) in interFoam<!--
*** 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
-->
<!--
All text between these marker...<!--
*** 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
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
<!-- Summarize the bug encountered concisely -->
When using the scheme Gauss CoBlended for the term div(phi,alpha) in the solver interFoam, the simulation breaks up with the following error message:
fvSchemes:
<pre>div(phi,alpha) Gauss CoBlended 1. Minmod 2. upwind;</pre>
logfile output:
<pre>--> FOAM FATAL ERROR:
Operator + is undefined for unoriented and oriented types
From function Foam::orientedType Foam::operator+(const Foam::orientedType&, const Foam::orientedType&)
in file orientedType/orientedType.C at line 458.</pre>
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Use tutorial /multiphase/RAS/interFoam/damBreak.
Change in fvSchemes:
<pre>div(phi,alpha) Gauss CoBlended 1. Minmod 2. upwind;</pre>
Run the case with Allrun.
### 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
-->
The damBreak tutorial (tutorials/multiphase/RAS/damBreak)
### What is the current *bug* behaviour?
<!-- What actually happens -->
Run fails in first alpha-Subcycle. Logfile output:
<pre> Courant Number mean: 0 max: 0
Interface Courant Number mean: 0 max: 0
deltaT = 0.00119048
Time = 0.00119048
PIMPLE: iteration 1
smoothSolver: Solving for alpha.water, Initial residual = 0, Final residual = 0, No Iterations 0
Phase-1 volume fraction = 0.130194 Min(alpha.water) = 0 Max(alpha.water) = 1
--> FOAM FATAL ERROR:
Operator + is undefined for unoriented and oriented types
From function Foam::orientedType Foam::operator+(const Foam::orientedType&, const Foam::orientedType&)
in file orientedType/orientedType.C at line 458.</pre>
### What is the expected *correct* behavior?
<!-- What you should see instead -->
Normal interFoam-running would be expected.
### 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 :v1812
Operating system :centos
Compiler :gcc
### Possible fixes
<!--
If you can, link to the line of code that might be responsible for the
problem
-->https://develop.openfoam.com/Development/OpenFOAM-plus/-/issues/1233moveDynamicMesh with -overwrite2019-03-14T12:45:39ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.commoveDynamicMesh with -overwrite### Functionality to add/problem to solve
(Brief scope)
moveDynamicMesh can be used to modify the initial mesh (i.e. as a meshing tool). An option to enforce the points being written to the constant/ directory might be nice.
Attached ...### Functionality to add/problem to solve
(Brief scope)
moveDynamicMesh can be used to modify the initial mesh (i.e. as a meshing tool). An option to enforce the points being written to the constant/ directory might be nice.
Attached is a version that has the -overwrite. Not sure whether it should run to completion or only one timestep (which is useful since now timeValue stays at 0)
[moveDynamicMesh.C](/uploads/fbdffbde320ce6dd99b9d83c55cf4a6e/moveDynamicMesh.C)Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/OpenFOAM-plus/-/issues/1228old time field being read in postprocessing2019-03-06T11:51:22ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comold time field being read in postprocessing<!--
*** 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
-->
<!--
All text between these marker...<!--
*** 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
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
<!-- Summarize the bug encountered concisely -->
During post processing it reads the contents of the directory e.g. as volFields. There is no need to automatically read the old-time field as well. This is just an efficiency issue.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Use e.g. setFields. Copy a field to make an old-time one: ```cp zoneID zoneID_0```
Switch on debug flag for ```volScalarField``` and run ```setFields``` with relevant ```setFieldsDict```. It shows loading the old-time field.Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/OpenFOAM-plus/-/issues/1227ENH: Inform users that the functionObject in question is disabled when it thr...2019-03-06T10:08:56ZKutalmış BerçinENH: Inform users that the functionObject in question is disabled when it throws FatalErrorInFunction-type warnings### Functionality to add/problem to solve
I initialised a variable in the constructor of a (developing) functionObject via a function call which involves a check with `FatalErrorInFunction`:
```
bool Foam::functionObjects::myFunctionOb...### Functionality to add/problem to solve
I initialised a variable in the constructor of a (developing) functionObject via a function call which involves a check with `FatalErrorInFunction`:
```
bool Foam::functionObjects::myFunctionObject::isTemporalVariant
(
const bool runTimeModifiable
) const
{
if (runTimeModifiable)
{
FatalErrorInFunction
<< "Available only for fixed time-step computations."
<< exit(FatalError);
}
return false;
}
```
```
//... Member initialiser list in the constructor
isTemporalVariant_(isTemporalVariant(runTime.runTimeModifiable())),
//...
```
`FatalErrorInFunction` is called when the user sets `controlDict\runTimeModifiable true`.
`FatalErrorInFunction` throws `FOAM Warning` instead of `FOAM FATAL ERROR`.
```
-> FOAM Warning :
Available only for fixed time-step computations.
From function bool Foam::functionObjects::myFunctionObject::isTemporalVariant(bool) const
in file streamingTotalDMD.C at line 53.
From function bool Foam::functionObjectList::read()
in file db/functionObjects/functionObjectList/functionObjectList.C at line 896
--> while loading function object 'myFunctionObject1'
```
Yet, IMHO, the user was not informed that the functionObject is disabled, and the computation is let to run.
### Target audience
Users of functionObjects.
### Proposal
Append information stating that the relevant functionObject is disabled, and the remaining functionObjects and the computation itself are allowed to continue their run.
### What does success look like, and how can we measure that?
N/A
### Links / references
N/A
### Funding
N/Ahttps://develop.openfoam.com/Development/OpenFOAM-plus/-/issues/1223potentialFoam with -region option2019-02-28T17:05:32ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.compotentialFoam with -region option### Functionality to add/problem to solve
(Brief scope)
Option to run potentialFoam with -region
### Target audience
(Who will benefit from the changes?)
(What type of cases?)
### Proposal
(How are we going to solve the problem?)...### Functionality to add/problem to solve
(Brief scope)
Option to run potentialFoam with -region
### Target audience
(Who will benefit from the changes?)
(What type of cases?)
### Proposal
(How are we going to solve the problem?)
Add handling of region name as command line argument. Feed through the -dry-run mesh handling.
### What does success look like, and how can we measure that?
(What are the success factors and acceptance criteria? e.g. test cases, error margins)
### Links / references
(Links to literature, supporting information)
### Funding
(Does the functionality already exist/is sponsorship available?)Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/OpenFOAM-plus/-/issues/1222solver doesn't creates the PIMPLE class2019-03-01T10:15:29ZKorbinian Faustsolver doesn't creates the PIMPLE class<!--
*** 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
-->
<!--
All text between these marker...<!--
*** 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
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
<!-- Summarize the bug encountered concisely -->
When trying to use the PIMPLE-mode with chtMultiRegionFoam the solver always runs all of the outerCorrector loops without reading the residual control. It looks like the solver doesn't create the PIMPLE-class properly. (See log-file)
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Starting of chtMultiRegionFoam in PIMPLE mode with residual control for different regions.
### Example case
<!--
If possible, please create a SMALL example and attach it to your report
If you are using an older version of OpenFOAM this will also determine
whether the bug has been fixed in a more recent version
-->
See attached: [Bug_report.zip](/uploads/b19da936c69be8f62a9a66b022d872b1/Bug_report.zip)
### What is the current *bug* behaviour?
<!-- What actually happens -->
Solver Runs all outerCorrector loops even if all given residual controls are fulfilled.
### What is the expected *correct* behavior?
<!-- What you should see instead -->
Solver should leave outerCorrector loop as soon as all given residuals are fulilled.
### 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.
-->
Log (Doesn't show anything about PIMPLE-loop): [log.chtMultiRegionFoam](/uploads/d32165edce48ecd9b65fbb915ce1e802/log.chtMultiRegionFoam)
### 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 : v1812
Operating system : ubuntu
Compiler :
### Possible fixes
<!--
If you can, link to the line of code that might be responsible for the
problem
-->
Problem discussed in: https://www.cfd-online.com/Forums/openfoam-solving/215261-outercorrectorresidualcontrol-openfoam-v1812-vs-openfoam-6-a.html#post726390https://develop.openfoam.com/Development/OpenFOAM-plus/-/issues/1221snappyHexMesh with empty regions in surfaces2019-02-28T15:20:19ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comsnappyHexMesh with empty regions in surfaces<!--
*** 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
-->
<!--
All text between these marker...<!--
*** 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
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
<!-- Summarize the bug encountered concisely -->
shm can potentially snap to a particular region. This is done by constructing a per-region search tree (triSurfaceRegionSearch). triSurfaceRegionSearch fails if there are some zero-sized regions.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Have surfaces with zero-sized regions. Run with
```snapControls:multiRegionFeatureSnap true```
### 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 -->
out-of-bounds access in Map<label>
### 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 :
Operating system :
Compiler :
### Possible fixes
<!--
If you can, link to the line of code that might be responsible for the
problem
-->Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/OpenFOAM-plus/-/issues/1219writeDictionary FO only prints after first iteration2019-02-27T13:24:02ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comwriteDictionary FO only prints after first iterationIt should print before the first iteration.It should print before the first iteration.https://develop.openfoam.com/Development/OpenFOAM-plus/-/issues/1218Missing information in the section for RPM installation2019-03-04T23:00:42ZBruno SantosMissing information in the section for RPM installationIn this page: https://www.openfoam.com/download/install-binary-linux.php - in the very first section "RPM Installation", it's missing the instructions on how to activate the OpenFOAM-v1812 shell environment...
I only spotted this becaus...In this page: https://www.openfoam.com/download/install-binary-linux.php - in the very first section "RPM Installation", it's missing the instructions on how to activate the OpenFOAM-v1812 shell environment...
I only spotted this because of this post: https://www.cfd-online.com/Forums/openfoam-installation/215231-rpm-installation-openfoam-v1812-opensuse-15-0-a.html#post726007https://develop.openfoam.com/Development/OpenFOAM-plus/-/issues/1216Improvements for PDRFoam (solver and utilities)2019-11-03T10:55:28ZMark OLESENImprovements for PDRFoam (solver and utilities)@Sergio @pratap@Sergio @pratapMark OLESENMark OLESEN