Development issueshttps://develop.openfoam.com/groups/Development/-/issues2022-08-18T10:37:11Zhttps://develop.openfoam.com/Development/openfoam/-/issues/2545BUG: externalHeatFluxSource: memory leak in addSup2022-08-18T10:37:11ZKutalmış BerçinBUG: externalHeatFluxSource: memory leak in addSup### Summary
The following in `void Foam::fa::externalHeatFluxSource::addSup` is not deallocated:
```
auto tQ = new areaScalarField
(
io,
regionMesh(),
dimensionedScalar("q", dimPower/...### Summary
The following in `void Foam::fa::externalHeatFluxSource::addSup` is not deallocated:
```
auto tQ = new areaScalarField
(
io,
regionMesh(),
dimensionedScalar("q", dimPower/sqr(dimLength), 0),
zeroGradientFaPatchScalarField::typeName
);
areaScalarField& Q = *tQ;
```
### Steps to reproduce
Memory analysis on `buoyantPimpleFoam` with `heatTransfer/buoyantPimpleFoam/hotRoomWithThermalShell`.
### Relevant logs and/or images
```
==14377== LEAK SUMMARY:
==14377== definitely lost: 4,408 bytes in 40 blocks
==14377== indirectly lost: 179,592 bytes in 400 blocks
==14377== possibly lost: 0 bytes in 0 blocks
==14377== still reachable: 0 bytes in 0 blocks
==14377== suppressed: 0 bytes in 0 blocks
==14377==
==14377== ERROR SUMMARY: 3 errors from 3 contexts (suppressed: 0 from 0)
```
### Environment information
5894874920Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2544jouleHeatingSource change file separator2022-07-26T18:31:13ZSergey MatsievskiyjouleHeatingSource change file separator<!--
*** 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
Currently, [`jouleHeatingSource`](https://develop.openfoam.com/Development/openfoam/-/tree/master/src/fvOptions/sources/derived/jouleHeatingSource) uses `:` file separator (e.g. `0/jouleHeatingSource:V`). This is a bad choice because of a special meaning in GNU Make. It prevents creating dependency lists for automated update.
For example, this is a snippet from my Makefile:
```makefile
FIELD_FILES_ORIG:=$(wildcard 0.orig/*)
FIELD_FILES:=$(foreach v,$(FIELD_FILES_ORIG),$(notdir $(v)))
FIELD_FILES_INITIAL:=$(foreach v,$(FIELD_FILES),0/$(v))
FIELD_FILES_INITIAL_REGIONS:=$(foreach v,$(FIELD_FILES),$(foreach r,$(REGIONS),0/$(r)/$(v)))
0/cellToRegion: constant/polyMesh $(FIELD_FILES_INITIAL) | 0
rm -f .changeDictionary
splitMeshRegions -cellZones -overwrite
renumberMesh -allRegions -overwrite
```
This code breaks because of a `:` character in file names.
This problem is trivially solved by replacing `:` file separator with something more Makefile-friendly. For example, `-` character.
If you agree with this, I could create a PR myself.
### Steps to reproduce
Execute code
```bash
git clone https://develop.openfoam.com/Development/openfoam.git --branch master
cd openfoam/tutorials/heatTransfer/chtMultiRegionSimpleFoam/jouleHeatingSolid
cat > Makefile << _EOF_
FILES:=\$(wildcard 0.orig/**/*)
all: \$(FILES)
echo success
_EOF_
make
```
Observe GNU Make error.
Fix file names and try again
```bash
rename 's/:/-/' 0.orig/solid/*
make
```
Observe output string `success`.
### Example case
*See `Steps to reproduce`*
### What is the current *bug* behaviour?
OpenFOAM file names break GNU Make automation
### What is the expected *correct* behavior?
OpenFOAM file names do not break GNU Make automation
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v2206|v2112|v2106|v2012|v2006 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2206
- Operating system : GNU Debian bookworm
- Hardware info : x86-64
- Compiler : gcc
### Possible fixes
I think that it's enough to replace `:` with `-` in
* https://develop.openfoam.com/Development/openfoam/-/blob/master/src/fvOptions/sources/derived/jouleHeatingSource/jouleHeatingSource.C#L47
* https://develop.openfoam.com/Development/openfoam/-/blob/master/src/fvOptions/sources/derived/jouleHeatingSource/jouleHeatingSource.C#L118
* https://develop.openfoam.com/Development/openfoam/-/blob/master/src/fvOptions/sources/derived/jouleHeatingSource/jouleHeatingSourceTemplates.C#L48
* https://develop.openfoam.com/Development/openfoam/-/blob/master/src/fvOptions/sources/derived/jouleHeatingSource/jouleHeatingSourceTemplates.C#L70
* https://develop.openfoam.com/Development/openfoam/-/blob/master/src/fvOptions/sources/derived/jouleHeatingSource/jouleHeatingSourceTemplates.C#L95
and to rename files in https://develop.openfoam.com/Development/openfoam/-/tree/master/tutorials/heatTransfer/chtMultiRegionSimpleFoam/jouleHeatingSolid/0.orig/solidhttps://develop.openfoam.com/Development/openfoam/-/issues/2543BUG: "faSchemes" files misleadingly include the "snGradSchemes" entry2022-07-25T14:10:47ZKutalmış BerçinBUG: "faSchemes" files misleadingly include the "snGradSchemes" entryWhen a finite-area case could not find an entry for "lnGradSchemes" in the "faSchemes" file, the "corrected" scheme has been picked up by default. Therefore, any changes in "snGradSchemes" entry will not be read by finite-area models.
H...When a finite-area case could not find an entry for "lnGradSchemes" in the "faSchemes" file, the "corrected" scheme has been picked up by default. Therefore, any changes in "snGradSchemes" entry will not be read by finite-area models.
However, the standard tutorials misleadingly include "faSchemes" files with the "snGradSchemes" entry instead of the "lnGradSchemes".Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2542Online documentation (user guide) sidebar broken2024-01-10T11:23:42ZChristian RohrOnline documentation (user guide) sidebar broken<!--
*** 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 sidebar in the user guide is no longer functional. It doesn't show the headings or links to pages making it very difficult to find what you need, as you have to guess search terms. It stays collapsed listing only the main page no matter where you navigate or what you search for.
![image](/uploads/c4694e1879bc8c1e15060b9820c3898f/image.png)
### Steps to reproduce
Just go to the online [user guide](https://www.openfoam.com/documentation/guides/latest/doc/index.html) and try to navigate through.
Have reproduced on Edge, Firefox, Chrome.
### What is the expected *correct* behavior?
The sidebar should populate with the document structure as it does for the API guide. It did so up until about 2 weeks ago. Like this:
![image](/uploads/c180e7a6ffee807794506a23dc46dc20/image.png)https://develop.openfoam.com/Development/openfoam/-/issues/2541Limiting the pressure (p or p_rgh) as an fvOption entry rather than having it...2022-07-25T15:44:42ZTobias HolzmannLimiting the pressure (p or p_rgh) as an fvOption entry rather than having it in the fvSolutions file### Functionality to add/problem to solve
For compressible flows it might be beneficial to limit the pressure values to some defined ranges in order to avoid non-physical behavior such as negative pressure or values which will never occ...### Functionality to add/problem to solve
For compressible flows it might be beneficial to limit the pressure values to some defined ranges in order to avoid non-physical behavior such as negative pressure or values which will never occur in the simulation one is performing. E.g., external aerodynamics might have a defined range around the atmospheric pressure value but will never get negative or too high.
We can limit the pressure values by using the pMin and pMax keywords inside the system/fvSolutions subDict (SIMPLE/PIMPLE/PISO) but personally, I would prefer to have some fvOption model that takes care of that such as the limitVelocity or limitTemperature. That would unify the code and we would have everything in one place.
Checking our actual implementation of the pMin and pMax results in the pressureControl class. So its implemented but maybe it would make sense to change it to be used with the fvOptions file?
### Target audience
As we have already an working implementation, probably no-one. However, we would have limitVelocity, limitPressure as well as limitTemperature in one place.
### Proposal
Its already implemented in the .org version.
https://github.com/OpenFOAM/OpenFOAM-dev/tree/master/src/fvConstraints/limitPressure
### What does success look like, and how can we measure that?
Success: Probably having all "limiting" constraints in one file (fvOptions) rather than split into fvSolution and fvOptions.
### Links / references
https://github.com/OpenFOAM/OpenFOAM-dev/commit/ab7d010a9aa91576a93ed7b09bb0f4e607a0fbd8
### Funding
Functionality already exist in the .org version.Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2540valgrind complains about memory leackage in simpleFoam when running in parallel2022-11-17T07:30:47ZVaggelis Papoutsisvalgrind complains about memory leackage in simpleFoam when running in parallelI am trying to hunt down a memory leakage problem within an in-house class that appears when running in parallel but not in serial.
In the process of doing so, I discovered mpirunDebug (there seems to be a nice script for everything yo...I am trying to hunt down a memory leakage problem within an in-house class that appears when running in parallel but not in serial.
In the process of doing so, I discovered mpirunDebug (there seems to be a nice script for everything you need :) )
When executing it however, valgrind reports multiple leakage errors related to UPstream.
I then switched to the pitchDaily case ran with simpleFoam and I get similar errors (case attached case [pitzDaily.tar.gz](/uploads/479cbb9918e45fa42b5f22f76c660261/pitzDaily.tar.gz))
I have tested in the following environments
1)
- OpenFOAM version: v2206
- OS: CentOS Linux release 7.5.1804
- Compiler: gcc (OpenFOAM) 9.3.0
- valgrind: valgrind-3.13.0
- mpi: OpenMPI 1.10.7
Log file from processor0: [processor0_env1.log](/uploads/c712588770fffca4f6b24fe5900a0c01/processor0_env1.log)
2)
- OpenFOAM version: v2206 (binary pack)
- OS: Ubuntu 22.04
- Compiler: gcc (Ubuntu 11.2.0-19ubuntu1) 11.2.0
- valgrind: valgrind-3.18.1
- mpi: OpenMPI 4.1.2
Log file from processor0: [processor0_env2.log](/uploads/56d72025391906fa0087d1bb89c8529b/processor0_env2.log)
As you will see, some errors are common, some exist only in the first environment but all seem to be related to UPStream somehow.
I am assuming these are false positives from valgrind. Any idea what is causing them or how they can be suppressed? They tend to pollute the outcome to a degree that makes tracking the real issue (if any) quite challenging.
Any help is appreciated.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2539Installation, Critical error, gcc and icoFoam not installed2022-07-20T16:16:58ZJaya TharanInstallation, Critical error, gcc and icoFoam not installedHi !
I'm trying to install OPENFOAM-v2206 in Ubuntu. I followed all the required steps. I indeed updated the software using all the lines.
But I'm getting critical error for gcc and icoFoam.
None of the software components are getting ...Hi !
I'm trying to install OPENFOAM-v2206 in Ubuntu. I followed all the required steps. I indeed updated the software using all the lines.
But I'm getting critical error for gcc and icoFoam.
None of the software components are getting recognized.
![Capture](/uploads/8d9f2ca98911c732a926cc0c214e8e2d/Capture.PNG)
I have latest version of gcc and other updates.. Been trying a lot. Please tell what I'm missing.
![Capture](/uploads/22b117212cd73768f0cddb65ef83a8fa/Capture.PNG)https://develop.openfoam.com/Development/openfoam/-/issues/2538BUG: diameterModel: duplicate entry error2022-08-19T09:03:35ZKutalmış BerçinBUG: diameterModel: duplicate entry error### Summary
`./Alltest` on `$FOAM_TUTORIALS/multiphase/twoPhaseEulerFoam/laminar/fluidisedBed` throws a duplicate entry error as follows:
```
Duplicate entry constant in runtime table diameterModel
#0 .../lin...### Summary
`./Alltest` on `$FOAM_TUTORIALS/multiphase/twoPhaseEulerFoam/laminar/fluidisedBed` throws a duplicate entry error as follows:
```
Duplicate entry constant in runtime table diameterModel
#0 .../linux64ClangDPInt32Opt/lib/libOpenFOAM.so(_ZN4Foam5error14safePrintStackERSo+0x2b) [0x7fee94eb627b]
#1 .../linux64ClangDPInt32Opt/lib/libcompressibleTwoPhaseSystem.so(_ZN4Foam13diameterModel31adddictionaryConstructorToTableINS_14diameterModels8constantEEC2ERKNS_4wordE+0xe4) [0x7fee95761e14]
#2 .../linux64ClangDPInt32Opt/lib/libreactingMultiphaseSystem.so(+0x25981f) [0x7fee89fe781f]
```
### Environment information
8b1514c99b-20220711Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2537Problem with snappyHexMesh when OpenFOAM is compiled using FMA-Instructions2022-09-28T14:12:02ZFlavio GaleazzoProblem with snappyHexMesh when OpenFOAM is compiled using FMA-Instructions<!--
*** 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
I found a problem when using snappyHexMesh and a specific grid. In certain machines, the grid is correctly generated, in others, snappyHexMesh hangs in an endless loop.
The problem is correlated to FMA instructions (Fused Multiply-Accumulate) in new CPUs. I have tested using AMD EPYC and Intel Skylake CPUs, and various versions of GCC and Intel Compiler. When compiling the code with –O2 or –O3 and the flag for FMA (-mfma) or the CPU architecture (-march=znver2 or -march=skylake), FMA instructions are turned on, which have a different rounding precision than operations without FMA. Thus a test in particle.C is too strict, and the distance between particles and tet faces is not captured correctly. This creates an endless loop at the stage “Feature refinement iteration 0” of the grid creation.
The operation that uses FMA is the ^ operator used to calculate T in Foam::particle::stationaryTetReverseTransform. The test that fails is in Foam::particle::trackToStationaryTri, line 759 of particle.C `(if (Tx1[i] < - detA*SMALL))`.
### Steps to reproduce
Compile OpenFOAM with FMA flags on and off (the bugged code is in the src/lagrangian/basic/particle library).
Create the mesh from the file attached (mesh.tgz) using snappyHexMesh. Using the version compiled with FMA flags hangs.
[mesh.tgz](/uploads/d48ebc937bdea4fa7f27cc37c1b3e6f8/mesh.tgz)
### Example case
A small code example with the same operations as the ^ operator is also attached (Test_CrossProduct.cpp). Using separated multiply and addition results in (0 0 0), as the calculations are rounded twice. When using FMA, the result is rounded only once, showing the rounding error of a double variable (e.g. -8.73968e-17 -1.82965e-16 1.82965e-16).
[Test_CrossProduct.cpp](/uploads/bce4efcb9a48fc38ebee8838a4de79e4/Test_CrossProduct.cpp)
Without FMA
```
g++ -O3 -o Test_CrossProduct Test_CrossProduct.cpp
chmod 755 Test_CrossProduct
./Test_CrossProduct
```
With FMA
```
g++ -mfma -O3 -o Test_CrossProduct Test_CrossProduct.cpp
chmod 755 Test_CrossProduct
./Test_CrossProduct
```
### What is the current *bug* behaviour?
snappyHexMesh hangs in an endless loop.
### What is the expected *correct* behavior?
snappyHexMesh creates the grid.
### Relevant logs and/or images
<!--
Paste any relevant logs - please use code blocks (```) to format console
output, logs, and code as it's very hard to read otherwise.
-->
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v2206|v2112|v2106|v2012|v2006 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2106
- Operating system : CentOS 8
- Hardware info : AMD EPYC, Intel Skylake
- Compiler : GCC and intel
### Possible fixes
The solution for this is straightforward, just replacing SMALL with ROOTSMALL, and everything works. The file with the correction is attached.
[particle.C.patch](/uploads/a26a860e86621fef7b54832d18f638f4/particle.C.patch)Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/issues/2536Problems with the "useImplicit" feature for coupled patches2024-01-10T11:24:32ZTobias HolzmannProblems with the "useImplicit" feature for coupled patches<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be re...<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be rendered on the platform by using the
"preview" tab above
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
<!-- Summarize the bug encountered concisely -->
Hey everybody, since we introduced the `useImplicit` keyword for coupled patches, I had the feeling that we have discrepancies using this feature in the energy equation (e.g., for chtMultiRegionSimpleFoam cases). After having some discussions on the 17th OpenFOAM workshop, people second my statement, that the `implicit` implementation is somehow buggy and lead to different results compared to running the case in the weakly coupling mode (standard one).
Hence, I made further investigations by using the multiRegionHeaterRadiation tutorial:
- Added a FO to record the average temperature inside each region
- Running the case in standard mode
- Running the case by adding the `useImplicit` keyword to the mapped boundary conditions (for all regions)
- Comparing the average temperatures of all regions between both simulations
- Simulation was run for 5000 iterations
- Simulation was performed in serial (no parallel run performed up to now)
The comparison is attached and as we can see, we get different results.
I also attached both cases and the gnuplot script.
If we do have mismatches for the CHT cases, I guess the `cyclic*` patches might have problems as well (e.g., AMI and aero).
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Unpack the tar ball with the two cases + the gnuplot script.
Run the Allrun script for both cases and execute the gnuplot script.
### Example case
Already mentioned above. No further information required here.
[chtMultiRegionTestCasesImplicitBug.tar.gz](/uploads/9397d6b19087f36fbc0ded7fa7a6c169/chtMultiRegionTestCasesImplicitBug.tar.gz)
<!--
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?
Energy-Mismatch. It seems that the `implicit` somehow adds some sink term which reduces the temperature in the regions.
<!-- What actually happens -->
### What is the expected *correct* behavior?
Having the same results for both, the standard and implicit case.
<!-- What you should see instead -->
### Relevant logs and/or images
![comparison](/uploads/6b6d2d8341c3735ee6e6c460ce058c31/comparison.png)
<!--
Paste any relevant logs - please use code blocks (```) to format console
output, logs, and code as it's very hard to read otherwise.
-->
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v2206|v2112|v2106|v2012|v2006 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2206
- Operating system : Ubuntu 20.04
- Hardware info : Not interesting
- Compiler : Gcc v 9.4
### 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/2535spatial filtering for mapped file2023-05-30T18:58:13ZMark OLESENspatial filtering for mapped fileAs discussed in EP1913, the sampled input surfaces may often be finer than the target surfaces, which causes various aliasing effects.
Need additional support for spatial filtering to remove high-frequency before mapping to the target s...As discussed in EP1913, the sampled input surfaces may often be finer than the target surfaces, which causes various aliasing effects.
Need additional support for spatial filtering to remove high-frequency before mapping to the target surface. Temporal filter is probably not needed.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2534Inconsistent number of particles escaping the system2023-05-30T18:55:52ZGuanyang XueInconsistent number of particles escaping the system### Summary
The number of particles escaping the system is inconsistent.
I've asked this question (the last reply of the thread) a long time ago but no one answered:
https://www.cfd-online.com/Forums/openfoam-solving/217086-particle-fa...### Summary
The number of particles escaping the system is inconsistent.
I've asked this question (the last reply of the thread) a long time ago but no one answered:
https://www.cfd-online.com/Forums/openfoam-solving/217086-particle-fate-dpmfoam-mppicfoam.html#post766848
Might be related to this issue: https://develop.openfoam.com/Development/OpenFOAM-plus/-/issues/1306
### Steps to reproduce
Run particle tracking with user compiled particle forces added to `src/lagrangian/intermediate/submodels/Kinematic/ParticleForces`.
The particle force is simply modified from `PressureGraident` so I don't think there's any bug in my particle force.
### Example case
I don't want to share the case file as it is research related.
If you can't reproduce one with built-in particle force, I'll create a minimal case to reproduce that.
### What is the current *bug* behaviour?
This is the log from v2112. Obviously the number 80777 is problematic, and the simulation result doesn't make sense.
```
Current number of parcels = 1963
Current mass in system = 8.222595172e-15
Linear momentum = (4.11548211259e-17 -1.5147123108e-17 4.67553491316e-27)
|Linear momentum| = 4.38537870697e-17
Linear kinetic energy = 4.111297586e-17
Average particle per parcel = 1
Injector model1:
- parcels added = 9861
- mass introduced = 4.13056602094e-14
Parcel fate: system (number, mass)
- escape = 80777, 3.38357906372e-13
Parcel fate: patch frontAndBackPlanes|confinement|sidewall|inlet (number, mass)
- escape = 0, 0
- stick = 0, 0
Parcel fate: patch outlet (number, mass)
- escape = 7898, 3.3083065037e-14
- stick = 0, 0
```
### What is the expected *correct* behavior?
I've done some particle tracking researches using v1712 before and I know this version didn't give me any issue.
I tried to backport the same particle force to V1712 and everything looks normal:
```
Current number of parcels = 467
Current mass in system = 1.95616502564e-15
Linear momentum = (5.25816684692e-17 -4.81196024144e-19 1.35596323969e-34)
|Linear momentum| = 5.25838702324e-17
Linear kinetic energy = 1.77465381473e-18
Injector model1:
- parcels added = 9893
- mass introduced = 4.1439701496e-14
Parcel fate: system (number, mass)
- escape = 9426, 3.94835364703e-14
Parcel fate: patch frontAndBackPlanes|confinement|sidewall|inlet (number, mass)
- escape = 0, 0
- stick = 0, 0
Parcel fate: patch outlet (number, mass)
- escape = 9426, 3.94835364701e-14
- stick = 0, 0
```
### Relevant logs and/or images
Above
### Environment information
- OpenFOAM version : v2112
- Operating system : Rocky Linux
- Hardware info :
- Compiler : gcc
### Possible fixes
I can confirm v1712 doesn't have this issue, but v1912 and after does. From the thread https://www.cfd-online.com/Forums/openfoam-solving/217086-particle-fate-dpmfoam-mppicfoam.html, the OP said he used v1812, so most likely the bug was introduced between v1712 and v1812.https://develop.openfoam.com/Development/openfoam/-/issues/2533changeDictionary does not work in parallel with collated I/O system2022-12-12T13:04:06ZSaeedsaeed.salehi@chalmers.sechangeDictionary does not work in parallel with collated I/O system<!--
*** 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
changeDictionary does not work in parallel with collated I/O format. In my humble opinion, this should be fixed because the collated format is much more preferable, especially when working with clusters with large number of cores. Usually, there are limitations on clusters with the number of files, and thus collated format is much more effective.
### Steps to reproduce
decompose any case you would like in collated format (-fileHandler collated) and then setup an arbitrary changeDictionaryDict and run the utility in parallel, for instance,:
`mpirun -np 2 changeDictionary -parallel -fileHandler collated`
You will be able to see that the target file is manipulated incorrectly. Although the collated system should write all the processors' information in one file, after running changeDictionary it seems that only one processor's info will remain in the target file.
### Example case
The attached test case is a minimal example that shows the problem. The "Allrun" runs fine but "AllrunCollated" throws an error.
[cavityTable.tar.gz](/uploads/a11bf79f46d7f7fb40763357e09f14fb/cavityTable.tar.gz)
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v2206|v2112|v2106|v2012|v2006 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : OpenFOAM-v2112
- Operating system : Ubuntu 18.04, CentOS-7
- Hardware info : Dell PC, A cluster (more info at https://www.nsc.liu.se/systems/tetralith/)
- Compiler : Gcc, Icchttps://develop.openfoam.com/Development/openfoam/-/issues/2532ensight case includes bad file (disk) names2022-09-09T08:42:54ZMark OLESENensight case includes bad file (disk) namesEnsight is generally stricter with file names than with variable names. When generating the `.case` content, need to properly reflect the file names actually used instead of re-using the variable names.
cross-ref: EP1936 @ChiaraEnsight is generally stricter with file names than with variable names. When generating the `.case` content, need to properly reflect the file names actually used instead of re-using the variable names.
cross-ref: EP1936 @ChiaraMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2531Improvement of calculation in interface curvature in interFoam and InterIsoFoam2022-08-05T12:13:33Ztakuya yamamotoImprovement of calculation in interface curvature in interFoam and InterIsoFoam### Functionality to add/problem to solve
This implementation reduces the calculation error of interface curvature in interFoam and interIsoFoam. This implementation was reported by Hoang et al. Comput. Fluids 86 (2013) 28-36. I impleme...### Functionality to add/problem to solve
This implementation reduces the calculation error of interface curvature in interFoam and interIsoFoam. This implementation was reported by Hoang et al. Comput. Fluids 86 (2013) 28-36. I implemented this method. This implementation reduces the spurious current drastically.
This problem is also reported in issue https://develop.openfoam.com/Development/openfoam/-/issues/2479.
Especially in the case of interIsoFoam, this filter drastically reduces the velocity of spurious current. (Yamamoto and Komarov, Investigation for optimal use of VOF method in OpenFOAM, Proc. of OpenCAE Symposium 2021 (2021) The OpenCAE Society of Japan)
### Target audience
To who want to reduce the velocity of spurious current.
### Proposal
I attach the repair patch for $FOAM_SRC/transportModels/interfaceProperties/interfaceProperties.C and $FOAM_SRC/transportModels/interfaceProperties/interfaceProperties.H
[interfacePropertiesC.patch](/uploads/5a6c7b99dacee152468604dd5032d5a2/interfacePropertiesC.patch)
[interfacePropertiesH.patch](/uploads/f11b9dcc3f0faad3b3a8dcacf09f9a68/interfacePropertiesH.patch)
### What does success look like, and how can we measure that?
I simulated the static bubble in water. In this case, the spurious current is generated due to the imbalance of surface tension force. We attached the both case with and without smoother.
With smoother![wSmoother](/uploads/d8df39475df8e5684fc8d3845d153793/wSmoother.png)
Without smoother![woSmoother](/uploads/7aee58526a89677612c5e3c1aba17570/woSmoother.png)
### How to control the number of Laplacian filter
In system/fvSolution, one needs to add the following sentence (nSmooth) in addition to other parameters such as nAlphaCorr, nAlphaSubCycles.
> nAlphaCorr 5;
> nAlphaSubCycles 1;
> nSmooth 3;
The larger number of nSmooth smooths the original distribution of alpha. Therefore, too large nSmooth has possibility to worsen the calculation accuracy.
### Available solvers
When one uses this patch, the following solvers can use this smoother as an option.
* interFoam
* interIsoFoam
* overInterDyMFoam
* compressibleInterFoam
* compressibleInterDyMFoam
* compressibleInterIsoFoam
* overCompressibleInterDyMFoam
* compressibleInterFilmFoam
* interPhaseChangeFoamKutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2530binField function object sometime fails to work when several functions are de...2022-12-23T15:57:24ZYannbinField function object sometime fails to work when several functions are defined to compute bins on different patches<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be re...<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be rendered on the platform by using the
"preview" tab above
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
When using several binField function objects to compute forces or forceCoeffs bins on several patches, some functions fail to report values.
### Steps to reproduce
1. Replace the incompressible/simpleFoam/motorBike/system/forceCoeffs file with this one: [forceCoeffs](/uploads/6aab51a2e899c0cde344f34fa3300dcf/forceCoeffs)
2. Run the case
3. Check the corresponding forceCoeffBin.dat file in the postProcessing directory : some files report results while other files only write zeros.
### Example case
incompressible/simpleFoam/motorBike tutorial case with this [forceCoeffs](/uploads/6aab51a2e899c0cde344f34fa3300dcf/forceCoeffs) file.
The file has been modified to add 5 binField functions in addition to the default forceCoeffs function:
```
binField_motorBikeGroup
{
type binField;
libs (fieldFunctionObjects);
binModel singleDirectionUniformBin;
fields (forceCoeff);
patches (motorBikeGroup);
decomposePatchValues true;
CofR ${..forceCoeffs1.CofR};
binData
{
nBin 20; // output data into 20 bins
direction (1 0 0); // bin direction
cumulative yes;
}
writeControl timeStep;
}
binField_rider
{
$binField_motorBikeGroup
patches ("motorBike_rider.*");
}
binField_front_wheel
{
$binField_motorBikeGroup
patches ("motorBike_fr.*");
}
binField_rear_wheel
{
$binField_motorBikeGroup
patches ("motorBike_rr.*");
}
binField_fuel-tank
{
$binField_motorBikeGroup
patches ("motorBike_fuel-tank.*");
}
```
<!--
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?
The case runs properly, and forceCoeffBin.dat file are created for each functions:
- The file contains non-zero values for the front wheel and motorBikeGroup functions. Eg. for front wheel:
```
# bins : 20
# start : -2.909713e-01
# end : 1.121981e+00
# delta : 7.064761e-02
# direction : (1.000000e+00 0.000000e+00 0.000000e+00)
# x co-ords : -2.203237e-01 -1.496761e-01 -7.902850e-02 -8.380887e-03 6.226672e-02 1.329143e-01 2.035619e-01 2.742095e-01 3.448572e-01 4.155048e-01 4.861524e-01 5.568000e-01 6.274476e-01 6.980952e-01 7.687428e-01 8.393904e-01 9.100380e-01 9.806856e-01 1.051333e+00 1.121981e+00
# y co-ords : -0.000000e+00 -0.000000e+00 -0.000000e+00 -0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00
# z co-ords : -0.000000e+00 -0.000000e+00 -0.000000e+00 -0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00
#
# Time total_0_x total_0_y total_0_z internal_0_x internal_0_y internal_0_z normal_0_x normal_0_y normal_0_z tangenial_0_x tangenial_0_y tangenial_0_z total_1_x total_1_y total_1_z internal_1_x internal_1_y internal_1_z normal_1_x normal_1_y normal_1_z tangenial_1_x tangenial_1_y tangenial_1_z total_2_x total_2_y total_2_z internal_2_x internal_2_y internal_2_z normal_2_x normal_2_y normal_2_z tangenial_2_x tangenial_2_y tangenial_2_z total_3_x total_3_y total_3_z internal_3_x internal_3_y internal_3_z normal_3_x normal_3_y normal_3_z tangenial_3_x tangenial_3_y tangenial_3_z total_4_x total_4_y total_4_z internal_4_x internal_4_y internal_4_z normal_4_x normal_4_y normal_4_z tangenial_4_x tangenial_4_y tangenial_4_z total_5_x total_5_y total_5_z internal_5_x internal_5_y internal_5_z normal_5_x normal_5_y normal_5_z tangenial_5_x tangenial_5_y tangenial_5_z total_6_x total_6_y total_6_z internal_6_x internal_6_y internal_6_z normal_6_x normal_6_y normal_6_z tangenial_6_x tangenial_6_y tangenial_6_z total_7_x total_7_y total_7_z internal_7_x internal_7_y internal_7_z normal_7_x normal_7_y normal_7_z tangenial_7_x tangenial_7_y tangenial_7_z total_8_x total_8_y total_8_z internal_8_x internal_8_y internal_8_z normal_8_x normal_8_y normal_8_z tangenial_8_x tangenial_8_y tangenial_8_z total_9_x total_9_y total_9_z internal_9_x internal_9_y internal_9_z normal_9_x normal_9_y normal_9_z tangenial_9_x tangenial_9_y tangenial_9_z total_10_x total_10_y total_10_z internal_10_x internal_10_y internal_10_z normal_10_x normal_10_y normal_10_z tangenial_10_x tangenial_10_y tangenial_10_z total_11_x total_11_y total_11_z internal_11_x internal_11_y internal_11_z normal_11_x normal_11_y normal_11_z tangenial_11_x tangenial_11_y tangenial_11_z total_12_x total_12_y total_12_z internal_12_x internal_12_y internal_12_z normal_12_x normal_12_y normal_12_z tangenial_12_x tangenial_12_y tangenial_12_z total_13_x total_13_y total_13_z internal_13_x internal_13_y internal_13_z normal_13_x normal_13_y normal_13_z tangenial_13_x tangenial_13_y tangenial_13_z total_14_x total_14_y total_14_z internal_14_x internal_14_y internal_14_z normal_14_x normal_14_y normal_14_z tangenial_14_x tangenial_14_y tangenial_14_z total_15_x total_15_y total_15_z internal_15_x internal_15_y internal_15_z normal_15_x normal_15_y normal_15_z tangenial_15_x tangenial_15_y tangenial_15_z total_16_x total_16_y total_16_z internal_16_x internal_16_y internal_16_z normal_16_x normal_16_y normal_16_z tangenial_16_x tangenial_16_y tangenial_16_z total_17_x total_17_y total_17_z internal_17_x internal_17_y internal_17_z normal_17_x normal_17_y normal_17_z tangenial_17_x tangenial_17_y tangenial_17_z total_18_x total_18_y total_18_z internal_18_x internal_18_y internal_18_z normal_18_x normal_18_y normal_18_z tangenial_18_x tangenial_18_y tangenial_18_z total_19_x total_19_y total_19_z internal_19_x internal_19_y internal_19_z normal_19_x normal_19_y normal_19_z tangenial_19_x tangenial_19_y tangenial_19_z
1 9.319290e-03 3.783831e-03 2.338152e-04 0.000000e+00 0.000000e+00 0.000000e+00 9.258101e-03 3.815737e-03 2.353604e-04 6.118848e-05 -3.190588e-05 -1.545173e-06 1.979991e-02 -1.850194e-03 8.902802e-04 0.000000e+00 0.000000e+00 0.000000e+00 1.966742e-02 -1.815459e-03 8.959847e-04 1.324888e-04 -3.473528e-05 -5.704508e-06 2.334951e-02 -2.883175e-03 1.750529e-03 0.000000e+00 0.000000e+00 0.000000e+00 2.309898e-02 -2.844194e-03 1.759148e-03 2.505298e-04 -3.898047e-05 -8.618617e-06 2.643431e-02 -8.073942e-04 2.167716e-03 0.000000e+00 0.000000e+00 0.000000e+00 2.606784e-02 -7.612544e-04 2.178087e-03 3.664755e-04 -4.613977e-05 -1.037027e-05 3.315431e-02 -1.749637e-03 1.229961e-03 0.000000e+00 0.000000e+00 0.000000e+00 3.258272e-02 -1.686047e-03 1.236655e-03 5.715982e-04 -6.358976e-05 -6.693573e-06 4.609401e-02 -3.308220e-03 2.969573e-03 0.000000e+00 0.000000e+00 0.000000e+00 4.533658e-02 -3.238456e-03 2.977818e-03 7.574293e-04 -6.976378e-05 -8.244840e-06 6.157083e-02 -3.086262e-03 5.036829e-03 0.000000e+00 0.000000e+00 0.000000e+00 6.061498e-02 -2.999691e-03 5.037953e-03 9.558410e-04 -8.657087e-05 -1.124104e-06 7.347939e-02 -3.887791e-03 6.219341e-03 0.000000e+00 0.000000e+00 0.000000e+00 7.236157e-02 -3.785717e-03 6.228883e-03 1.117826e-03 -1.020747e-04 -9.542771e-06 7.549274e-02 -5.475471e-03 7.948811e-03 0.000000e+00 0.000000e+00 0.000000e+00 7.425961e-02 -5.361700e-03 7.973868e-03 1.233126e-03 -1.137718e-04 -2.505786e-05 7.954899e-02 -9.492312e-03 5.649803e-03 0.000000e+00 0.000000e+00 0.000000e+00 7.811080e-02 -9.335274e-03 5.712560e-03 1.438186e-03 -1.570380e-04 -6.275729e-05 7.708490e-02 -2.146010e-02 -3.996349e-03 0.000000e+00 0.000000e+00 0.000000e+00 7.547406e-02 -2.127314e-02 -3.918022e-03 1.610839e-03 -1.869567e-04 -7.832665e-05 7.534768e-02 -4.127680e-02 -1.407033e-02 0.000000e+00 0.000000e+00 0.000000e+00 7.345758e-02 -4.104295e-02 -1.398129e-02 1.890096e-03 -2.338458e-04 -8.903720e-05 7.640583e-02 -5.706572e-02 -1.899707e-02 0.000000e+00 0.000000e+00 0.000000e+00 7.421245e-02 -5.680462e-02 -1.889045e-02 2.193380e-03 -2.611016e-04 -1.066246e-04 7.613573e-02 -5.836737e-02 -1.796248e-02 0.000000e+00 0.000000e+00 0.000000e+00 7.388125e-02 -5.810644e-02 -1.785002e-02 2.254475e-03 -2.609222e-04 -1.124585e-04 7.613573e-02 -5.836737e-02 -1.796248e-02 0.000000e+00 0.000000e+00 0.000000e+00 7.388125e-02 -5.810644e-02 -1.785002e-02 2.254475e-03 -2.609222e-04 -1.124585e-04 7.613573e-02 -5.836737e-02 -1.796248e-02 0.000000e+00 0.000000e+00 0.000000e+00 7.388125e-02 -5.810644e-02 -1.785002e-02 2.254475e-03 -2.609222e-04 -1.124585e-04 7.613573e-02 -5.836737e-02 -1.796248e-02 0.000000e+00 0.000000e+00 0.000000e+00 7.388125e-02 -5.810644e-02 -1.785002e-02 2.254475e-03 -2.609222e-04 -1.124585e-04 7.613573e-02 -5.836737e-02 -1.796248e-02 0.000000e+00 0.000000e+00 0.000000e+00 7.388125e-02 -5.810644e-02 -1.785002e-02 2.254475e-03 -2.609222e-04 -1.124585e-04 7.613573e-02 -5.836737e-02 -1.796248e-02 0.000000e+00 0.000000e+00 0.000000e+00 7.388125e-02 -5.810644e-02 -1.785002e-02 2.254475e-03 -2.609222e-04 -1.124585e-04 7.613573e-02 -5.836737e-02 -1.796248e-02 0.000000e+00 0.000000e+00 0.000000e+00 7.388125e-02 -5.810644e-02 -1.785002e-02 2.254475e-03 -2.609222e-04 -1.124585e-04
2 1.347019e-02 4.183287e-03 3.040636e-04 0.000000e+00 0.000000e+00 0.000000e+00 1.341172e-02 4.214053e-03 3.055959e-04 5.846725e-05 -3.076563e-05 -1.532301e-06 2.710668e-02 -5.463558e-03 1.163173e-03 0.000000e+00 0.000000e+00 0.000000e+00 2.698525e-02 -5.412589e-03 1.169025e-03 1.214330e-04 -5.096843e-05 -5.851988e-06 3.124344e-02 -7.410281e-03 2.129561e-03 0.000000e+00 0.000000e+00 0.000000e+00 3.100574e-02 -7.348602e-03 2.137749e-03 2.376977e-04 -6.167834e-05 -8.188228e-06 3.505466e-02 -4.780226e-03 2.468843e-03 0.000000e+00 0.000000e+00 0.000000e+00 3.470934e-02 -4.713481e-03 2.481864e-03 3.453195e-04 -6.674509e-05 -1.302139e-05 4.471806e-02 -6.887990e-03 3.241075e-04 0.000000e+00 0.000000e+00 0.000000e+00 4.419996e-02 -6.804114e-03 3.393086e-04 5.180939e-04 -8.387693e-05 -1.520111e-05 6.209383e-02 -1.177219e-02 6.453413e-04 0.000000e+00 0.000000e+00 0.000000e+00 6.141188e-02 -1.168759e-02 6.695453e-04 6.819493e-04 -8.460279e-05 -2.420398e-05 8.308572e-02 -1.476724e-02 2.337215e-03 0.000000e+00 0.000000e+00 0.000000e+00 8.222519e-02 -1.466988e-02 2.355647e-03 8.605274e-04 -9.736346e-05 -1.843233e-05 9.678646e-02 -1.946263e-02 3.396610e-03 0.000000e+00 0.000000e+00 0.000000e+00 9.578805e-02 -1.935175e-02 3.423065e-03 9.984159e-04 -1.108729e-04 -2.645541e-05 9.857364e-02 -2.274205e-02 5.494448e-03 0.000000e+00 0.000000e+00 0.000000e+00 9.748327e-02 -2.260876e-02 5.543953e-03 1.090371e-03 -1.332858e-04 -4.950496e-05 1.046467e-01 -2.952611e-02 2.314062e-03 0.000000e+00 0.000000e+00 0.000000e+00 1.033936e-01 -2.936274e-02 2.389464e-03 1.253094e-03 -1.633677e-04 -7.540159e-05 1.007346e-01 -4.737008e-02 -1.109968e-02 0.000000e+00 0.000000e+00 0.000000e+00 9.933051e-02 -4.718101e-02 -1.100853e-02 1.404090e-03 -1.890603e-04 -9.115020e-05 9.799262e-02 -7.454921e-02 -2.531834e-02 0.000000e+00 0.000000e+00 0.000000e+00 9.632993e-02 -7.431963e-02 -2.521256e-02 1.662695e-03 -2.295875e-04 -1.057887e-04 9.877255e-02 -9.532148e-02 -3.034821e-02 0.000000e+00 0.000000e+00 0.000000e+00 9.682054e-02 -9.506470e-02 -3.022699e-02 1.952007e-03 -2.567854e-04 -1.212137e-04 9.859432e-02 -9.717074e-02 -2.843500e-02 0.000000e+00 0.000000e+00 0.000000e+00 9.658586e-02 -9.691059e-02 -2.831186e-02 2.008462e-03 -2.601457e-04 -1.231398e-04 9.859432e-02 -9.717074e-02 -2.843500e-02 0.000000e+00 0.000000e+00 0.000000e+00 9.658586e-02 -9.691059e-02 -2.831186e-02 2.008462e-03 -2.601457e-04 -1.231398e-04 9.859432e-02 -9.717074e-02 -2.843500e-02 0.000000e+00 0.000000e+00 0.000000e+00 9.658586e-02 -9.691059e-02 -2.831186e-02 2.008462e-03 -2.601457e-04 -1.231398e-04 9.859432e-02 -9.717074e-02 -2.843500e-02 0.000000e+00 0.000000e+00 0.000000e+00 9.658586e-02 -9.691059e-02 -2.831186e-02 2.008462e-03 -2.601457e-04 -1.231398e-04 9.859432e-02 -9.717074e-02 -2.843500e-02 0.000000e+00 0.000000e+00 0.000000e+00 9.658586e-02 -9.691059e-02 -2.831186e-02 2.008462e-03 -2.601457e-04 -1.231398e-04 9.859432e-02 -9.717074e-02 -2.843500e-02 0.000000e+00 0.000000e+00 0.000000e+00 9.658586e-02 -9.691059e-02 -2.831186e-02 2.008462e-03 -2.601457e-04 -1.231398e-04 9.859432e-02 -9.717074e-02 -2.843500e-02 0.000000e+00 0.000000e+00 0.000000e+00 9.658586e-02 -9.691059e-02 -2.831186e-02 2.008462e-03 -2.601457e-04 -1.231398e-04
3 1.480038e-02 2.928874e-03 3.120123e-04 0.000000e+00 0.000000e+00 0.000000e+00 1.473949e-02 2.962430e-03 3.138393e-04 6.089108e-05 -3.355517e-05 -1.826947e-06 2.730425e-02 -9.088814e-03 1.072127e-03 0.000000e+00 0.000000e+00 0.000000e+00 2.718348e-02 -9.028400e-03 1.079400e-03 1.207684e-04 -6.041454e-05 -7.273380e-06 3.058932e-02 -1.138982e-02 1.722938e-03 0.000000e+00 0.000000e+00 0.000000e+00 3.036146e-02 -1.130964e-02 1.733425e-03 2.278582e-04 -8.018040e-05 -1.048629e-05 3.421375e-02 -8.905770e-03 1.615114e-03 0.000000e+00 0.000000e+00 0.000000e+00 3.388956e-02 -8.818958e-03 1.631322e-03 3.241844e-04 -8.681132e-05 -1.620785e-05 4.438852e-02 -1.171869e-02 -1.310350e-03 0.000000e+00 0.000000e+00 0.000000e+00 4.391319e-02 -1.161206e-02 -1.290396e-03 4.753279e-04 -1.066300e-04 -1.995419e-05 6.210889e-02 -1.977270e-02 -3.156279e-03 0.000000e+00 0.000000e+00 0.000000e+00 6.149757e-02 -1.966797e-02 -3.128175e-03 6.113150e-04 -1.047298e-04 -2.810421e-05 8.307434e-02 -2.604784e-02 -2.516071e-03 0.000000e+00 0.000000e+00 0.000000e+00 8.232975e-02 -2.593587e-02 -2.489903e-03 7.445967e-04 -1.119664e-04 -2.616730e-05 9.465559e-02 -3.333242e-02 -1.798736e-03 0.000000e+00 0.000000e+00 0.000000e+00 9.381042e-02 -3.320559e-02 -1.760581e-03 8.451712e-04 -1.268241e-04 -3.815460e-05 9.502228e-02 -3.688120e-02 2.195585e-04 0.000000e+00 0.000000e+00 0.000000e+00 9.411142e-02 -3.672983e-02 2.899914e-04 9.108599e-04 -1.513698e-04 -7.043292e-05 1.008312e-01 -4.623596e-02 -3.965335e-03 0.000000e+00 0.000000e+00 0.000000e+00 9.979184e-02 -4.606608e-02 -3.869965e-03 1.039398e-03 -1.698766e-04 -9.537010e-05 9.589313e-02 -6.761570e-02 -1.917265e-02 0.000000e+00 0.000000e+00 0.000000e+00 9.472021e-02 -6.742150e-02 -1.906304e-02 1.172920e-03 -1.941978e-04 -1.096020e-04 9.241788e-02 -9.794649e-02 -3.490485e-02 0.000000e+00 0.000000e+00 0.000000e+00 9.100568e-02 -9.771496e-02 -3.478048e-02 1.412205e-03 -2.315339e-04 -1.243671e-04 9.275135e-02 -1.208652e-01 -3.867554e-02 0.000000e+00 0.000000e+00 0.000000e+00 9.106568e-02 -1.206091e-01 -3.853516e-02 1.685675e-03 -2.560213e-04 -1.403745e-04 9.288178e-02 -1.231811e-01 -3.625065e-02 0.000000e+00 0.000000e+00 0.000000e+00 9.114261e-02 -1.229219e-01 -3.611004e-02 1.739165e-03 -2.591978e-04 -1.406148e-04 9.288178e-02 -1.231811e-01 -3.625065e-02 0.000000e+00 0.000000e+00 0.000000e+00 9.114261e-02 -1.229219e-01 -3.611004e-02 1.739165e-03 -2.591978e-04 -1.406148e-04 9.288178e-02 -1.231811e-01 -3.625065e-02 0.000000e+00 0.000000e+00 0.000000e+00 9.114261e-02 -1.229219e-01 -3.611004e-02 1.739165e-03 -2.591978e-04 -1.406148e-04 9.288178e-02 -1.231811e-01 -3.625065e-02 0.000000e+00 0.000000e+00 0.000000e+00 9.114261e-02 -1.229219e-01 -3.611004e-02 1.739165e-03 -2.591978e-04 -1.406148e-04 9.288178e-02 -1.231811e-01 -3.625065e-02 0.000000e+00 0.000000e+00 0.000000e+00 9.114261e-02 -1.229219e-01 -3.611004e-02 1.739165e-03 -2.591978e-04 -1.406148e-04 9.288178e-02 -1.231811e-01 -3.625065e-02 0.000000e+00 0.000000e+00 0.000000e+00 9.114261e-02 -1.229219e-01 -3.611004e-02 1.739165e-03 -2.591978e-04 -1.406148e-04 9.288178e-02 -1.231811e-01 -3.625065e-02 0.000000e+00 0.000000e+00 0.000000e+00 9.114261e-02 -1.229219e-01 -3.611004e-02 1.739165e-03 -2.591978e-04 -1.406148e-04
```
- The files of the 3 other functions (fuel tank, rider and rear wheel) only reports zeros. Eg. on rider:
```
# bins : 20
# start : 3.120153e-01
# end : 1.268628e+00
# delta : 4.783063e-02
# direction : (1.000000e+00 0.000000e+00 0.000000e+00)
# x co-ords : 3.598459e-01 4.076766e-01 4.555072e-01 5.033378e-01 5.511685e-01 5.989991e-01 6.468297e-01 6.946604e-01 7.424910e-01 7.903216e-01 8.381523e-01 8.859829e-01 9.338135e-01 9.816442e-01 1.029475e+00 1.077305e+00 1.125136e+00 1.172967e+00 1.220797e+00 1.268628e+00
# y co-ords : 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00
# z co-ords : 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00
#
# Time total_0_x total_0_y total_0_z internal_0_x internal_0_y internal_0_z normal_0_x normal_0_y normal_0_z tangenial_0_x tangenial_0_y tangenial_0_z total_1_x total_1_y total_1_z internal_1_x internal_1_y internal_1_z normal_1_x normal_1_y normal_1_z tangenial_1_x tangenial_1_y tangenial_1_z total_2_x total_2_y total_2_z internal_2_x internal_2_y internal_2_z normal_2_x normal_2_y normal_2_z tangenial_2_x tangenial_2_y tangenial_2_z total_3_x total_3_y total_3_z internal_3_x internal_3_y internal_3_z normal_3_x normal_3_y normal_3_z tangenial_3_x tangenial_3_y tangenial_3_z total_4_x total_4_y total_4_z internal_4_x internal_4_y internal_4_z normal_4_x normal_4_y normal_4_z tangenial_4_x tangenial_4_y tangenial_4_z total_5_x total_5_y total_5_z internal_5_x internal_5_y internal_5_z normal_5_x normal_5_y normal_5_z tangenial_5_x tangenial_5_y tangenial_5_z total_6_x total_6_y total_6_z internal_6_x internal_6_y internal_6_z normal_6_x normal_6_y normal_6_z tangenial_6_x tangenial_6_y tangenial_6_z total_7_x total_7_y total_7_z internal_7_x internal_7_y internal_7_z normal_7_x normal_7_y normal_7_z tangenial_7_x tangenial_7_y tangenial_7_z total_8_x total_8_y total_8_z internal_8_x internal_8_y internal_8_z normal_8_x normal_8_y normal_8_z tangenial_8_x tangenial_8_y tangenial_8_z total_9_x total_9_y total_9_z internal_9_x internal_9_y internal_9_z normal_9_x normal_9_y normal_9_z tangenial_9_x tangenial_9_y tangenial_9_z total_10_x total_10_y total_10_z internal_10_x internal_10_y internal_10_z normal_10_x normal_10_y normal_10_z tangenial_10_x tangenial_10_y tangenial_10_z total_11_x total_11_y total_11_z internal_11_x internal_11_y internal_11_z normal_11_x normal_11_y normal_11_z tangenial_11_x tangenial_11_y tangenial_11_z total_12_x total_12_y total_12_z internal_12_x internal_12_y internal_12_z normal_12_x normal_12_y normal_12_z tangenial_12_x tangenial_12_y tangenial_12_z total_13_x total_13_y total_13_z internal_13_x internal_13_y internal_13_z normal_13_x normal_13_y normal_13_z tangenial_13_x tangenial_13_y tangenial_13_z total_14_x total_14_y total_14_z internal_14_x internal_14_y internal_14_z normal_14_x normal_14_y normal_14_z tangenial_14_x tangenial_14_y tangenial_14_z total_15_x total_15_y total_15_z internal_15_x internal_15_y internal_15_z normal_15_x normal_15_y normal_15_z tangenial_15_x tangenial_15_y tangenial_15_z total_16_x total_16_y total_16_z internal_16_x internal_16_y internal_16_z normal_16_x normal_16_y normal_16_z tangenial_16_x tangenial_16_y tangenial_16_z total_17_x total_17_y total_17_z internal_17_x internal_17_y internal_17_z normal_17_x normal_17_y normal_17_z tangenial_17_x tangenial_17_y tangenial_17_z total_18_x total_18_y total_18_z internal_18_x internal_18_y internal_18_z normal_18_x normal_18_y normal_18_z tangenial_18_x tangenial_18_y tangenial_18_z total_19_x total_19_y total_19_z internal_19_x internal_19_y internal_19_z normal_19_x normal_19_y normal_19_z tangenial_19_x tangenial_19_y tangenial_19_z
1 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00
2 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00
3 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00
```
### What is the expected *correct* behavior?
Since the forceCoeffs have been calculated on the whole motorBike geometry, I would expect binField to be able to retrieve and compute data on any patch or group of patch contained in this geometry.
I firstly thought I misunderstood the way binField is supposed to work, but the fact it actually works on some patches let me think there is a bug somewhere.
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v2206
Operating system : ubuntu 20.04 and
-->
- OpenFOAM version : v2206
- Operating system : Ubuntu 18.04Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2529multi-world communication can hang due to warnComm2022-12-23T14:57:41ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.commulti-world communication can hang due to warnComm<!--
*** 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 -->
Some multi-world cases can hang with stacktraces:
```
[solid/6] #0 Foam::error::printStack(Foam::Ostream&) at ??:?
[solid/6] #1 Foam::UIPstream::read(Foam::UPstream::commsTypes, int, char*, long, int, int) at ??:?
[solid/6] #2 void Foam::syncTools::syncBoundaryFaceList<Foam::Vector<double>, Foam::eqOp<Foam::Vector<double> >, Foam::mapDistribute::transformPosition>(Foam::polyMesh const&, Foam::UList<Foam::Vector<double> >&, Foam::eqOp<Foam::Vector<double> > const&, Foam::mapDistribute::transformPosition const&, bool) at ??:?
[solid/6] #3 Foam::polyMeshTetDecomposition::findFaceBasePts(Foam::polyMesh const&, double, bool) at ??:?
[solid/6] #4 Foam::polyMesh::tetBasePtIs() const at ??:?
[solid/6] #5 Foam::mappedPatchBase::facePoints(Foam::polyPatch const&) const at ??:?
[solid/6] #6 Foam::mappedPatchBase::calcMapping() const at ??:?
[solid/6] #7 Foam::mappedPatchBase::map() const at ??:?
[solid/6] #8 void Foam::mappedPatchBase::distribute<double>(Foam::List<double>&) const at ??:?
[solid/6] #9 Foam::compressible::turbulentTemperatureRadCoupledMixedFvPatchScalarField::updateCoeffs() at ??:?
[solid/6] #10 Foam::mixedFvPatchField<double>::evaluate(Foam::UPstream::commsTypes) at ??:?
[solid/6] #11 Foam::mixedEnergyFvPatchScalarField::updateCoeffs() at ??:?
[solid/6] #12 Foam::fvMatrix<double>::fvMatrix(Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh> const&, Foam::dimensionSet const&) at ??:?
[solid/6] #13 Foam::tmp<Foam::fvMatrix<double> > Foam::fv::optionList::operator()<double>(Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh> const&, Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh>&, Foam::word c
```
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
No case yet.
### What is the current *bug* behaviour?
<!-- What actually happens -->
Printing backtrace due to warnComm being set but worldComm not yet switched over.
### What is the expected *correct* behavior?
<!-- What you should see instead -->
No backtrace, no hanging
### 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.
-->
See above
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v2206|v2112|v2106|v2012|v2006 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2206
### 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
-->Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/2528ParaFoam crashes loading mesh made using snappyHexMesh2022-07-05T12:22:06ZRamkumarParaFoam crashes loading mesh made using snappyHexMeshHello developer(s), I am Ramkumar.
Recently I compiled OpenFOAM v2112 along with ParaView 5.10 that comes with it, on a Ubuntu 20.04 machine. Then I prepared a simulation case setup in which I used snappyHexMesh to generate the mesh, w...Hello developer(s), I am Ramkumar.
Recently I compiled OpenFOAM v2112 along with ParaView 5.10 that comes with it, on a Ubuntu 20.04 machine. Then I prepared a simulation case setup in which I used snappyHexMesh to generate the mesh, when i try to visualize the mesh in ParaView using command `paraFoam`, ParaView immediately crashes. To understand what is the issue, I created a foam file using `touch case.foam` and tried loading it in ParaView using command `paraview case.foam`. There i was able to visualize the mesh properly.
To narrow down further, i tried loading the background mesh that was created using `blockMesh` containing only pure hex cells, using `paraFoam`, and i was able to load/visualize it there. So, the issue is that, `paraview` was able to load mesh with polyhedral cells but `paraFoam` crashes when loading it, but `paraFoam` works fine with pure hex mesh. I guess it is something to do with PVFoamReader.
I think this is not a bug, but something i am missing during compilation. Because, if it was a bug, then i am sure that you might have caught it long before me. I couldn't find any support for this on forums and other community places, so i came here.
For your reference, I have attached [log.paraviewCompilation](/uploads/f16479d02a4972be5741e7a247403837/log.paraviewCompilation) log file which is made during ParaView compilation and, [log.recompile](/uploads/89587a8ae2412ee64defa6da24a40e87/log.recompile) this log is made during second run of `./Allwmake` after compiling paraview. and [log.paraFoamRun](/uploads/31ace57ebcbbe822538c5197848574e1/log.paraFoamRun) this is the log of error output that i got when `paraFoam` crashes.
FYI, i need paraFoam for my work, as those plugins i get with are very helpful. otherwise i could have gone for regular paraview. I followed all the steps mentioned in the user guide for compilation.
Could you please help me in fixing this issue?. I got almost same one on compiling v2206 on a Ubuntu 22.04 machine.https://develop.openfoam.com/Development/openfoam/-/issues/2527BUG: setTurbulenceFields: processor boundaries are not updated2022-07-04T15:26:55ZKutalmış BerçinBUG: setTurbulenceFields: processor boundaries are not updated`fld.correctBoundaryConditions()` should be avoided, but processor boundaries should still need to be updated.`fld.correctBoundaryConditions()` should be avoided, but processor boundaries should still need to be updated.Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2526oscillatingRotatingMotion for pointDisplacement field does not decompose if n...2022-08-18T10:37:11ZCristóbal IbáñezoscillatingRotatingMotion for pointDisplacement field does not decompose if not written differently<!--
*** 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 -->
Boundary condition `type solidBodyMotionDisplacement;` with `solidBodyMotionFunction oscillatingRotatingMotion;` for `pointDisplacement` field runs fine in serial but needs to be written differently if the case wants to be decomposed.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Decomposing the tutorial case `$FOAM_TUTORIALS/mesh/moveDynamicMesh/relativeMotion/box2D_moveDynamicMesh` I get the following error when decomposing the field:
```
Processor 0: field transfer
--> FOAM FATAL IO ERROR: (openfoam-2206)
Entry 'solidBodyMotionFunction' not found in dictionary "/scratch/cibanez/relativeMotion/box2D_moveDynamicMesh/0/pointDisplacement.boundaryField.wing2.oscillatingRotatingMotionCoeffs"
file: 0/pointDisplacement.boundaryField.wing2.oscillatingRotatingMotionCoeffs at line 56 to 59.
From bool Foam::dictionary::readEntry(const Foam::word&, T&, Foam::keyType::option, bool) const [with T = Foam::word]
in file /prog/OpenFOAM/OpenFOAM-v2206/src/OpenFOAM/lnInclude/dictionaryTemplates.C at line 322.
FOAM exiting
```
<!--
### Example case
If possible, please create a SMALL example and attach it to your report
If you are using an older version of OpenFOAM this will also determine
whether the bug has been fixed in a more recent version
-->
### What is the current *bug* behaviour?
<!-- What actually happens -->
The current BC in `pointDisplacement` runs in serial
```
wing2
{
// Make wing2 rotate around its centre
type solidBodyMotionDisplacement;
solidBodyMotionFunction oscillatingRotatingMotion;
oscillatingRotatingMotionCoeffs
{
origin (-0.41 0 0);
axis (0 0 1);
omega 10; // rad/s, 1rad/s=9.5rpm
amplitude (0 0 10); // max amplitude (degrees)
}
}
```
but it needs to be written as follows to be able to decompose the boundary field
```
wing2
{
// Make wing2 rotate around its centre
type solidBodyMotionDisplacement;
solidBodyMotionFunction oscillatingRotatingMotion;
oscillatingRotatingMotionCoeffs
{
solidBodyMotionFunction oscillatingRotatingMotion; // This line added inside the coeffs
origin (-0.41 0 0);
axis (0 0 1);
omega 10; // rad/s, 1rad/s=9.5rpm
amplitude (0 0 10); // max amplitude (degrees)
}
}
```
### What is the expected *correct* behavior?
<!-- What you should see instead -->
It should decompose as it's written in the tutorial.
<!--
### Relevant logs and/or images
Paste any relevant logs - please use code blocks (```) to format console
output, logs, and code as it's very hard to read otherwise.
-->
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v2206|v2112|v2106|v2012|v2006 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2206 | v2112
<!--
### 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