Development issueshttps://develop.openfoam.com/groups/Development/-/issues2023-09-06T09:01:10Zhttps://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
-->https://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/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/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/2183pimpleFoam fails if ddtCorr is turned off2021-08-18T09:08:01ZSaeedsaeed.salehi@chalmers.sepimpleFoam fails if ddtCorr is turned 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
You can see how your report will be re...<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be rendered on the platform by using the
"preview" tab above
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
The ddtCorr term is now optional in the pimpleFoam solver. It is controlled by the pimpleControl class through:
`ddtCorr_ = pimpleDict.getOrDefault("ddtCorr", true);`
The default value is _true_. But if one tries to set it to _false_ the pimpleFoam returns the following error:
`--> FOAM FATAL ERROR: (openfoam-2012)`\
`Different dimensions for '(a += b)'`\
` dimensions : [0 3 -1 0 0 0 0] != [0 0 1 0 0 0 0]`
### Steps to reproduce
One can simply reproduce this problem by setting ddtCorr to false in the PIMPLE dictionary in fvSolution of any pimpleFoam case.
### What is the current *bug* behaviour?
In the pEqn.H file of pimpleFoam we have:
`if (pimple.ddtCorr())`\
`{`\
` phiHbyA += MRF.zeroFilter(fvc::interpolate(rAU)*fvc::ddtCorr(U, phi, Uf));`\
`}`\
`else`\
`{`\
` phiHbyA += MRF.zeroFilter(fvc::interpolate(rAU));`\
`}`
Therefore, when ddtCorr is set to _false_ the _else_ statement activates. However, the zeroFilter needs a phi (flux) field as an input argument, while `fvc::interpolate(rAU)` does not have a flux dimension. That's why we get a dimension error.
### Possible fixes
Simply removing the _else_ statement should fix the problem. When the ddtCorr is set to _false_, no extra time correction is required for the fluxes. Therefore, we should simply skip the _if_ statement.Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/issues/2184Crash using ParticleCollector in parallel2021-09-08T08:44:54ZDarrin StephensCrash using ParticleCollector in parallel
### Summary
When using the ParticleCollector cloud function in parallel the simulation may crash. The crash is dependent on the number of processors used and the memory state of the computer.
### Steps to reproduce
I have been able t...
### Summary
When using the ParticleCollector cloud function in parallel the simulation may crash. The crash is dependent on the number of processors used and the memory state of the computer.
### Steps to reproduce
I have been able to replicate this problem on multiple computers using the splashPanel tutorial (tutorials/lagrangian/reactingParcelFoam/splashPanel). To get the crash behaviour this tutorial needs to be run with at least 10 processors. The small number of cells in the wall region with this number of processors is no the cause of the crash. I have had this problem on much bigger cases that I cannot share.
### Example case
[splashPLanel_parallel.tar.gz](/uploads/48c93fa4e973ecc29ce991c948e03b8d/splashPLanel_parallel.tar.gz)
### What is the current *bug* behaviour?
When the bug is encountered you will get an error message similar to that shown below. Note the processor that the problem occurs on can be different between crashes.
```
[3] --> FOAM FATAL IO ERROR: (openfoam-2012 patch=210618)
[3] Wrong token type - expected scalar value, found on line 3: punctuation '-'
[3]
[3] file: /tmp/06_splashPLanel_parallel/processor3/0/uniform/lagrangian/reactingCloud1/reactingCloud1OutputProperties.cloudFunctionObject.particleCollector1.massTotal at line 3.
[3]
[3] From Foam::Istream& Foam::operator>>(Foam::Istream&, Foam::doubleScalar&)
[3] in file lnInclude/Scalar.C at line 154.
[3]
FOAM parallel run exiting
```
### What is the expected *correct* behavior?
Correct behaviour is the cloud function calculate the massTotal and MassFlowRate without crashing.
### Environment information
- OpenFOAM version : v2106 and at least v2012. Older versions have not been tested.
- Operating system : ubuntu and centos
- Hardware info :
- Compiler : gcc
### Possible fixes
The line number below refer to the v2016 version of src/lagrangian/intermediate/submodels/CloudFunctionObjects/ParticleCollector/ParticleCollector.C.
The problem is caused by some processors getting a -nan for the massTotal and/or massFlowRate. These values get written to the processor uniform/lagrangian/reactingCloud1/reactingCloud1OutputProperties dictionary. This results in a read failure at lines 427 and 430 on the next timestep.
The reason for the nan's. The massTotal and massFlowRate are calculated for each collector's face in the loop on lines 435-459. The scalar lists allProcMass and allProcMassFlowRate are not initialised to any value at declaration. i.e. they get whatever is in the memory location. A gather function is then used on these lists. After the gather, every processor only knows its own data and that of the processors below it. This means only the master process has the complete list. Other processors lists may still have junk numbers from initialisation. The sum operations performed on lines 440 and 445 will sum the local list for each processor. Noting only the master has the correct list. The correct values are reported because of the Info<< usage on line 461. Lines 497 and 498 write the values for the massTotal and massFlowRate into the reactingCloud1OutputProperties dictionary for each processor, potentially causing the read problem on the next timestep.
Proposed solution: There are a couple of ways to fix this. One would be to scatter the list after the gather, making sure all processors have the same information. Since it appears it is only the master that needs this information, an alternative solution is to initialise the allProcMass and allProcMassFlowRate lists to zero at construction. That way the sums (lines 440 and 445) will not result in large (overflow) numbers.https://develop.openfoam.com/Development/openfoam/-/issues/2185Bug: foamToEnsight skips mesh2021-09-09T16:14:41ZPrashant SonakarBug: foamToEnsight skips meshFollowing illustrator creates valid EnSight in v1912 but later versions seem to skip the time without uniform folder and hence invalid EnSight export.
[pitzDaily.tgz](/uploads/9b6a5226d64515b801940207310b4538/pitzDaily.tgz)
@markFollowing illustrator creates valid EnSight in v1912 but later versions seem to skip the time without uniform folder and hence invalid EnSight export.
[pitzDaily.tgz](/uploads/9b6a5226d64515b801940207310b4538/pitzDaily.tgz)
@markhttps://develop.openfoam.com/Development/openfoam/-/issues/2186rotateMesh performs faulty operations in some boundary conditions2021-12-09T20:11:32ZDário CanossirotateMesh performs faulty operations in some boundary conditions### Summary
When applied to cases containing specific boundary conditions defined for vectorial or tensorial fields, the utility `rotateMesh` performs a _double rotation_, due to inadequate behaviour when writing transformed points into...### Summary
When applied to cases containing specific boundary conditions defined for vectorial or tensorial fields, the utility `rotateMesh` performs a _double rotation_, due to inadequate behaviour when writing transformed points into the polyMesh directory. If multiple time directories are present, only the first one is affected.
### Steps to reproduce
It is possible to reproduce the bug by setting an OpenFOAM case including specific boundary conditions for vectorial (or tensorial) fields that need to read geometric data from the mesh. For instance, in the `simpleFoam` tutorial _pitzDaily_, if we replace the inlet boundaryField condition with a _flowRateInletVelocity_ condition equivalent to the original _fixedValue_ condition, in the `0/U` file, like:
```
/*--------------------------------*- C++ -*----------------------------------*\
| ========= | |
| \\ / F ield | OpenFOAM: The Open Source CFD Toolbox |
| \\ / O peration | Version: v2106 |
| \\ / A nd | Website: www.openfoam.com |
| \\/ M anipulation | |
\*---------------------------------------------------------------------------*/
FoamFile
{
version 2.0;
format ascii;
class volVectorField;
object U;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
dimensions [0 1 -1 0 0 0 0];
internalField uniform (0 0 0);
boundaryField
{
/*inlet
{
type fixedValue;
value uniform (10 0 0);
}*/
inlet
{
type flowRateInletVelocity;
volumetricFlowRate 2.54e-4;
}
outlet
{
type zeroGradient;
}
upperWall
{
type noSlip;
}
lowerWall
{
type noSlip;
}
frontAndBack
{
type empty;
}
}
// ************************************************************************* //
```
And then perform a simple +45 degree rotation along the z-axis using the utility `rotateMesh` (could be _any_ arbitrary rotation), the velocity vector defined in the inlet boundaryField for `U` is erroneously rotated twice, completing a 90 degree rotation.
This +45 degree rotation along the z-axis can be achieved by this _Allrun_ shell script:
```
#!/bin/sh
cd "${0%/*}" || exit # Run from this directory
. ${WM_PROJECT_DIR:?}/bin/tools/RunFunctions # Tutorial run functions
#------------------------------------------------------------------------------
# Create 0.orig directory for backup
[ -d 0 ] && mv 0 0.orig
cp -r 0.orig/ 0/
runApplication blockMesh
runApplication rotateMesh "(1 0 0)" "(0.707107 0.707107 0)"
runApplication $(getApplication)
#------------------------------------------------------------------------------
```
### Example case
Find attached the example case described above.
[pitzDaily_bug_rotateMesh.zip](/uploads/c2ffc024466ade780fb48544ea2e1787/pitzDaily_bug_rotateMesh.zip)
### What is the current *bug* behaviour?
The utility `rotateMesh` performs a _double rotation_ to the velocity vector defined in the inlet boundaryField for `U`.
This is due to an inadequate behaviour in the `rotateMesh` algorithm, which writes the transformed points into the polyMesh directory **before** the vector and tensor fields are rotated. Vector or tensor boundary conditions that must read from the mesh points in order to write corresponding vector/tensor values are hence rotated twice.
### What is the expected *correct* behavior?
The expected correct behaviour can be obtained by using the utility `transformPoints` instead, for reproducing the same rotation, with the _rotateFields_ flag. The commands below can be employed and lead to the same +45 degree rotation, however without breaking the inlet boundaryField velocity vector:
`$ transformPoints -rotate '((1 0 0) (0.707107 0.707107 0))' -rotateFields`
or
`$ transformPoints -rotate-angle '((0 0 1) 45)' -rotateFields`
### Relevant logs and/or images
Erroneous inlet boundaryField for the velocity after the rotation (produced by the `rotateMesh` utility):
```
inlet
{
type flowRateInletVelocity;
volumetricFlowRate constant 0.000254;
value nonuniform List<vector>
30
(
(3.730349363e-14 10 0)
(-2.069228318e-07 10 0)
(3.375077995e-14 10 0)
(1.80136758e-07 10 -8.429032341e-17)
(0 10 0)
(-1.568181549e-07 10 -7.337898766e-17)
(1.463164896e-07 10 -6.846501721e-17)
(-1.365181355e-07 10 0)
(1.273759462e-07 10 -1.192045185e-16)
(-1.188459393e-07 10 1.112217487e-16)
(1.108871617e-07 10 0)
(-1.231714002e-07 10 0)
(-3.463895837e-14 10 -1.891196916e-16)
(8.288824915e-08 10 0)
(-4.759729677e-08 10 0)
(-5.577976303e-09 10 2.088050669e-16)
(3.660640857e-08 10 0)
(-7.507386712e-09 10 -2.810307806e-16)
(-1.539641836e-08 10 0)
(1.261886595e-08 10 0)
(-1.449527609e-08 10 0)
(1.554063989e-08 10 2.077669184e-16)
(3.18776916e-09 10 -2.386615189e-16)
(1.318243825e-08 10 -2.741500913e-16)
(-1.766639723e-08 10 0)
(1.932702354e-08 10 0)
(-3.33014194e-08 10 0)
(6.375543737e-08 10 -1.193307603e-16)
(-5.858861751e-08 10 0)
(6.73006717e-08 10 0)
)
;
```
Correct inlet boundaryField for the velocity after the rotation (produced by the `transformPoints` utility):
```
inlet
{
type flowRateInletVelocity;
volumetricFlowRate constant 0.000254;
value uniform (7.07107 7.07107 0);
}
```
### Environment information
- OpenFOAM version : v2106
- Operating system : Ubuntu 20.04.2 LTS
- Hardware info : Intel(R) Core(TM) i7-10510U CPU @ 1.80GHz
- Compiler : gcc 9.3.0
### Possible fixes
This issue can be fixed by constructing the pointer-list of _fvMesh_ objects inside the `rotateMesh` utility before the intermediate operation of points transformation is performed.
This can be achieved by inserting the include file _createNamedMeshes.H_ before the first program loop. The relevant section of the code would read:
```
// ------------------------------------------------------------------------
#include "createNamedMeshes.H"
forAll(regionNames, regioni)
{
const word& regionName = regionNames[regioni];
const word& regionDir =
(
regionName == polyMesh::defaultRegion ? word::null : regionName
);
const fileName meshDir = regionDir/polyMesh::meshSubDir;
if (regionNames.size() > 1)
{
Info<< "region=" << regionName << nl;
}
pointIOField points
(
IOobject
(
"points",
runTime.findInstance(meshDir, "points"),
meshDir,
runTime,
IOobject::MUST_READ,
IOobject::NO_WRITE,
false
)
);
points = transform(rotT, points);
// Set the precision of the points data to 10
IOstream::defaultPrecision(max(10u, IOstream::defaultPrecision()));
Info<< "Writing points into directory "
<< runTime.relativePath(points.path()) << nl
<< endl;
points.write();
}
instantList timeDirs = timeSelector::select0(runTime, args);
forAll(timeDirs, timei)
{
// ...
}
```
Find attached the rotateMesh.C C++ file with the proposed code, that patches this specific bug.
[rotateMesh.C](/uploads/209af5cd64f57ae5cf3d4582981a13e2/rotateMesh.C)
PS: I personally consider this solution to be naive and somewhat simplistic, where a more elegant and robust one would reorganise the `rotateMesh` algorithm to match the order of operations in the `transformPoints` utility (points transformation -> mesh objects construction -> fields rotation -> mesh writing). However, I could not find an example case in which the simple solution suggested above fails.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/2188useImplicit and radiation models lead to divergence.2021-10-27T21:12:21ZJiaming LiuuseImplicit and radiation models lead to divergence.If the multiregion heat transfer calculation uses useImplicit with the fvDOM radiation model, the calculation will diverge. If the radiation model calculation is turned off there is no problem and converges normally.If the multiregion heat transfer calculation uses useImplicit with the fvDOM radiation model, the calculation will diverge. If the radiation model calculation is turned off there is no problem and converges normally.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/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/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/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/2193createPatch does not check for repatching same face twice2021-09-07T09:21:31ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comcreatePatch does not check for repatching same face twice### Functionality to add/problem to solve
createPatch can create patches from selections of boundary faces (either from faceSets or existing patches). However it does not check that faces are present in more than one selection. Currentl...### Functionality to add/problem to solve
createPatch can create patches from selections of boundary faces (either from faceSets or existing patches). However it does not check that faces are present in more than one selection. Currently the 'last one wins' but it would be nice to have proper checks.
### Proposal
Error if selections overlap.Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/2194iglooWithFridges tutorial set-up2021-12-10T15:24:19ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comiglooWithFridges tutorial set-up<!--
*** 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 -->
heatTransfer/buoyantBoussinesqSimpleFoam/iglooWithFridges tutorial contains commented out code to run in parallel with collated file format. This does not run.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Set 'parallel true' at top of script.
### What is the current *bug* behaviour?
<!-- What actually happens -->
- wrong directory ('processors' instead of 'processors2')
- reconstructParMesh run without -fileHandler collated
### 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 : v2106Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/2195IOobject : add relative path function2021-10-01T15:36:47ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comIOobject : add relative path function### Functionality to add/problem to solve
IOobject has objectPath() to obtain the complete path. It would be nice to have a relative (to the <case>) path, especially for warning/error messages.### Functionality to add/problem to solve
IOobject has objectPath() to obtain the complete path. It would be nice to have a relative (to the <case>) path, especially for warning/error messages.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2196bad distributed roots specification causes odd error2021-12-01T17:49:25ZMark OLESENbad distributed roots specification causes odd errorReported in EP1660, if decomposeParDict has distributed true, but has an empty `roots ()` entry, we get very odd error messages.
@martin.wertherReported in EP1660, if decomposeParDict has distributed true, but has an empty `roots ()` entry, we get very odd error messages.
@martin.wertherMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2197aarch64/debian package/docker image OF21062021-09-10T12:00:23ZGiuseppe Giaquintoaarch64/debian package/docker image OF2106### Functionality to add/problem to solve
Some day ago I build a docker image for linux/arm64 for my M1 mac, but it was a real pain because there are no debian packages with precompiled binaries so I would ask if it was possible to add ...### Functionality to add/problem to solve
Some day ago I build a docker image for linux/arm64 for my M1 mac, but it was a real pain because there are no debian packages with precompiled binaries so I would ask if it was possible to add such debian package and make an official docker image for arm64.
### Links / references
[my docker images](https://hub.docker.com/repository/docker/giuseppegq20/openfoam2106)Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2198Sloshing2D tutorial crashing in openfoam20122021-10-27T21:15:35ZBart VermeulenSloshing2D tutorial crashing in openfoam2012<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be re...<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be rendered on the platform by using the
"preview" tab above
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
The sloshing2D tutorial case is crashing with a floating point exception.
### Steps to reproduce
Run the sloshing2D tutorial case.
### Example case
See the sloshing2D case included in the openfoam2012 release, located at tutorials/incompressible/pimpleFoam/laminar/sloshing2D
### What is the current *bug* behaviour?
Run crashes with floating point exception. When run in the 2006 version the tutorial runs with no issue.
### What is the expected *correct* behavior?
Tutorial is expected to run with no issue.
### Relevant logs and/or images
tail of output of pimpleFoam
```
Courant Number mean: 0.0219597 max: 1.05238
Time = 0.48
PIMPLE: iteration 1
Maximal capillary Courant number: 4.01058
Free surface curvature: min = -0.103997, max = 0.0975977, average = -3.99992e-05
Free surface continuity error : sum local = 0.0197539, global = 1.75478e-11
DICPCG: Solving for cellMotionUx, Initial residual = 0, Final residual = 0, No Iterations 0
DICPCG: Solving for cellMotionUy, Initial residual = 0.457312, Final residual = 5.64373e-09, No Iterations 48
smoothSolver: Solving for Ux, Initial residual = 0.0427553, Final residual = 1.82027e-10, No Iterations 3
smoothSolver: Solving for Uy, Initial residual = 0.0483463, Final residual = 8.64354e-11, No Iterations 3
GAMG: Solving for p, Initial residual = 0.208065, Final residual = 8.26681e-09, No Iterations 21
time step continuity errors : sum local = 8.53615e-12, global = -3.40791e-12, cumulative = -1.51755e-10
GAMG: Solving for p, Initial residual = 0.0254321, Final residual = 7.7193e-09, No Iterations 16
time step continuity errors : sum local = 9.91592e-12, global = 4.01099e-12, cumulative = -1.47744e-10
GAMG: Solving for p, Initial residual = 0.00370436, Final residual = 4.97571e-09, No Iterations 16
time step continuity errors : sum local = 6.30442e-12, global = -2.5717e-12, cumulative = -1.50316e-10
PIMPLE: iteration 2
Free surface continuity error : sum local = 0.0314803, global = 7.36567e-10
DICPCG: Solving for cellMotionUx, Initial residual = 0, Final residual = 0, No Iterations 0
DICPCG: Solving for cellMotionUy, Initial residual = 0.74463, Final residual = 9.73061e-09, No Iterations 49
smoothSolver: Solving for Ux, Initial residual = 0.017863, Final residual = 1.36831e-10, No Iterations 4
smoothSolver: Solving for Uy, Initial residual = 0.0240514, Final residual = 2.23125e-10, No Iterations 4
GAMG: Solving for p, Initial residual = 0.129237, Final residual = 9.01299e-09, No Iterations 21
time step continuity errors : sum local = 9.515e-12, global = 3.51329e-12, cumulative = -1.46802e-10
GAMG: Solving for p, Initial residual = 0.0444841, Final residual = 9.74374e-09, No Iterations 18
time step continuity errors : sum local = 7.47935e-12, global = -2.77065e-12, cumulative = -1.49573e-10
GAMG: Solving for p, Initial residual = 0.00602138, Final residual = 7.04264e-09, No Iterations 16
time step continuity errors : sum local = 5.44304e-12, global = 2.03037e-12, cumulative = -1.47543e-10
PIMPLE: iteration 3
Free surface continuity error : sum local = 0.0307808, global = 7.89252e-10
DICPCG: Solving for cellMotionUx, Initial residual = 0, Final residual = 0, No Iterations 0
DICPCG: Solving for cellMotionUy, Initial residual = 0.827931, Final residual = 6.51922e-09, No Iterations 49
smoothSolver: Solving for Ux, Initial residual = 0.00918507, Final residual = 1.91392e-10, No Iterations 4
smoothSolver: Solving for Uy, Initial residual = 0.011106, Final residual = 1.70839e-10, No Iterations 4
GAMG: Solving for p, Initial residual = 0.188214, Final residual = 5.6468e-09, No Iterations 21
time step continuity errors : sum local = 5.19288e-12, global = 3.17129e-12, cumulative = -1.44371e-10
GAMG: Solving for p, Initial residual = 0.0291086, Final residual = 8.36559e-09, No Iterations 16
time step continuity errors : sum local = 8.81108e-12, global = -5.34691e-12, cumulative = -1.49718e-10
GAMG: Solving for p, Initial residual = 0.00488945, Final residual = 7.43674e-09, No Iterations 15
time step continuity errors : sum local = 7.90801e-12, global = 4.81474e-12, cumulative = -1.44903e-10
PIMPLE: iteration 4
Free surface continuity error : sum local = 0.00477103, global = 4.35966e-11
DICPCG: Solving for cellMotionUx, Initial residual = 0, Final residual = 0, No Iterations 0
DICPCG: Solving for cellMotionUy, Initial residual = 0.0896289, Final residual = 6.78209e-09, No Iterations 47
smoothSolver: Solving for Ux, Initial residual = 0.00788484, Final residual = 2.09289e-12, No Iterations 3
smoothSolver: Solving for Uy, Initial residual = 0.00482004, Final residual = 1.00621e-12, No Iterations 3
GAMG: Solving for p, Initial residual = 0.149903, Final residual = 7.07337e-09, No Iterations 18
time step continuity errors : sum local = 1.05058e-11, global = 6.34139e-12, cumulative = -1.38562e-10
GAMG: Solving for p, Initial residual = 0.027082, Final residual = 8.70494e-09, No Iterations 16
time step continuity errors : sum local = 1.45241e-11, global = 8.70469e-12, cumulative = -1.29857e-10
GAMG: Solving for p, Initial residual = 0.00467499, Final residual = 8.92156e-09, No Iterations 13
time step continuity errors : sum local = 1.51271e-11, global = -9.2286e-12, cumulative = -1.39086e-10
PIMPLE: iteration 5
Free surface continuity error : sum local = 0.0287436, global = -8.29794e-10
DICPCG: Solving for cellMotionUx, Initial residual = 0, Final residual = 0, No Iterations 0
DICPCG: Solving for cellMotionUy, Initial residual = 0.551951, Final residual = 7.17263e-09, No Iterations 51
smoothSolver: Solving for Ux, Initial residual = 0.0113926, Final residual = 4.32554e-10, No Iterations 5
smoothSolver: Solving for Uy, Initial residual = 0.0139625, Final residual = 1.39168e-10, No Iterations 7
GAMG: Solving for p, Initial residual = 0.0598591, Final residual = 4.9069e-09, No Iterations 20
time step continuity errors : sum local = 7.71824e-12, global = -4.4745e-12, cumulative = -1.4356e-10
GAMG: Solving for p, Initial residual = 0.0327082, Final residual = 5.9765e-09, No Iterations 16
time step continuity errors : sum local = 9.03766e-12, global = 5.26532e-12, cumulative = -1.38295e-10
GAMG: Solving for p, Initial residual = 0.0268987, Final residual = 8.39761e-09, No Iterations 15
time step continuity errors : sum local = 1.28788e-11, global = -7.44382e-12, cumulative = -1.45739e-10
PIMPLE: iteration 6
Free surface continuity error : sum local = 0.0346845, global = -7.9425e-10
DICPCG: Solving for cellMotionUx, Initial residual = 0, Final residual = 0, No Iterations 0
DICPCG: Solving for cellMotionUy, Initial residual = 0.809593, Final residual = 7.7121e-09, No Iterations 52
smoothSolver: Solving for Ux, Initial residual = 0.0133566, Final residual = 8.67802e-10, No Iterations 17
smoothSolver: Solving for Uy, Initial residual = 0.0189276, Final residual = 5.5088e-10, No Iterations 17
GAMG: Solving for p, Initial residual = 0.315144, Final residual = 5.3234e-09, No Iterations 6
time step continuity errors : sum local = 15973, global = -27168.6, cumulative = -27168.6
GAMG: Solving for p, Initial residual = 0.00485725, Final residual = 6.75073e-09, No Iterations 17
time step continuity errors : sum local = 42937.3, global = 26776.7, cumulative = -391.905
GAMG: Solving for p, Initial residual = 2.02096e-15, Final residual = 2.02096e-15, No Iterations 0
time step continuity errors : sum local = 4.27168e+10, global = -1.42809e+10, cumulative = -1.42809e+10
PIMPLE: iteration 7
Free surface continuity error : sum local = 8.3222e+10, global = -7.14045e+10
DICPCG: Solving for cellMotionUx, Initial residual = 0, Final residual = 0, No Iterations 0
DICPCG: Solving for cellMotionUy, Initial residual = 1, Final residual = 7.14591e-09, No Iterations 52
smoothSolver: Solving for Ux, Initial residual = 0.70222, Final residual = 2.92166e-10, No Iterations 15
smoothSolver: Solving for Uy, Initial residual = 0.604349, Final residual = 5.74197e-10, No Iterations 13
#0 Foam::error::printStack(Foam::Ostream&) at ??:?
#1 Foam::sigFpe::sigHandler(int) at ??:?
#2 ? in /lib/x86_64-linux-gnu/libpthread.so.0
#3 Foam::GAMGSolver::scale(Foam::Field<double>&, Foam::Field<double>&, Foam::lduMatrix const&, Foam::FieldField<Foam::Field, double> const&, Foam::UPtrList<Foam::lduInterfaceField const> const&, Foam::Field<double> const&, unsigned char) const at ??:?
#4 Foam::GAMGSolver::Vcycle(Foam::PtrList<Foam::lduMatrix::smoother> const&, Foam::Field<double>&, Foam::Field<double> const&, Foam::Field<double>&, Foam::Field<double>&, Foam::Field<double>&, Foam::Field<double>&, Foam::Field<double>&, Foam::PtrList<Foam::Field<double> >&, Foam::PtrList<Foam::Field<double> >&, unsigned char) const at ??:?
#5 Foam::GAMGSolver::solve(Foam::Field<double>&, Foam::Field<double> const&, unsigned char) const at ??:?
#6 Foam::fvMatrix<double>::solveSegregated(Foam::dictionary const&) at ??:?
#7 Foam::fvMatrix<double>::solveSegregatedOrCoupled(Foam::dictionary const&) at ??:?
#8 Foam::fvMesh::solve(Foam::fvMatrix<double>&, Foam::dictionary const&) const at ??:?
#9 ? in ~/OpenFOAM/OpenFOAM-v2012/platforms/linux64GccDPInt32Opt/bin/pimpleFoam
#10 __libc_start_main in /lib/x86_64-linux-gnu/libc.so.6
#11 ? in ~/OpenFOAM/OpenFOAM-v2012/platforms/linux64GccDPInt32Opt/bin/pimpleFoam
Floating point exception (core dumped)
```
### 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
- Hardware info :Intel(R) Core(TM) i5-8265U CPU @ 1.60GHz
- 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
-->Kutalmış BerçinKutalmış Berçin