Development issueshttps://develop.openfoam.com/groups/Development/-/issues2021-09-09T15:48:19Zhttps://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
-->https://develop.openfoam.com/Development/openfoam/-/issues/2174Possibly wrong online documentation for omegaWallFunction2021-11-01T12:30:40ZGabriel SantosPossibly wrong online documentation for omegaWallFunctionThe [omegaWallFunction](https://www.openfoam.com/documentation/guides/latest/doc/guide-bcs-wall-turbulence-omegaWallFunction.html) entry in the User Guide states that the `blinding stepwise;` is used by default. However, in [omegaWallFun...The [omegaWallFunction](https://www.openfoam.com/documentation/guides/latest/doc/guide-bcs-wall-turbulence-omegaWallFunction.html) entry in the User Guide states that the `blinding stepwise;` is used by default. However, in [omegaWallFunctionFvPatchScalarField.H](https://www.openfoam.com/documentation/guides/latest/api/omegaWallFunctionFvPatchScalarField_8H_source.html#l00239) the code actually adopts `blending binomial2;` by default.
Perhaps this should be corrected in the online documentation.Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2164Simulation hangs when sampling sets of type face.2021-12-20T12:18:01ZTom LauriksSimulation hangs when sampling sets of type face.I have an LES of a half open channel (empty atmospheric boundary layer). The domain is a cuboid. The mesh is built with blockMesh, without grading, and the cells are nearly uniform. I use the pimpleFoam solver. I'm using openfoam v2012. ...I have an LES of a half open channel (empty atmospheric boundary layer). The domain is a cuboid. The mesh is built with blockMesh, without grading, and the cells are nearly uniform. I use the pimpleFoam solver. I'm using openfoam v2012.
I'm trying to sample on a line in my domain, running from one side to the opposing side, somewhere though the middle of my domain and parallel with one of the coordinate axes. I'm using sets from libsampling.so. I'm trying to use the type face, which should sample at intersections of the specified line and mesh cell faces. As my mesh cells are evenly spaced, this is very convenient.
I've noticed that my simulation sometimes hangs and sometimes not. By hanging I mean, that the log file from calling pimpleFoam > log is created, and that the simulation doesn't stop, but simply gets stuck at a certain line in the log file. E.g. during the last simulation where I had this problem, the simulation stopped at the line containing "outlet":
```
Creating finite volume options from "constant/fvOptions"
No finite volume options present
Courant Number mean: 0.001365 max: 0.0013832
fieldAverage fieldAverage1:
Restarting averaging for fields:
U: starting averaging at time 0
turbulenceFields turbulenceFields1: storing fields:
turbulenceProperties:R
Reading set description:
buildings
inlet
outlet
```
I've furthermore noticed that when I adjust one of the coordinates of the line, then the simulation sometimes doesn't hang anymore and sometimes it still hangs.
This seems like a bug in the sampling application.https://develop.openfoam.com/Development/openfoam/-/issues/2161Potential wrong behavior of particles in MPPICInterFoam when using MRF2021-12-17T14:59:00ZRiccardo RossiPotential wrong behavior of particles in MPPICInterFoam when using MRFI'm opening this ticket as a follow up to #1941 after running the same test with MPPICInterFoam as requested by @Sergio.
As you can see from the two video attached, the standard MPPICInterFoam solver behaves essentially in the same way ...I'm opening this ticket as a follow up to #1941 after running the same test with MPPICInterFoam as requested by @Sergio.
As you can see from the two video attached, the standard MPPICInterFoam solver behaves essentially in the same way as my custom solver, i.e. water phase is convected by relative velocity in the MRF region of the standard mixerVessel tutorial used here whereas the particles are not.
If one switches to drag force given by relative velocity in the MRF region as I did in my modified custom solver, then the particles behaves correctly when looking at the reference AMI based simulation, where the MRF region is replaced by the actually moving mesh.
Looking forward to hearing your thoughts.
[mixerVesselWater.avi](/uploads/af4eb236f4797d81f9ba941b91bd1587/mixerVesselWater.avi)
[mixerVesselParticles.wmv](/uploads/5a00e673f191b794fe67d1d0c6cca1b0/mixerVesselParticles.wmv)https://develop.openfoam.com/Development/openfoam/-/issues/2156waveMethod called from inverseDistanceCellCellStencil returns error for empty...2021-11-19T15:20:54ZLouiswaveMethod called from inverseDistanceCellCellStencil returns error for empty source processors
### Summary
inverseDistanceCellCellStencil calls waveMethod::calculate(tgtMesh, srcMesh, tgtToSrcAddr) which then calls
FaceCellWave<meshToMeshData, meshToMeshData::trackData> calc
(
src,
...
### Summary
inverseDistanceCellCellStencil calls waveMethod::calculate(tgtMesh, srcMesh, tgtToSrcAddr) which then calls
FaceCellWave<meshToMeshData, meshToMeshData::trackData> calc
(
src,
changedFaces,
changedFacesInfo,
faceData,
cellData,
src.globalData().nTotalCells(), // max iterations
td
);
which will return an error when src.globalData().nTotalCells() is 0.
A solution is to add 1 (works for me) or maybe, more logical, make a max(1,src.globalData().nTotalCells())
### What is the current *bug* behaviour?
returns error
> Maximum number of iterations reached. Increase maxIter.
### What is the expected *correct* behavior?
overset runs
### Environment information
I think hierarchical is particularly sensible to this issue.
### Possible fixes
mentioned above
PS: I'm not sure I can get this error for the "standard" code, as I haven't tested if empty src is possible. I'm using a modified B-box inverseDistance scheme...Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/2150Feature: CFL number2021-07-06T11:17:28ZPrashant SonakarFeature: CFL numberIt is useful to analyze CFL number for compressible cases which takes acoustic speed into account.
@andyIt is useful to analyze CFL number for compressible cases which takes acoustic speed into account.
@andyhttps://develop.openfoam.com/Development/openfoam/-/issues/2141Add support for user defined liquidProperties2021-12-10T13:12:14ZDanielAdd support for user defined liquidProperties### Functionality to add/problem to solve
Currently only hardcoded liquids can be used for modeling Lagrangian particles such as water and a few selected hydrocarbons.
This limits the possibility of modeling liquid injection for cases o...### Functionality to add/problem to solve
Currently only hardcoded liquids can be used for modeling Lagrangian particles such as water and a few selected hydrocarbons.
This limits the possibility of modeling liquid injection for cases other than liquid fuel combustion.
### Target audience
Users who want to model injecting ammonia for nitric oxide reduction.
### Proposal
Implement similar functionality to what is available through generic [liquid](https://github.com/OpenFOAM/OpenFOAM-dev/tree/master/src/thermophysicalModels/thermophysicalProperties/liquidProperties/liquid).
### Funding
I already have a working implementation and can provide the patch/merge reguest.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2136cyclic patch - decomposition issue2021-06-22T17:40:52ZPrashant Sonakarcyclic patch - decomposition issueRun Attached case and compare checkMesh output logs in serial and parallel. The cyclic faces coincide with processor boundary and are not seen in parallel mesh.[cyclic-face-common-with-processor.tgz](/uploads/aa4e94fa5becc268f5ab45fbfa7c...Run Attached case and compare checkMesh output logs in serial and parallel. The cyclic faces coincide with processor boundary and are not seen in parallel mesh.[cyclic-face-common-with-processor.tgz](/uploads/aa4e94fa5becc268f5ab45fbfa7ca21e/cyclic-face-common-with-processor.tgz)https://develop.openfoam.com/Development/openfoam/-/issues/2131refineFieldDirs tutorial produces warnings at iter62021-12-13T17:37:24ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comrefineFieldDirs tutorial produces warnings at iter6<!--
*** 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 -->
From iter5 to iter6 the refineMesh stars complaining
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
```tutorials/mesh/refineMesh/refineFieldDirs```
Run step by step (remove the -overwrite). Going from 5 to 6 it will complain:
```
cellCuts : constructor from cellCutter
--> FOAM Warning :
From void Foam::cellCuts::setFromCellCutter(const Foam::cellLooper &, const List<Foam::refineCell> &)
in file meshCut/cellCuts/cellCuts.C at line 2435
Found loop on cell 1 that resulted in an unexpected bad cut.
Suggestions:
- Turn on the debug switch for 'cellCuts' to get geometry files that identify this cell.
- Also keep in mind to check the defined reference directions, as these are most likely the origin of the problem.
```
Switch on debug for more info
```
DebugSwitches
{
cellCuts 2;
}
```
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v1806|v1812|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2106
### Possible fixes
Since topo is not very complex and the cuts are still made ok maybe it is just a geometric tolerance?Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/2128volFieldValue produces empty lines2021-06-17T16:13:39ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comvolFieldValue produces empty lines### Functionality to add/problem to solve
`volFieldValue::read` prints a newline when it does a read (even though it prints nothing else). This produces unnecessary empty lines at startup.
Run e.g.
`incompressible/pisoFoam/RAS/cavity`
...### Functionality to add/problem to solve
`volFieldValue::read` prints a newline when it does a read (even though it prints nothing else). This produces unnecessary empty lines at startup.
Run e.g.
`incompressible/pisoFoam/RAS/cavity`
and there will be about 20 empty lines from the FOvolFieldValue use of volFieldValue in various permutations.
### Proposal
volFieldValue::read, surfaceFieldValue::read : do not output a line if nothing else has been printed. Or always output at least something?Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2123Illegal Operand when OpenFoam is compiled with GCC2021-06-23T14:45:57ZGeorge FrickeIllegal Operand when OpenFoam is compiled with GCC### Summary
I am compiling OpenFoam 2012 for the users of our Centos7 HPC systems using the spack recipe.
When I compile using Intel 19.1.1 everything runs as expected using the cavity tutorial as a test.
When I compile with gcc (I'v...### Summary
I am compiling OpenFoam 2012 for the users of our Centos7 HPC systems using the spack recipe.
When I compile using Intel 19.1.1 everything runs as expected using the cavity tutorial as a test.
When I compile with gcc (I've tried 6.4 and 10.2) everything seems to work except when called with mpirun and --parallel. I have tried version 2012 and the current devel branch. The proximate error is "Illegal Operand" see below for the error stack.
Compiling OpenFoam-org version 7 with gcc 10.2.0 works with mpirun. One of our users has a particular need to use gcc and OpenFoam to write an extension.
### Steps to reproduce
```
spack install openfoam%gcc@10.2
module load openfoam-develop-gcc-10.2.0-mkl-6r7rrzb
cd cavity
blockMesh
decomposePar
mpirun -np 2 -machinefile $PBS_NODEFILE icoFoam -parallel # Assuming a PBS allocated node
```
### What is the current *bug* behaviour?
```
[wheeler100:30014:0:30014] Caught signal 4 (Illegal instruction: illegal operand)
==== backtrace ====
[wheeler100:30013:0:30013] Caught signal 4 (Illegal instruction: illegal operand)
```
### Relevant logs and/or images
```
mfricke@wheeler100:~/test_programs/OpenFoam/cavity $ mpirun -np 2 -machinefile $PBS_NODEFILE icoFoam -parallel
[wheeler100:30014:0:30014] Caught signal 4 (Illegal instruction: illegal operand)
==== backtrace ====
[wheeler100:30013:0:30013] Caught signal 4 (Illegal instruction: illegal operand)
==== backtrace ====
0 /usr/lib64/libucs.so.0(+0x17970) [0x2aef18126970]
1 /usr/lib64/libucs.so.0(+0x179f3) [0x2aef181269f3]
2 /opt/spack/opt/spack/linux-centos7-nehalem/gcc-10.2.0/libfabric-1.12.1-bgj3y4nzp2uuvkohviyxf5i5dit4ufzy/lib/libfabric.so.1(+0x7f29f) [0x2aee4a7ef29f]
3 /opt/spack/opt/spack/linux-centos7-nehalem/gcc-10.2.0/libfabric-1.12.1-bgj3y4nzp2uuvkohviyxf5i5dit4ufzy/lib/libfabric.so.1(+0x11c45) [0x2aee4a781c45]
4 /opt/spack/opt/spack/linux-centos7-nehalem/gcc-10.2.0/libfabric-1.12.1-bgj3y4nzp2uuvkohviyxf5i5dit4ufzy/lib/libfabric.so.1(fi_getinfo+0x70d) [0x2aee4a78260d]
5 /opt/spack/opt/spack/linux-centos7-nehalem/gcc-10.2.0/libfabric-1.12.1-bgj3y4nzp2uuvkohviyxf5i5dit4ufzy/lib/libfabric.so.1(fi_getinfo+0x4c) [0x2aee4a786efc]
6 /opt/intel/compilers_and_libraries_2020.1.217/linux/mpi/intel64/lib/debug/libmpi.so.12(+0x872452) [0x2aee48fb2452]
7 /opt/intel/compilers_and_libraries_2020.1.217/linux/mpi/intel64/lib/debug/libmpi.so.12(+0x242b6e) [0x2aee48982b6e]
8 /opt/intel/compilers_and_libraries_2020.1.217/linux/mpi/intel64/lib/debug/libmpi.so.12(+0x579bd5) [0x2aee48cb9bd5]
9 /opt/intel/compilers_and_libraries_2020.1.217/linux/mpi/intel64/lib/debug/libmpi.so.12(PMPI_Init_thread+0x10b) [0x2aee48cba1d1]
10 /opt/spack/opt/spack/linux-centos7-nehalem/gcc-10.2.0/openfoam-develop-6r7rrzbjrqxjejo6stnxarlrcwrsncr3/platforms/linux64GccDPInt32-spack/lib/libPstream.so(_ZN4Foam8UPstream4initERiRPPcb+0x82) [0x2aee47b6c3b2]
11 /opt/spack/opt/spack/linux-centos7-nehalem/gcc-10.2.0/openfoam-develop-6r7rrzbjrqxjejo6stnxarlrcwrsncr3/platforms/linux64GccDPInt32-spack/lib/libOpenFOAM.so(_ZN4Foam7argListC1ERiRPPcbbb+0x767) [0x2aee460cc907]
12 icoFoam() [0x42244d]
13 /lib64/libc.so.6(__libc_start_main+0xf5) [0x2aee477b2555]
14 icoFoam() [0x426ac7]
===================
0 /usr/lib64/libucs.so.0(+0x17970) [0x2ab44ffa2970]
1 /usr/lib64/libucs.so.0(+0x179f3) [0x2ab44ffa29f3]
2 /opt/spack/opt/spack/linux-centos7-nehalem/gcc-10.2.0/libfabric-1.12.1-bgj3y4nzp2uuvkohviyxf5i5dit4ufzy/lib/libfabric.so.1(+0x7f29f) [0x2ab38266b29f]
3 /opt/spack/opt/spack/linux-centos7-nehalem/gcc-10.2.0/libfabric-1.12.1-bgj3y4nzp2uuvkohviyxf5i5dit4ufzy/lib/libfabric.so.1(+0x11c45) [0x2ab3825fdc45]
4 /opt/spack/opt/spack/linux-centos7-nehalem/gcc-10.2.0/libfabric-1.12.1-bgj3y4nzp2uuvkohviyxf5i5dit4ufzy/lib/libfabric.so.1(fi_getinfo+0x70d) [0x2ab3825fe60d]
5 /opt/spack/opt/spack/linux-centos7-nehalem/gcc-10.2.0/libfabric-1.12.1-bgj3y4nzp2uuvkohviyxf5i5dit4ufzy/lib/libfabric.so.1(fi_getinfo+0x4c) [0x2ab382602efc]
6 /opt/intel/compilers_and_libraries_2020.1.217/linux/mpi/intel64/lib/debug/libmpi.so.12(+0x872452) [0x2ab380e2e452]
7 /opt/intel/compilers_and_libraries_2020.1.217/linux/mpi/intel64/lib/debug/libmpi.so.12(+0x242b6e) [0x2ab3807feb6e]
8 /opt/intel/compilers_and_libraries_2020.1.217/linux/mpi/intel64/lib/debug/libmpi.so.12(+0x579bd5) [0x2ab380b35bd5]
9 /opt/intel/compilers_and_libraries_2020.1.217/linux/mpi/intel64/lib/debug/libmpi.so.12(PMPI_Init_thread+0x10b) [0x2ab380b361d1]
10 /opt/spack/opt/spack/linux-centos7-nehalem/gcc-10.2.0/openfoam-develop-6r7rrzbjrqxjejo6stnxarlrcwrsncr3/platforms/linux64GccDPInt32-spack/lib/libPstream.so(_ZN4Foam8UPstream4initERiRPPcb+0x82) [0x2ab37f9e83b2]
11 /opt/spack/opt/spack/linux-centos7-nehalem/gcc-10.2.0/openfoam-develop-6r7rrzbjrqxjejo6stnxarlrcwrsncr3/platforms/linux64GccDPInt32-spack/lib/libOpenFOAM.so(_ZN4Foam7argListC1ERiRPPcbbb+0x767) [0x2ab37df48907]
12 icoFoam() [0x42244d]
13 /lib64/libc.so.6(__libc_start_main+0xf5) [0x2ab37f62e555]
14 icoFoam() [0x426ac7]
===================
Here is the concretization from spack showing all the dependency versions:
mfricke@wheeler-sn:~/test_programs/OpenFoam/cavity $ spack spec openfoam
Input spec
--------------------------------
openfoam
Concretized
--------------------------------
openfoam@2012%gcc@10.2.0~float32~int64~kahip~knl~metis~mgridgen~paraview+scotch+source~spdp~vtk~zoltan arch=linux-centos7-nehalem
^adios2@2.7.1%gcc@10.2.0+blosc+bzip2~dataman~dataspaces~endian_reverse+fortran~hdf5~ipo+mpi+pic+png~python+shared+ssc+sst+sz+zfp build_type=Release arch=linux-centos7-nehalem
^bzip2@1.0.8%gcc@10.2.0~debug~pic+shared arch=linux-centos7-nehalem
^diffutils@3.7%gcc@10.2.0 arch=linux-centos7-nehalem
^libiconv@1.16%gcc@10.2.0 arch=linux-centos7-nehalem
^c-blosc@1.21.0%gcc@10.2.0+avx2~ipo build_type=RelWithDebInfo arch=linux-centos7-nehalem
^cmake@3.20.2%gcc@10.2.0~doc+ncurses+openssl+ownlibs~qt build_type=Release arch=linux-centos7-nehalem
^ncurses@6.2%gcc@10.2.0~symlinks+termlib abi=none arch=linux-centos7-nehalem
^pkg-config@0.29.2%gcc@10.2.0+internal_glib arch=linux-centos7-nehalem
^openssl@1.1.1k%gcc@10.2.0~docs+systemcerts arch=linux-centos7-nehalem
^perl@5.32.1%gcc@10.2.0+cpanm+shared+threads arch=linux-centos7-nehalem
^berkeley-db@18.1.40%gcc@10.2.0+cxx~docs+stl patches=b231fcc4d5cff05e5c3a4814f6a5af0e9a966428dc2176540d2c05aff41de522 arch=linux-centos7-nehalem
^gdbm@1.19%gcc@10.2.0 arch=linux-centos7-nehalem
^readline@8.1%gcc@10.2.0 arch=linux-centos7-nehalem
^zlib@1.2.11%gcc@10.2.0+optimize+pic+shared arch=linux-centos7-nehalem
^lz4@1.9.3%gcc@10.2.0 libs=shared,static arch=linux-centos7-nehalem
^snappy@1.1.8%gcc@10.2.0~ipo+pic+shared build_type=RelWithDebInfo patches=c9cfecb1f7a623418590cf4e00ae7d308d1c3faeb15046c2e5090e38221da7cd arch=linux-centos7-nehalem
^zstd@1.4.9%gcc@10.2.0~ipo~legacy~lz4~lzma+multithread+programs+shared+static~zlib build_type=RelWithDebInfo arch=linux-centos7-nehalem
^intel-mpi@2019.7.217%gcc@10.2.0 arch=linux-centos7-nehalem
^libfabric@1.12.1%gcc@10.2.0~kdreg fabrics=sockets,tcp,udp arch=linux-centos7-nehalem
^libffi@3.3%gcc@10.2.0 patches=26f26c6f29a7ce9bf370ad3ab2610f99365b4bdd7b82e7c31df41a3370d685c0 arch=linux-centos7-nehalem
^libpng@1.6.37%gcc@10.2.0 arch=linux-centos7-nehalem
^sz@2.1.11.1%gcc@10.2.0~fortran~hdf5~ipo~netcdf~pastri~python~random_access+shared~stats~time_compression build_type=RelWithDebInfo arch=linux-centos7-nehalem
^zfp@0.5.5%gcc@10.2.0~aligned~c~cuda~fasthash~fortran~ipo~openmp~profile~python+shared~strided~twoway bsws=64 build_type=RelWithDebInfo cuda_arch=none arch=linux-centos7-nehalem
^boost@1.76.0%gcc@10.2.0+atomic+chrono~clanglibcpp~container~context~coroutine+date_time~debug+exception~fiber+filesystem+graph~icu+iostreams+locale+log+math~mpi+multithreaded~numpy~pic+program_options~python+random+regex+serialization+shared+signals~singlethreaded+system~taggedlayout+test+thread+timer~versionedlayout+wave cxxstd=98 visibility=hidden arch=linux-centos7-nehalem
^cgal@4.13%gcc@10.2.0~core~demos+eigen~header_only~imageio~ipo+shared build_type=Release arch=linux-centos7-nehalem
^eigen@3.3.9%gcc@10.2.0~ipo build_type=RelWithDebInfo arch=linux-centos7-nehalem
^gmp@6.2.1%gcc@10.2.0 arch=linux-centos7-nehalem
^autoconf@2.69%gcc@10.2.0 arch=linux-centos7-nehalem
^m4@1.4.18%gcc@10.2.0+sigsegv patches=3877ab548f88597ab2327a2230ee048d2d07ace1062efe81fc92e91b7f39cd00,fc9b61654a3ba1a8d6cd78ce087e7c96366c290bc8d2c299f09828d793b853c8 arch=linux-centos7-nehalem
^libsigsegv@2.13%gcc@10.2.0 arch=linux-centos7-nehalem
^automake@1.16.3%gcc@10.2.0 arch=linux-centos7-nehalem
^libtool@2.4.6%gcc@10.2.0 arch=linux-centos7-nehalem
^mpfr@4.1.0%gcc@10.2.0 arch=linux-centos7-nehalem
^autoconf-archive@2019.01.06%gcc@10.2.0 arch=linux-centos7-nehalem
^texinfo@6.5%gcc@10.2.0 patches=12f6edb0c6b270b8c8dba2ce17998c580db01182d871ee32b7b6e4129bd1d23a,1732115f651cff98989cb0215d8f64da5e0f7911ebf0c13b064920f088f2ffe1 arch=linux-centos7-nehalem
^flex@2.6.4%gcc@10.2.0+lex~nls patches=09c22e5c6fef327d3e48eb23f0d610dcd3a35ab9207f12e0f875701c677978d3 arch=linux-centos7-nehalem
^bison@3.7.6%gcc@10.2.0 arch=linux-centos7-nehalem
^findutils@4.8.0%gcc@10.2.0 arch=linux-centos7-nehalem
^gettext@0.21%gcc@10.2.0+bzip2+curses+git~libunistring+libxml2+tar+xz arch=linux-centos7-nehalem
^libxml2@2.9.10%gcc@10.2.0~python arch=linux-centos7-nehalem
^xz@5.2.5%gcc@10.2.0~pic libs=shared,static arch=linux-centos7-nehalem
^tar@1.34%gcc@10.2.0 arch=linux-centos7-nehalem
^help2man@1.47.16%gcc@10.2.0 arch=linux-centos7-nehalem
^intel-mkl@2020.1.217%gcc@10.2.0~ilp64+shared threads=none arch=linux-centos7-nehalem
^scotch@6.0.10%gcc@10.2.0+compression~esmumps~int64~metis+mpi+shared arch=linux-centos7-nehalem
```
### Environment information
- OpenFOAM version : 2021 and develop
- Operating system : CentOS Linux release 7.9.2009 (Core)
- Hardware info : Intel(R) Xeon(R) CPU X5550 @ 2.67GHz, 48 GB RAM, Infiniband ConnectX-4
- Compiler : GCC 10.2.0 and GCC 6.4.0
Any help would be appreciated,
Matthew