Development issueshttps://develop.openfoam.com/groups/Development/-/issues2021-10-27T11:38:37Zhttps://develop.openfoam.com/Development/openfoam/-/issues/2244foamDebugSwitches script is still mentioned in programmer's guide2021-10-27T11:38:37Zs1291foamDebugSwitches script is still mentioned in programmer's guideHi,
In OpenFOAM Programmer's guide (Page 21), the foamDebugSwitches script is still there.
![image](/uploads/03f9c0483f16328a90fa46d87dd1735d/image.png)
RegardsHi,
In OpenFOAM Programmer's guide (Page 21), the foamDebugSwitches script is still there.
![image](/uploads/03f9c0483f16328a90fa46d87dd1735d/image.png)
Regardshttps://develop.openfoam.com/Development/openfoam/-/issues/2241Cannot create valid tet decomposition for wegde mesh2021-10-26T15:18:53ZJan GärtnerCannot create valid tet decomposition for wegde mesh### Summary
A wedge mesh generated with blockMesh in OpenFOAM v2012 cannot be decomposed into tets with `polyMeshTetDecomposition::cellTetIndices()` and the `tetIndices::faceTriIs()` function.
A possible reason might be that four poin...### Summary
A wedge mesh generated with blockMesh in OpenFOAM v2012 cannot be decomposed into tets with `polyMeshTetDecomposition::cellTetIndices()` and the `tetIndices::faceTriIs()` function.
A possible reason might be that four points of the tet face are reported, e.g. for the sketch below it writes face (A B C A)
```c++
// A general wege
C
+
/|
/ |
/ 1|
+---+ B
^
A
```
If the mesh is generated with blockMesh of OpenFOAM 5.x the error does not occur. Note, only the mesh is generated with 5.x decomposition into tets is then done with v2012.
### Steps to reproduce
* Generate a wedge domain with blockMesh
* Use cellTetIndices to get the tets for all cells and try to find the `faceTriIs`. An example `main()` function could be:
```c++
int main()
{
#include "setRootCase.H"
#include "createTime.H"
#include "createMesh.H"
forAll(mesh,cellI)
{
List<tetIndices> cellTets =
polyMeshTetDecomposition::cellTetIndices(mesh, cellI);
triFaceList triFaces(cellTets.size());
forAll(cellTets, cTI)
{
triFaces[cTI] = cellTets[cTI].faceTriIs(mesh);
}
}
return 0;
};
```
* This will return the warning:
> --> FOAM Warning :
> From Foam::triFace Foam::tetIndices::faceTriIs(const Foam::polyMesh&, bool) const
> in file <FILEPATH>
> No base point for face 1620, 4(0 1 442 441), produces a valid tet decomposition.
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v1806|v1812|v1906|v1912|v2006|v2012|v2106 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2012
- Operating system : ubuntu 18.04 LTS
- Hardware info : amd ryzen 7
- Compiler : g++ 7.5.0Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2240FPE handling for OSX arm642024-01-11T15:06:56ZMark OLESENFPE handling for OSX arm64Mentioned in cfd-online and refers to this gitrepo :
https://github.com/ttsyshmz/howtoFoam/blob/main/codes/feexceptErsatz-v2106/feexceptErsatz.HMentioned in cfd-online and refers to this gitrepo :
https://github.com/ttsyshmz/howtoFoam/blob/main/codes/feexceptErsatz-v2106/feexceptErsatz.Hv2306Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2238Feature: harmonic interpolation of zero values2022-02-20T23:38:31ZBas NieuwboerFeature: harmonic interpolation of zero values### Functionality to add/problem to solve
OpenFOAM offers an harmonic interpolation scheme which is suitable for interpolating across steep gradients. It is for instance very suitable for interpolating the concentration and (mixture) vis...### Functionality to add/problem to solve
OpenFOAM offers an harmonic interpolation scheme which is suitable for interpolating across steep gradients. It is for instance very suitable for interpolating the concentration and (mixture) viscosity in a bed transport using a sand-water mixture. Such an interpolation limits the diffusion due to the linear interpolation across the interface.
### Proposal
Currently, the interpolation scheme cannot handle zero values of the interpolated property. As can be viewed in this equation:
```math
\varphi_f = \frac{1}{\frac{\delta_1 / \delta}{\varphi_2} + \frac{\delta_2 / \delta}{\varphi_1}}
```
The dissertation of Goeree (2018) [1] describes a form in which it is possible to handle these zero values (5.22 and 5.17).
```math
\varphi_f = \frac{\varphi_1 \, \varphi_2}{\frac{\delta_1}{\delta} \,\varphi_1 + \frac{\delta_2}{ \delta} \, \varphi_2}
```
My knowledge on the interpolation schemes implementation is limited and I could not implement this scheme myself. Would it be possible to change the implementation of this scheme or add a second scheme, which uses the version described in Goeree [1]? With some pointers I could implement and test it myself.
I did found a work-around for the harmonic schemes to handle zero values by first using a linear interpolation. I’ve added the code for this scheme when implementing the different scheme is not possible.
[harmonic0.C](/uploads/b40eefb9a7787be845e65d0f3583bff9/harmonic0.C)
[harmonic0.H](/uploads/4c900e6800cfdb1afd8af42bb60d035e/harmonic0.H)
### Links / references
[1] https://repository.tudelft.nl/islandora/object/uuid%3A2d432d11-cce4-40de-b951-e89dfebbef27https://develop.openfoam.com/Development/openfoam/-/issues/2236Can't run decomposePar -fields after parallel snappyHexMesh due to lack of fa...2024-03-15T12:42:43ZRobin KnowlesCan't run decomposePar -fields after parallel snappyHexMesh due to lack of faceProcAddressing files<!--
*** 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
`decomposePar -fields` cannot be run _after_ parallel `snappyHexMesh` due to missing `faceProcAddressing` files.
### Steps to reproduce
- mesh the `motorbike` tutorial in parallel
- copy `0.orig` to `0`
- run `decomposePar -fields`
### What is the current *bug* behaviour?
`decomposePar -fields` fails with the error:
```
Processor 0: field transfer
--> FOAM FATAL ERROR: (openfoam-2106)
cannot find file "/home/openfoam/processor0/constant/polyMesh/faceProcAddressing"
From virtual Foam::autoPtr<Foam::ISstream> Foam::fileOperations::uncollatedFileOperation::readStream(Foam::regIOobject&, const Foam::fileName&, const Foam::word&, bool) const
in file global/fileOperations/uncollatedFileOperation/uncollatedFileOperation.C at line 542.
FOAM exiting
```
### What is the expected *correct* behavior?
`decomposePar -fields` should propagate the fields in the `0` (or any other specified time directory) to the existing processor directories, parsing any `include` directives, expressions &/or regex present in the boundary condition dictionaries.
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v1806|v1812|v1906|v1912|v2006|v2012|v2106 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2106
- Operating system : Ubuntu / Docker
- Hardware info : Mac
- Compiler : Pre-Compiled Binaries / Docker images
Related issue: #2235Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/2231reduce/improve library settings for paraview/vtk2021-10-07T06:51:41ZMark OLESENreduce/improve library settings for paraview/vtkMore recent paraview versions do not an explicit LD_LIBRARY_PATH to run so this setting can be removed from the config.sh/ entry.
Verified with a fresh ParaView build/install under /tmp/make-thirdparty. Used these locations when buildin...More recent paraview versions do not an explicit LD_LIBRARY_PATH to run so this setting can be removed from the config.sh/ entry.
Verified with a fresh ParaView build/install under /tmp/make-thirdparty. Used these locations when building the PV-Plugins (aka, paraFoam modules). Relocated ParaView to the usual ThirdParty/platforms locations. Plugins load correctly.
Will need an additional mechanism to specify `libpaths` for catalyst and runTimePostProcessing though.
[0001-CONFIG-newer-paraview-finds-its-own-libraries.patch](/uploads/86bae44b982821277e68fe24903f94c8/0001-CONFIG-newer-paraview-finds-its-own-libraries.patch)https://develop.openfoam.com/Development/openfoam/-/issues/2227pimpleFoam and pisoFoam deltaT not respecting controlDict value when running ...2021-11-02T10:13:48ZAaronpimpleFoam and pisoFoam deltaT not respecting controlDict value when running SPDP (but does for DP)### Summary
deltaT is not being respected by pimpleFoam and pisoFoam when in SPDP. This is for a deltaT of 7.5e-05, so not an issue of being too small for single precision. When solving in DP, deltaT is as expected.
### Steps to reprodu...### Summary
deltaT is not being respected by pimpleFoam and pisoFoam when in SPDP. This is for a deltaT of 7.5e-05, so not an issue of being too small for single precision. When solving in DP, deltaT is as expected.
### Steps to reproduce
Simply run pimpleFoam, both in SPDP and DP to see how DP respects the deltaT prescribed in controlDict, while SPDP generates a random value. The random value is not even very close to the controlDict deltaT (it's off by ~20%), and it varies with each iteration. This prevents endTime writing on the last iteration, makes results processing difficult, etc.
### Example case
https://www.dropbox.com/s/bmfxslcx7lj3wec/issue2227_deltaT_SPDP.tar.xz?dl=0
I have a solved (steady state) 500k cell case which is about ~50Mb. I can send it through another channel if you prefer.
### What is the current *bug* behaviour?
Random deltaT - differing from controlDict value by up to 20% - being applied to each iteration when running SPDP
### What is the expected *correct* behavior?
deltaT per controlDict, as is the case when running DP
### Relevant logs and/or images
controlDict
```
startFrom startTime;
**startTime 400;**
stopAt endTime;
endTime 400.20025;
**deltaT 7.5e-05;**
writeControl timeStep;
writeInterval 267;
monStart 400.1002;
purgeWrite 100;
writeFormat ascii;
writeCompression on;
writePrecision 7;
timeFormat general;
timePrecision 11;
runTimeModifiable yes;
```
DP - expected behavior
```
Build : f4ccdec894-20210902 OPENFOAM=2012 patch=210618
Arch : "LSB;label=32;scalar=64"
Starting time loop
Courant Number mean: 0.007378641 max: 2.702994
**Time = 400.000075**
PIMPLE: iteration 1
velocityDampingConstraint damp damped 3 (0.000564893%) of cells
smoothSolver: Solving for Ux, Initial residual = 4.640301e-07, Final residual = 1.441689e-08, No Iterations 1
smoothSolver: Solving for Uy, Initial residual = 4.99919e-05, Final residual = 5.043536e-08, No Iterations 3
smoothSolver: Solving for Uz, Initial residual = 6.165809e-06, Final residual = 1.953994e-08, No Iterations 2
GAMG: Solving for p, Initial residual = 0.3755113, Final residual = 0.02669367, No Iterations 1
GAMG: Solving for p, Initial residual = 0.02671251, Final residual = 0.001826018, No Iterations 3
time step continuity errors : sum local = 1.271702e-09, global = 1.048906e-11, cumulative = 1.048906e-11
GAMG: Solving for p, Initial residual = 0.01341298, Final residual = 0.000939755, No Iterations 2
GAMG: Solving for p, Initial residual = 0.001842091, Final residual = 9.379453e-07, No Iterations 28
time step continuity errors : sum local = 6.500214e-13, global = 2.663773e-17, cumulative = 1.048909e-11
smoothSolver: Solving for omega, Initial residual = 2.509855e-07, Final residual = 1.21354e-08, No Iterations 1
bounding omega, min: -5721.012 max: 283395.7 average: 3373.21
smoothSolver: Solving for k, Initial residual = 7.494289e-06, Final residual = 1.253224e-08, No Iterations 2
bounding k, min: -36.23042 max: 384.4423 average: 11.56855
ExecutionTime = 2.98 s ClockTime = 3 s
Courant Number mean: 0.007378645 max: 2.242397
**Time = 400.00015**
```
SPDP - strange time step which is different from DP and controlDict specification
```
Build : 4245909efb-20210203 OPENFOAM=2012
Arch : "LSB;label=32;scalar=32;solveScalar=64"
Starting time loop
Courant Number mean: 0.007378641 max: 2.703078
**Time = 400.00006104**
PIMPLE: iteration 1
velocityDampingConstraint damp damped 3 (0.000564893%) of cells
smoothSolver: Solving for Ux, Initial residual = 5.07782e-07, Final residual = 1.456293e-08, No Iterations 1
smoothSolver: Solving for Uy, Initial residual = 4.999212e-05, Final residual = 5.043533e-08, No Iterations 3
smoothSolver: Solving for Uz, Initial residual = 6.165838e-06, Final residual = 1.953989e-08, No Iterations 2
GAMG: Solving for p, Initial residual = 0.3754919, Final residual = 0.02666569, No Iterations 1
GAMG: Solving for p, Initial residual = 0.02669024, Final residual = 0.00183339, No Iterations 3
time step continuity errors : sum local = 1.534634e-09, global = 7.045955e-12, cumulative = 7.045955e-12
GAMG: Solving for p, Initial residual = 0.01344812, Final residual = 0.0009438513, No Iterations 2
GAMG: Solving for p, Initial residual = 0.001842122, Final residual = 9.032984e-07, No Iterations 29
time step continuity errors : sum local = 3.146365e-10, global = 1.095093e-12, cumulative = 8.141048e-12
smoothSolver: Solving for omega, Initial residual = 2.511907e-07, Final residual = 1.21357e-08, No Iterations 1
bounding omega, min: -5721.12 max: 283415 average: 3373.219
smoothSolver: Solving for k, Initial residual = 7.494291e-06, Final residual = 1.253221e-08, No Iterations 2
bounding k, min: -36.23087 max: 384.4427 average: 11.56855
ExecutionTime = 2.36 s ClockTime = 3 s
Courant Number mean: 0.007378645 max: 2.242493
**Time = 400.00012207**
```
### Environment information
- OpenFOAM version : v2012 & v2106
- Operating system : ubuntu1804
- Hardware info : x86
- Compiler : gcchttps://develop.openfoam.com/Development/openfoam/-/issues/2225chtMultiRegionSimpleFoam - frozenFlow mode results in large errors2021-12-06T20:45:03ZKumar KrishnachtMultiRegionSimpleFoam - frozenFlow mode results in large errorsRunning chtMultiRegionSimpleFoam on a converged flow by activating the frozenFlow switch to calculate the heat transport results in fairly large deviations in the final temperatures as opposed to running the case in the "normal" (fully c...Running chtMultiRegionSimpleFoam on a converged flow by activating the frozenFlow switch to calculate the heat transport results in fairly large deviations in the final temperatures as opposed to running the case in the "normal" (fully coupled) mode.
Attached is a 2D case to illustrate the problem. It is a simple case of water flowing at high velocity through a narrow channel above a copper plate which is heated from below.
To reproduce the problem, please do the following steps:
(1) Run the case as it is. The case runs in fully coupled mode for 2000 iterations.
(2) Run the case for the first 1000 iterations by turning off the (h|e) solvers in the ./system/copper/fvSolution and ./system/water/fvSolution subdirectories, i.e, please activate the 'maxIter 0' statement.
(3) Now please turn on the frozenFlow keyword in the PIMPLE subdict and run for another 1000 iterations. In this case, deactivate the 'maxIter 0' statement in the respective fvSolution dicts.
We can see that the Temp. results obtained at the end of 2000 iterations in both cases are very different.
[ConjCopperWater.tar.gz](/uploads/9bbe5fd5dedce1ef301d0f0f8c86b96a/ConjCopperWater.tar.gz)
**Environment Information**
- OpenFOAM Version: v2106
- Operating System: Windows 10 (MinGW)
- Hardware Info: PC (HP Z240)https://develop.openfoam.com/Development/openfoam/-/issues/2216interCondensatingEvaporatingFoam: interfaceHeatResistance model failing for c...2021-10-29T07:57:20ZMoritz MuthinterCondensatingEvaporatingFoam: interfaceHeatResistance model failing for condensation cases### Summary
I initialized a stefans problem case inside a rectangular domain with a small liquid film on the bottom wall and a vapour phase above the film. The film was set to a temperature 10K below the saturation temperature while the ...### Summary
I initialized a stefans problem case inside a rectangular domain with a small liquid film on the bottom wall and a vapour phase above the film. The film was set to a temperature 10K below the saturation temperature while the vapour was at saturation temperature. The phase change model used was the interfaceHeatResistance model. The top wall is hot and the bottom wall cold, gravity is off. Condensation should appear and the film should grow, while the evaporation massflux should be zero.
The condensation mass flux, which can be viewed in ParaView, seems to produce the correct value but there is also an evaporation mass flux, which is none zero. Also there is a strange behavior within the interface area calculation, which seems to randomly add parts of the walls. If i reversed the temperature setting and looked at an evaporation case the right behavior with growing vapour phase occurred.
### Steps to reproduce
Run the attached testcase, look at the mass fluxes and alpha-field in ParaView, especially at the interface.
### Example case
The example case is attached. [Example_case.zip](/uploads/4b1b23eb3154eb27a9cb0ac217df36e5/Example_case.zip)
### What is the current *bug* behaviour?
The solver produces an evaporation mass flux which isn't set to zero for a condensation case (T < Tsat). For information: In the reversed case (evaporation) the condensation mass flux is set to zero. Also the solver uses an wrong interface area with parts of the side walls.
### What is the expected *correct* behavior?
The evaporation mass flux should be set to zero in the case of a condensation case. And the liquid film should grow depending on the analytic solution for the Stefans problem. The interface area, which the solver uses, should only be the interface between the liquid and the vapour phase.https://develop.openfoam.com/Development/openfoam/-/issues/2207uniform Field gets output in ascii2021-09-13T09:33:47ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comuniform Field gets output in ascii### Functionality to add/problem to solve
A uniform field gets output as e.g. (see OpenFOAM/fields/Fields/Field/Field.C)
`uniform 123.456;`
The value gets written in ascii in the current precision. Hence any restart is not exact.### Functionality to add/problem to solve
A uniform field gets output as e.g. (see OpenFOAM/fields/Fields/Field/Field.C)
`uniform 123.456;`
The value gets written in ascii in the current precision. Hence any restart is not exact.https://develop.openfoam.com/Development/openfoam/-/issues/2204overset patch with setFields2021-09-09T15:48:19ZMatej Formanoverset patch with setFieldsI'm not sure, whether this is bug or a feature so I am going to call it an annoyance.
Let's imagine you have an overset patch, where you are using setFields utility to set alpha.water level.
At the same time you have empty BC oversetPa...I'm not sure, whether this is bug or a feature so I am going to call it an annoyance.
Let's imagine you have an overset patch, where you are using setFields utility to set alpha.water level.
At the same time you have empty BC oversetPatch of type overset (in boundary file and fields files as well).
When you are running setFields setting values on volumetric region, everything is fine,
once you start setting alpha on faces (e.g. to set a fixed value on inlets and outlets) you will receive an error saying oversetPatch needs value entry.
so the oversetPatch in alpha.water file looks like this:
`
oversetPatch
{
type overset;
value uniform 0;
}
`
It is not great nor terrible, but it's ugly.
OF v2106, ubuntu, arm64 standard out of box compilationhttps://develop.openfoam.com/Development/openfoam/-/issues/2192chtMultiRegionFoam -postProcess does not work2021-10-29T13:46:19ZHenning ScheuflerchtMultiRegionFoam -postProcess does not work
### Summary
The postProcessing results generated by postProcess and during runtime are not identical
### Steps to reproduce
./Allrun
and compare the postProcessing results
### Example case
[multiRegionHeater.tar.xz](/uploads/0901...
### Summary
The postProcessing results generated by postProcess and during runtime are not identical
### Steps to reproduce
./Allrun
and compare the postProcessing results
### Example case
[multiRegionHeater.tar.xz](/uploads/0901403264338b6e67029780bb33ce6b/multiRegionHeater.tar.xz)
### What is the current *bug* behaviour?
The results obtained by function object, probe and wallheatFlux, differ from the runtime results. The wallHeatflux and the temperature probe produce the same value for the whole time series. However, we see the correct behavior for the pressure ,p , with the probe function object
Is the temperature reloaded in the thermoLibraries?
PS the same behavior can also be observed in rhoPimpleFoam tut-case: helmholtzResonance
### What is the expected *correct* behavior?
The results should be identical
### Environment information
- OpenFOAM version : 2012
- Operating system : Ubuntu 2004
- Hardware info :
- Compiler : gcc
### Possible fixes
<!--
If you can, link to the line of code that might be responsible for the
problem
The "/label ~bug" text is a gitlab flag that will add the "bug" label to this
issue
-->https://develop.openfoam.com/Development/openfoam/-/issues/2191patchType does not survive operations2021-08-25T10:35:47ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.compatchType does not survive operations### Functionality to add/problem to solve
Override a bc on a constraint patch type (e.g. cyclicAMI) using the `patchType` override. Now do any kind of operation. E.g. run laplacianFoam (calculates&writes fvc::grad). This will e.g. write...### Functionality to add/problem to solve
Override a bc on a constraint patch type (e.g. cyclicAMI) using the `patchType` override. Now do any kind of operation. E.g. run laplacianFoam (calculates&writes fvc::grad). This will e.g. write gradTx which will have again `type cyclicAMI`. We might want the default `calculated` instead (so preserve the `patchType` override)
@andy @Prashant @mark
### Proposal
Have additional keyword like `patchType`?https://develop.openfoam.com/Development/openfoam/-/issues/2190BlockMesh fails when attempting to merge wedge blocks with mergePatchPairs2021-08-25T13:03:43ZMark YobbBlockMesh fails when attempting to merge wedge blocks with mergePatchPairs<!--
*** 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 -->
BlockMesh fails to run when attempting to merge a wedge block with a another block using mergePatchPairs. This occurs when merging a wedge to a wedge or a wedge to a quadrilateral block. This issue will not necessarily be something that comes up with wedge type mesh arrangements only.
This issue seems related to Issue #1862. Unlike issue #1862 this issue occurs when attempting to merge the three vertex end faces (patches) of a wedge (as opposed to the radial faces between outer radial wedge blocks.)
This issue goes away when including the "mergeType points;" directive in the blockMeshDict.
Before identifying the solution of mergeType I was attempting to solve this issue by using two vertices at the wedge origin located at a very small distance apart i.e. effectively at the same point so the first cells from the origin would in fact be hexahedron instead of prisms. This approach did infact allowed blockMesh to run. This suggests to me that the default merge algorithm is unable to handle the triangular cell faces of the prism cells on the patches.
Oddly enough when I run blockMesh on the rodFoamCase from Issue #1862 it runs with either the "mergeType points;" directive set or left to the default setting? Maybe there has been changes that already addressed #1862?
### Steps to reproduce
Within blockMeshDict create two wedge blocks or a wedge block and a quadrilateral block that share a common plane. If using two wedge blocks of the same included angle the wedge faces must not share all vertices on the common plane (like if one of the wedges is longer in the radial direction.) The grading on either side of the plane can be shared or different. Create patches on either side of plane associated with the blocks. blockMesh will run successfully if you do not attempt to merge the blocks. Set the patches to be merged with mergePatchPairs and run blockMesh again. It will fail and give the error shown below.
<!-- How one can reproduce the issue - this is very important -->
### Example case
I am including a couple of .tar.xz files that provide two cases of this error. One is for wedge blocks being merged together and one is for a wedge block being merged to a quadrilateral block. Just extract the cases and try running blockMesh. They will fail. Open the cases and uncomment the "mergeType points;" directive and try again. blockMesh will then successfully complete.
[PatchMergeWedgeToWedge.tar.xz](/uploads/f03dd5274b449e1ed7139325df4966c6/PatchMergeWedgeToWedge.tar.xz)
[PatchMergeWedgeToBlock.tar.xz](/uploads/9e75dca2b9a37fbdfadd92d139af3493/PatchMergeWedgeToBlock.tar.xz)
<!--
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?
BlockMesh only partially runs, outputs an error message and aborts.
<!-- What actually happens -->
### What is the expected *correct* behavior?
Ideally the default blockMesh meshing algorithm should be able to successfully mesh this geometry without requiring a directive to revert to the older meshing algorithm by using 'mergeType points;' in blockMeshDict or blockMesh -merge-points. It seems like it is something that it should be able to do without having to revert to an older meshing method via directive.
<!-- 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.
-->
The error that blockMesh outputs is:
"Adding point and face zones
Creating attachPolyTopoChanger
--> FOAM FATAL ERROR: (openfoam-2106)
Bad points:(2 0 0) (2 0 0) (3 0 0)
From void Foam::plane::calcFromEmbeddedPoints(const point&, const point&, const point&, const char*)
in file meshes/primitiveShapes/plane/plane.C at line 108.
FOAM aborting
#0 Foam::error::printStack(Foam::Ostream&) at ??:?
#1 Foam::error::exitOrAbort(int, bool) at ??:?
#2 Foam::plane::calcFromEmbeddedPoints(Foam::Vector<double> const&, Foam::Vector<double> const&, Foam::Vector<double> const&, char const*) at ??:?
#3 Foam::slidingInterface::coupleInterface(Foam::polyTopoChange&) const at ??:?
#4 Foam::slidingInterface::setRefinement(Foam::polyTopoChange&) const at ??:?
#5 Foam::polyTopoChanger::topoChangeRequest() const at ??:?
#6 Foam::polyTopoChanger::changeMesh(bool, bool, bool, bool) at ??:?
#7 Foam::attachPolyTopoChanger::attach(bool) at ??:?
#8 ? in ~/OpenFOAM/OpenFOAM-v2106/platforms/linux64GccDPInt32Opt/bin/blockMesh
#9 __libc_start_main in /lib/x86_64-linux-gnu/libc.so.6
#10 ? in ~/OpenFOAM/OpenFOAM-v2106/platforms/linux64GccDPInt32Opt/bin/blockMesh
Aborted"
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v1806|v1812|v1906|v1912|v2006|v2012|v2106 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2106
- Operating system : Debian Bullseye (11)
- Hardware info : AMD Ryzen 9 5950X 16-Core Processor, MemTotal: 65831088 kB
- Compiler : gcc version 10.2.1 20210110 (Debian 10.2.1-6)
### 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
-->
If someone comes up with a fix I will gladly help test. I will look at the code to see if I can spot the issue. Kind regards. Mark.https://develop.openfoam.com/Development/openfoam/-/issues/2189Cannot find parcel injection cell2021-11-01T12:12:49ZCongyaoCannot find parcel injection cell<!--
*** 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'm modelling a moving rigid sphere in a medium and including lagrangian particles to trace the gas flow. But I've always met the following error:
"--> FOAM FATAL ERROR:
Cannot find parcel injection cell. Parcel position = (-5.63103 21.11 -1)"
I don't know if this is a bug or there is anything I missed. Thanks!
### 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
-->
[pimpleLPTFoam.7z](/uploads/eecf8e4772c48906b1810294f1522f55/pimpleLPTFoam.7z)
[movingCone.7z](/uploads/3fee1e9f0df2873cb3ffcc781f8ef9be/movingCone.7z)
The solver simply includes lagrangian particles in the pimpleFoam.
### What is the current *bug* behaviour?
When topology changes, particles penetrate the moving wall boundary.
### What is the expected *correct* behavior?
Particles should be reflected by the wall.
### 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|v1912|v2006|v2012|v2106 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2106
- 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/2187BUG/ENH: multiWorld - blocks - multiple comms between same worlds2021-08-27T12:20:30ZPrashant SonakarBUG/ENH: multiWorld - blocks - multiple comms between same worldsAttached modified case of multiWorld2 where slab1 is extended to make 'U' connection to 'top' world. There is a slab in the middle which interacts with slab1 and top.
The `slab1` interacts with `top` via left and right side
![multiWorld...Attached modified case of multiWorld2 where slab1 is extended to make 'U' connection to 'top' world. There is a slab in the middle which interacts with slab1 and top.
The `slab1` interacts with `top` via left and right side
![multiWorld3](/uploads/a6d6e1698b22a45c94df9d6390ed02a6/multiWorld3.png)
[multiWorld3.tgz](/uploads/b5c71767477cf8b3e62cc3272a7e2407/multiWorld3.tgz)https://develop.openfoam.com/Development/openfoam/-/issues/2182interFoam for wave simulation fails in Debug but not in Opt2021-10-27T12:49:23ZValerio GraziosointerFoam for wave simulation fails in Debug but not in Opt<!--
*** 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 running a wave tank simulation with interFoam, if using openfoam compiled with WM_COMPILE_OPTION=Opt everything is ok. When using openfoam compiled with WM_COMPILE_OPTION=Debug the simulation crashes during the first timestep
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
1) run Allrun script (mesh preparation)
2) run the attached case with "interFoam" with openfoam v2106 (verified also for v1812) compiled with WM_COMPILE_OPTION=Debug
### 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 attachment
### What is the current *bug* behaviour?
<!-- What actually happens -->
The code crashes
### What is the expected *correct* behavior?
<!-- What you should see instead -->
It should run until Time=25
### 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.
-->
```
/*---------------------------------------------------------------------------*\
| ========= | |
| \\ / F ield | OpenFOAM: The Open Source CFD Toolbox |
| \\ / O peration | Version: v2106 |
| \\ / A nd | Website: www.openfoam.com |
| \\/ M anipulation | |
\*---------------------------------------------------------------------------*/
Build : _c15bfde3cb-20210624 OPENFOAM=2106
Arch : "LSB;label=32;scalar=64"
Exec : interFoam
Date : Aug 16 2021
Time : 03:23:02
Host : valerio-Z370-HD3P
PID : 190691
I/O : uncollated
Case : ~/OpenFOAM/Tanks/2021/RobustControl/Hemisphere_WEC/40N
nProcs : 1
trapFpe: Floating point exception trapping enabled (FOAM_SIGFPE).
fileModificationChecking : Monitoring run-time modified files using timeStampMaster (fileModificationSkew 5, maxFileModificationPolls 20)
allowSystemOperations : Allowing user-supplied system call operations
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
Create time
Create mesh for time = 0
Selecting dynamicFvMesh dynamicMotionSolverFvMesh
Selecting motion solver: sixDoFRigidBodyMotion
Applying solid body motion to entire mesh
Selecting sixDoFSolver Newmark
Translational constraint tensor (0 0 0 0 0 0 0 0 1)
Rotational constraint tensor (0 0 0 0 0 0 0 0 0)
PIMPLE: Operating solver in PISO mode
Reading field p_rgh
Reading field U
Reading/calculating face flux field phi
Reading transportProperties
Selecting incompressible transport model Newtonian
Selecting incompressible transport model Newtonian
Selecting turbulence model type laminar
Selecting laminar stress model Stokes
Reading g
Reading hRef
Calculating field g.h
No MRF models present
No finite volume options present
GAMGPCG: Solving for pcorr, Initial residual = 0, Final residual = 0, No Iterations 0
GAMGPCG: Solving for pcorr, Initial residual = 0, Final residual = 0, No Iterations 0
GAMGPCG: Solving for pcorr, Initial residual = 0, Final residual = 0, No Iterations 0
time step continuity errors : sum local = 0, global = 0, cumulative = 0
Constructing face velocity Uf
Courant Number mean: 0 max: 0
Starting time loop
forces forces:
rho: rhoInf
Freestream density (rhoInf) set to 1000
Not including porosity effects
Courant Number mean: 0 max: 0
Interface Courant Number mean: 0 max: 0
Time = 0.001
PIMPLE: iteration 1
forces forces:
rho: rho
Not including porosity effects
Restraint Spring: attachmentPt - anchor (0 0 2.678) spring length 2.678 force (-0 -0 -16.0364)
Restraint PTO: attachmentPt - anchor (0 0 2.678) spring length 2.678 control force (0 0 0.0024) control force raw0.0024 nTimes4
6-DoF rigid body motion
Centre of rotation: (0 0 -0.131)
Centre of mass: (0 0 -0.131)
Orientation: (1 0 0 0 1 0 0 0 1)
Linear velocity: (0 0 -1.46985e-05)
Angular velocity: (0 0 0)
Selecting waveModel shallowWaterAbsorption
--> FOAM FATAL ERROR: (openfoam-2106)
Field<vector> f1(5085) and Field<vector> f2(0)
for operation f1 = s & f2
From void Foam::checkFields(const Foam::UList<T>&, const Foam::UList<Key>&, const char*) [with Type1 = Foam::Vector<double>; Type2 = Foam::Vector<double>]
in file ~/OpenFOAM/OpenFOAM-v2106/src/OpenFOAM/lnInclude/FieldM.H at line 58.
FOAM aborting
#0 Foam::error::printStack(Foam::Ostream&) at ~/OpenFOAM/OpenFOAM-v2106/src/OSspecific/POSIX/printStack/printStack.C:237
#1 Foam::error::exitOrAbort(int, bool) at ~/OpenFOAM/OpenFOAM-v2106/src/OpenFOAM/lnInclude/error.C:261
#2 Foam::error::abort() at ~/OpenFOAM/OpenFOAM-v2106/src/OpenFOAM/lnInclude/error.C:297
#3 Foam::Ostream& Foam::operator<< <Foam::error>(Foam::Ostream&, Foam::errorManip<Foam::error>) in ~/OpenFOAM/OpenFOAM-v2106/platforms/linux64GccDPInt32Debug/bin/interFoam
#4 void Foam::checkFields<Foam::Vector<double>, Foam::Vector<double> >(Foam::UList<Foam::Vector<double> > const&, Foam::UList<Foam::Vector<double> > const&, char const*) in ~/OpenFOAM/OpenFOAM-v2106/platforms/linux64GccDPInt32Debug/bin/interFoam
#5 void Foam::dot<Foam::Tensor<double>, double, (unsigned char)9, Foam::Vector<double> >(Foam::Field<Foam::innerProduct<Foam::Tensor<double>, Foam::Vector<double> >::type>&, Foam::VectorSpace<Foam::Tensor<double>, double, (unsigned char)9> const&, Foam::UList<Foam::Vector<double> > const&) at ~/OpenFOAM/OpenFOAM-v2106/src/OpenFOAM/lnInclude/FieldFunctions.C:827
#6 Foam::tmp<Foam::Field<Foam::innerProduct<Foam::Tensor<double>, Foam::Vector<double> >::type> > Foam::operator&<Foam::Tensor<double>, double, (unsigned char)9, Foam::Vector<double> >(Foam::VectorSpace<Foam::Tensor<double>, double, (unsigned char)9> const&, Foam::UList<Foam::Vector<double> > const&) at ~/OpenFOAM/OpenFOAM-v2106/src/OpenFOAM/lnInclude/FieldFunctions.C:827
#7 Foam::waveModel::initialiseGeometry() at ~/OpenFOAM/OpenFOAM-v2106/src/waveModels/waveModel/waveModel.C:94 (discriminator 1)
#8 Foam::waveModel::readDict(Foam::dictionary const&) at ~/OpenFOAM/OpenFOAM-v2106/src/waveModels/waveModel/waveModel.C:323 (discriminator 2)
#9 Foam::waveModels::waveAbsorptionModel::readDict(Foam::dictionary const&) at ~/OpenFOAM/OpenFOAM-v2106/src/waveModels/waveAbsorptionModels/base/waveAbsorptionModel/waveAbsorptionModel.C:80
#10 Foam::waveModels::shallowWaterAbsorption::readDict(Foam::dictionary const&) at ~/OpenFOAM/OpenFOAM-v2106/src/waveModels/waveAbsorptionModels/derived/shallowWaterAbsorption/shallowWaterAbsorption.C:115
#11 Foam::waveModels::shallowWaterAbsorption::shallowWaterAbsorption(Foam::dictionary const&, Foam::fvMesh const&, Foam::polyPatch const&, bool) at ~/OpenFOAM/OpenFOAM-v2106/src/waveModels/waveAbsorptionModels/derived/shallowWaterAbsorption/shallowWaterAbsorption.C:104
#12 Foam::waveModel::addpatchConstructorToTable<Foam::waveModels::shallowWaterAbsorption>::New(Foam::dictionary const&, Foam::fvMesh const&, Foam::polyPatch const&) at ~/OpenFOAM/OpenFOAM-v2106/src/waveModels/lnInclude/waveModel.H:184 (discriminator 2)
#13 Foam::waveModel::New(Foam::word const&, Foam::fvMesh const&, Foam::polyPatch const&) at ~/OpenFOAM/OpenFOAM-v2106/src/waveModels/waveModel/waveModelNew.C:81
#14 Foam::waveModel::lookupOrCreate(Foam::polyPatch const&, Foam::fvMesh const&, Foam::word const&) at ~/OpenFOAM/OpenFOAM-v2106/src/waveModels/waveModel/waveModelNew.C:98 (discriminator 1)
#15 Foam::waveVelocityFvPatchVectorField::updateCoeffs() at ~/OpenFOAM/OpenFOAM-v2106/src/waveModels/derivedFvPatchFields/waveVelocity/waveVelocityFvPatchVectorField.C:112
#16 Foam::fvPatchField<Foam::Vector<double> >::evaluate(Foam::UPstream::commsTypes) at ~/OpenFOAM/OpenFOAM-v2106/src/finiteVolume/lnInclude/fvPatchField.C:340
#17 Foam::GeometricField<Foam::Vector<double>, Foam::fvPatchField, Foam::volMesh>::Boundary::evaluate() in ~/OpenFOAM/OpenFOAM-v2106/platforms/linux64GccDPInt32Debug/bin/interFoam
#18 Foam::GeometricField<Foam::Vector<double>, Foam::fvPatchField, Foam::volMesh>::correctBoundaryConditions() in ~/OpenFOAM/OpenFOAM-v2106/platforms/linux64GccDPInt32Debug/bin/interFoam
#19 Foam::dynamicMotionSolverFvMesh::update() at ~/OpenFOAM/OpenFOAM-v2106/src/dynamicFvMesh/dynamicMotionSolverFvMesh/dynamicMotionSolverFvMesh.C:135
#20 ? in ~/OpenFOAM/OpenFOAM-v2106/platforms/linux64GccDPInt32Debug/bin/interFoam
#21 __libc_start_main in /lib/x86_64-linux-gnu/libc.so.6
#22 ? in ~/OpenFOAM/OpenFOAM-v2106/platforms/linux64GccDPInt32Debug/bin/interFoam
```
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v1806|v1812|v1906|v1912|v2006|v2012|v2106 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version :v1812 | v2106
- Operating system :ubuntu (mint)
- Hardware info :Intel i7
- Compiler :gcc
### Possible fixes
<!--
If you can, link to the line of code that might be responsible for the
problem
The "/label ~bug" text is a gitlab flag that will add the "bug" label to this
issue
-->
It seems that the inner product vector * tensor ,fails a dimension check because the second operand (tensor) is "seen" with 0 dimension, while it is not. Maybe a problem with the template for the double type in the Debug case??[WaveTank_s.tar.gz](/uploads/1bce0558586853ce59222151f8476815/WaveTank_s.tar.gz)Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2181multi-world operation : setup2021-08-09T14:52:26ZPrashant Sonakarmulti-world operation : setup### Functionality to add/problem to solve
- Case with some BCs using database (syncObjects) and others not: hangs. Maybe add a check at startup
@mark### Functionality to add/problem to solve
- Case with some BCs using database (syncObjects) and others not: hangs. Maybe add a check at startup
@markhttps://develop.openfoam.com/Development/openfoam/-/issues/2180Feature: volume fraction2021-08-09T11:37:18ZPrashant SonakarFeature: volume fractionAs discussed, it would be nice to have a volume fraction of a specified species in the domain for multi-species cases.As discussed, it would be nice to have a volume fraction of a specified species in the domain for multi-species cases.Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/issues/2179mapFieldsPar problem when running in Parallel2023-09-06T09:01:10ZPablo UsyaopinmapFieldsPar problem when running 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
When executing the mapFieldsPar in parallel trying to map one box with 2 elements into another box of 2 or 4, or more elements I encounter a out of index error. When executing the same in serial it works fine.
### Steps to reproduce
In the target source I execute the following:
mpirun -np 2 mapFieldsPar /decayIsoTurb4.1_copyWithLessTime -sourceTime latestTime -parallel
### What is the current *bug* behaviour?
```
/*---------------------------------------------------------------------------*\
| ========= | |
| \\ / F ield | OpenFOAM: The Open Source CFD Toolbox |
| \\ / O peration | Version: v2006 |
| \\ / A nd | Website: www.openfoam.com |
| \\/ M anipulation | |
\*---------------------------------------------------------------------------*/
Build : 5e660c36e9-20201103 OPENFOAM=2006 patch=201012
Arch : "LSB;label=32;scalar=64"
Exec : mapFieldsPar /home/pablo/Desktop/ApplicationRuhr/Data/paperIlana/twoPointCorrEnric/decayIsoTurb4.1_copyWithLessTime -sourceTime latestTime -parallel
Date : Aug 07 2021
Time : 10:09:18
Host : pablo-XPS-13-9370
PID : 13775
I/O : uncollated
Case : /home/pablo/Desktop/ApplicationRuhr/Data/paperIlana/twoPointCorrEnric/decayIsoTurb4.1_trialWithLessElements
nProcs : 2
Hosts :
(
(pablo-XPS-13-9370 2)
)
Pstream initialized with:
floatTransfer : 0
nProcsSimpleSum : 0
commsType : nonBlocking
polling iterations : 0
trapFpe: Floating point exception trapping enabled (FOAM_SIGFPE).
fileModificationChecking : Monitoring run-time modified files using timeStampMaster (fileModificationSkew 5, maxFileModificationPolls 20)
allowSystemOperations : Allowing user-supplied system call operations
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
Source: "/home/pablo/Desktop/ApplicationRuhr/Data/paperIlana/twoPointCorrEnric" "decayIsoTurb4.1_copyWithLessTime"
Target: "/home/pablo/Desktop/ApplicationRuhr/Data/paperIlana/twoPointCorrEnric" "decayIsoTurb4.1_trialWithLessElements"
Create databases as time
I/O : uncollated
Case : /home/pablo/Desktop/ApplicationRuhr/Data/paperIlana/twoPointCorrEnric/decayIsoTurb4.1_copyWithLessTime
nProcs : 2
Hosts :
(
(pablo-XPS-13-9370 2)
)
Pstream initialized with:
floatTransfer : 0
nProcsSimpleSum : 0
commsType : nonBlocking
polling iterations : 0
Overriding DebugSwitches according to controlDict
meshToMesh 2;
Source time: 0
Target time: 0
Create meshes
Source mesh size: 2 Target mesh size: 2
Creating and mapping fields for time 0
Creating mesh-to-mesh addressing for region0 and region0 regions using cellVolumeWeight
From Foam::label Foam::meshToMesh::calcDistribution(const Foam::polyMesh&, const Foam::polyMesh&) const
in file meshToMesh/meshToMeshParallelOps.C at line 70
Meshes split across multiple processors
meshToMesh: Using AABBTree method
From Foam::autoPtr<Foam::mapDistribute> Foam::meshToMesh::calcProcMap(const Foam::polyMesh&, const Foam::polyMesh&) const
in file meshToMesh/meshToMeshParallelOps.C at line 176
Determining extent of src mesh per processor:
proc bb
0 2{(-0.0003 -0.0003 -0.0003) (0.0203 0.0203 0.0103)}
1 2{(-0.0003 -0.0003 0.0097) (0.0203 0.0203 0.0203)}
[0] Of my 1 target cells I need to send to:
[0] proc cells
[0] 0 1
[0] 1 1
[1] Of my 1 target cells I need to send to:
[1] proc cells
[1] 0 1
[1] 1 1
[0] tgtProc:0 sending tgt cell 0[0] to srcProc 0
[1] tgtProc:1 sending tgt cell 0[1] to srcProc 0
[0] tgtProc:0 sending tgt cell 0[0] to srcProc 1
[1] tgtProc:1 sending tgt cell 0[1] to srcProc 1
[0] Target mesh send sizes[0]: points=8, faces=6, nInternalFaces=0, faceOwn=6, faceNbr=6, cellIDs=1
[0] Target mesh send sizes[1]: points=8, faces=6, nInternalFaces=0, faceOwn=6, faceNbr=6, cellIDs=1
[1] Target mesh send sizes[0]: points=8, faces=6, nInternalFaces=0, faceOwn=6, faceNbr=6, cellIDs=1
[1] Target mesh send sizes[1]: points=8, faces=6, nInternalFaces=0, faceOwn=6, faceNbr=6, cellIDs=1
[0] Additional internal face between procs:0 and 1 across local face 0
[0] Additional internal face between procs:0 and 1 across local face 0
[1] Additional internal face between procs:0 and 1 across local face 0
[1] Additional internal face between procs:0 and 1 across local face 0
[0] Additional internal face between procs:0 and 1 across local face 0
[1] Additional internal face between procs:0 and 1 across local face 0
[0] proc 0 inserting face:0 connection between owner 0 and neighbour 0
[0] proc 1 inserting face:1 connection between owner 1 and neighbour -2
[1] proc 0 inserting face:0 connection between owner 0 and neighbour 0
[1] proc 1 inserting face:1 connection between owner 1 and neighbour -2
[1] proc 1 inserting face:2 connection between owner 1 and neighbour -2
[0] proc 1 inserting face:2 connection between owner 1 and neighbour -2
[0]
[0]
[0] --> FOAM FATAL ERROR:
[0] index 9 out of range [0,9]
[0]
[0] From void Foam::UList<T>::checkIndex(Foam::label) const [with T = Foam::face; Foam::label = int]
[0] in file /home/pablo/BuildOpenFoamPlus/OpenFoamGit/openfoam/src/OpenFOAM/lnInclude/UListI.H at line 138.
[0]
FOAM parallel run aborting
[0]
[1]
[1]
[1] --> FOAM FATAL ERROR:
[1] index 9 out of range [0,9]
[1]
[1] From void Foam::UList<T>::checkIndex(Foam::label) const [with T = Foam::face; Foam::label = int]
[1] in file /home/pablo/BuildOpenFoamPlus/OpenFoamGit/openfoam/src/OpenFOAM/lnInclude/UListI.H at line 138.
[1]
FOAM parallel run aborting
[0]
[1]
[1]
[1] --> FOAM FATAL ERROR:
[1] index 9 out of range [0,9]
[1]
[1] From void Foam::UList<T>::checkIndex(Foam::label) const [with T = Foam::face; Foam::label = int]
[1] in file /home/pablo/BuildOpenFoamPlus/OpenFoamGit/openfoam/src/OpenFOAM/lnInclude/UListI.H at line 138.
[1]
[1]
[0] #0 [1] #0 Foam::error::printStack(Foam::Ostream&)Foam::error::printStack(Foam::Ostream&) at ~/BuildOpenFoamPlus/OpenFoamGit/openfoam/src/OSspecific/POSIX/printStack/printStack.C:237
at ~/BuildOpenFoamPlus/OpenFoamGit/openfoam/src/OSspecific/POSIX/printStack/printStack.C:237
[1] #1 Foam::error::exitOrAbort(int, bool)[0] #1 Foam::error::exitOrAbort(int, bool) at ~/BuildOpenFoamPlus/OpenFoamGit/openfoam/src/OpenFOAM/lnInclude/error.C:265
at ~/BuildOpenFoamPlus/OpenFoamGit/openfoam/src/OpenFOAM/lnInclude/error.C:265
[1] #2 Foam::error::abort()[0] #2 Foam::error::abort() at ~/BuildOpenFoamPlus/OpenFoamGit/openfoam/src/OpenFOAM/lnInclude/error.C:307
[0] #3 at ~/BuildOpenFoamPlus/OpenFoamGit/openfoam/src/OpenFOAM/lnInclude/error.C:307
[1] #3 Foam::Ostream& Foam::operator<< <Foam::error>(Foam::Ostream&, Foam::errorManip<Foam::error>)Foam::Ostream& Foam::operator<< <Foam::error>(Foam::Ostream&, Foam::errorManip<Foam::error>) in ~/BuildOpenFoamPlus/OpenFoamGit/openfoam/platforms/linux64Gcc75DPInt32Debug/bin/mapFieldsPar
[0] #4 in ~/BuildOpenFoamPlus/OpenFoamGit/openfoam/platforms/linux64Gcc75DPInt32Debug/bin/mapFieldsPar
[1] #4 Foam::UList<Foam::face>::checkIndex(int) constFoam::UList<Foam::face>::checkIndex(int) const in ~/BuildOpenFoamPlus/OpenFoamGit/openfoam/platforms/linux64Gcc75DPInt32Debug/bin/mapFieldsPar
[0] #5 Foam::UList<Foam::face>::operator[](int) in ~/BuildOpenFoamPlus/OpenFoamGit/openfoam/platforms/linux64Gcc75DPInt32Debug/bin/mapFieldsPar
[1] #5 Foam::UList<Foam::face>::operator[](int) at ~/BuildOpenFoamPlus/OpenFoamGit/openfoam/src/OpenFOAM/lnInclude/UListI.H:251
at ~/BuildOpenFoamPlus/OpenFoamGit/openfoam/src/OpenFOAM/lnInclude/UListI.H:251
[0] #6 Foam::meshToMesh::distributeAndMergeCells(Foam::mapDistribute const&, Foam::polyMesh const&, Foam::globalIndex const&, Foam::Field<Foam::Vector<double> >&, Foam::List<Foam::face>&, Foam::List<int>&, Foam::List<int>&, Foam::List<int>&) const[1] #6 Foam::meshToMesh::distributeAndMergeCells(Foam::mapDistribute const&, Foam::polyMesh const&, Foam::globalIndex const&, Foam::Field<Foam::Vector<double> >&, Foam::List<Foam::face>&, Foam::List<int>&, Foam::List<int>&, Foam::List<int>&) const at ~/BuildOpenFoamPlus/OpenFoamGit/openfoam/src/sampling/meshToMesh/meshToMeshParallelOps.C:860 (discriminator 1)
[0] #7 Foam::meshToMesh::calculate(Foam::word const&, bool) at ~/BuildOpenFoamPlus/OpenFoamGit/openfoam/src/sampling/meshToMesh/meshToMeshParallelOps.C:860 (discriminator 1)
[1] #7 Foam::meshToMesh::calculate(Foam::word const&, bool) at ~/BuildOpenFoamPlus/OpenFoamGit/openfoam/src/sampling/meshToMesh/meshToMesh.C:466 (discriminator 1)
[1] #8 Foam::meshToMesh::constructFromCuttingPatches(Foam::word const&, Foam::word const&, Foam::HashTable<Foam::word, Foam::word, Foam::string::hash> const&, Foam::List<Foam::word> const&, bool) at ~/BuildOpenFoamPlus/OpenFoamGit/openfoam/src/sampling/meshToMesh/meshToMesh.C:466 (discriminator 1)
[0] #8 Foam::meshToMesh::constructFromCuttingPatches(Foam::word const&, Foam::word const&, Foam::HashTable<Foam::word, Foam::word, Foam::string::hash> const&, Foam::List<Foam::word> const&, bool) at ~/BuildOpenFoamPlus/OpenFoamGit/openfoam/src/sampling/meshToMesh/meshToMesh.C:832
at ~/BuildOpenFoamPlus/OpenFoamGit/openfoam/src/sampling/meshToMesh/meshToMesh.C:832
[1] #9 Foam::meshToMesh::meshToMesh(Foam::polyMesh const&, Foam::polyMesh const&, Foam::word const&, Foam::word const&, Foam::HashTable<Foam::word, Foam::word, Foam::string::hash> const&, Foam::List<Foam::word> const&, Foam::meshToMesh::procMapMethod const&, bool)[0] #9 Foam::meshToMesh::meshToMesh(Foam::polyMesh const&, Foam::polyMesh const&, Foam::word const&, Foam::word const&, Foam::HashTable<Foam::word, Foam::word, Foam::string::hash> const&, Foam::List<Foam::word> const&, Foam::meshToMesh::procMapMethod const&, bool) at ~/BuildOpenFoamPlus/OpenFoamGit/openfoam/src/sampling/meshToMesh/meshToMesh.C:980
[0] #10 at ~/BuildOpenFoamPlus/OpenFoamGit/openfoam/src/sampling/meshToMesh/meshToMesh.C:980
[1] #10 ?? in ~/BuildOpenFoamPlus/OpenFoamGit/openfoam/platforms/linux64Gcc75DPInt32Debug/bin/mapFieldsPar
[0] #11 in ~/BuildOpenFoamPlus/OpenFoamGit/openfoam/platforms/linux64Gcc75DPInt32Debug/bin/mapFieldsPar
[1] #11 ?? in ~/BuildOpenFoamPlus/OpenFoamGit/openfoam/platforms/linux64Gcc75DPInt32Debug/bin/mapFieldsPar
[0] #12 __libc_start_main in ~/BuildOpenFoamPlus/OpenFoamGit/openfoam/platforms/linux64Gcc75DPInt32Debug/bin/mapFieldsPar
[1] #12 __libc_start_main in /lib/x86_64-linux-gnu/libc.so.6
[0] #13 in /lib/x86_64-linux-gnu/libc.so.6
[1] #13 ?? in ~/BuildOpenFoamPlus/OpenFoamGit/openfoam/platforms/linux64Gcc75DPInt32Debug/bin/mapFieldsPar
```
### What is the expected *correct* behavior?
When running in serial the result is as expected:
```
mapFieldsPar /decayIsoTurb4.1_copyWithLessTime -sourceTime latestTime
```
```
Source: "/home/pablo/Desktop/ApplicationRuhr/Data/paperIlana/twoPointCorrEnric" "decayIsoTurb4.1_copyWithLessTime"
Target: "/home/pablo/Desktop/ApplicationRuhr/Data/paperIlana/twoPointCorrEnric" "decayIsoTurb4.1_trialWithLessElements"
Create databases as time
I/O : uncollated
Case : /home/pablo/Desktop/ApplicationRuhr/Data/paperIlana/twoPointCorrEnric/decayIsoTurb4.1_copyWithLessTime
nProcs : 1
Overriding DebugSwitches according to controlDict
meshToMesh 2;
Source time: 0
Target time: 0
Create meshes
Source mesh size: 2 Target mesh size: 2
Creating and mapping fields for time 0
Creating mesh-to-mesh addressing for region0 and region0 regions using cellVolumeWeight
Source size = 2
Target size = 2
Overlap volume: 8e-06
interpolating onto existing field U
ExecutionTime = 0.03 s ClockTime = 0 s
End
```
### Environment information
- OpenFOAM version : v2006 and v2012
- Operating system : Ubuntu 18.04 and OpenSuse 15.2
- Hardware info :
- Compiler : gcc7.5
The "/label ~bug" text is a gitlab flag that will add the "bug" label to this
issue
-->