Development issueshttps://develop.openfoam.com/groups/Development/-/issues2022-09-28T14:12:02Zhttps://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/1979Problem with totalFlux calculation in adjustPhi2022-04-26T16:06:28ZJohan RoenbyProblem with totalFlux calculation in adjustPhiThe variable totalFlux in cfdTools/general/adjustPhi/adjustPhi.C is calculated like this:
```
scalar totalFlux = VSMALL + sum(mag(phi)).value();
```
If I understand this correctly, the sum is over all internal faces.
At least in my cas...The variable totalFlux in cfdTools/general/adjustPhi/adjustPhi.C is calculated like this:
```
scalar totalFlux = VSMALL + sum(mag(phi)).value();
```
If I understand this correctly, the sum is over all internal faces.
At least in my case [floating2Dbox.zip](/uploads/09927295f1b004a086522694b51a693f/floating2Dbox.zip), the sum is initially zero, and I get totalFlux = 1e-300 although on the boundaries I have matching in- and outflow fluxes. For the attached case, this results in crash with:
```
--> FOAM FATAL ERROR: (openfoam-2012)
Continuity error cannot be removed by adjusting the outflow.
Please check the velocity boundary conditions and/or run potentialFoam to initialise the outflow.
Total flux : 1.0000000000000000251e-300
Specified mass inflow : 1.0000000000000059952
Specified mass outflow : 1.0000000000000064393
Adjustable mass outflow : 0
[floating2Dbox.zip](/uploads/eaba426b2041929d8e0787cc7a877d0d/floating2Dbox.zip)
```
The culprit is the line:
```
else if (mag(fixedMassOut - massIn)/totalFlux > 1e-8)
```
triggering the error.
My suggestion is to redefine totalFlux to also include the fixed boundary flux:
```
scalar totalFlux =
VSMALL + sum(mag(phi)).value() + mag(fixedMassOut) + mag(massIn);
```
It could also be considered to replace the hardcoded 1e-8 in the error condition above by for instance the `tolerance` of pFinal or p_rghFinal specified by the user in fvSolution.v2206Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1067Problem with wave boundary conditions2024-03-08T22:57:31ZJohan RoenbyProblem with wave boundary conditionsThe wave boundary conditions are introducing a small fraction of air in the water phase. This is illustrated in the attached video:
![streamFunWaveProblem](/uploads/e4972a4f225032115a5583500e15852c/streamFunWaveProblem.mp4)
which shows...The wave boundary conditions are introducing a small fraction of air in the water phase. This is illustrated in the attached video:
![streamFunWaveProblem](/uploads/e4972a4f225032115a5583500e15852c/streamFunWaveProblem.mp4)
which shows the 0.99 and 0.9999 alpha contours of the $FOAM_TUTORIALS/multiphase/interFoam/laminar/waveExampleStreamFunction case.
The case was run as is.
If run with interIsoFoam instead of interFoam, isoAdvector collects the small amount of air in the water phase into bubbles that rise to the surface. A work around is to run interIsoFoam with surfCellTol = 1e-2 in fvSolution.solvers."alpha.water.*". But really this seems to be a problem with the wave BC's and not with isoAdvector.
A Paraview state file used to generate the movie is attached here: [state2.pvsm](/uploads/0ae150172498bbf215446260ada7e1e5/state2.pvsm)v1812Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/issues/1856profiling csv2020-11-17T13:15:23ZHenning Scheuflerprofiling csvProfiling your application is an important step in development. The new profiling feature drastically simplifies this process by just adding profiling triggers or macros in the relevant function or classes. When writing a test applicatio...Profiling your application is an important step in development. The new profiling feature drastically simplifies this process by just adding profiling triggers or macros in the relevant function or classes. When writing a test application using the profiling feature the timings can be written to a specific file by adding:
`profiling::print(fileName)`
However, the current format is hard to parse with another tool/language e.g. python:
```
profiling
{
trigger0
{
id 0;
description "application::main";
calls 1;
totalTime 2.50246;
childTime 2.41516;
active true;
}
trigger1
{
id 1;
parentId 0;
description "trigger";
calls 56;
totalTime 2.39554;
childTime 1.21259;
maxMem 260780;
active true;
}
.....
}
```
Would it be possible to add an alternative write format such as csv:?
trigger,id,parentId,description,calls,totalTime,childTime,maxMem,active
trigger0,0,application::main,1,2.50246,2.41516,true
The documentation of the profiling feature is very helpful but could be improved by adding the default write the location of the profiling file:
```
Detailed Description
Code profiling.
This is typically activated from within the system/controlDict as follows (defaults shown):
profiling
{
active true;
cpuInfo false;
memInfo false;
sysInfo false;
}
or simply using all defaults:
profiling
{}
The default output is timeName/uniform/profiling // added
```Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2588propellerInfo function object cannot find MRFProperties file2022-09-20T16:52:59ZNikola MajksnerpropellerInfo function object cannot find MRFProperties file
### Summary
When using `rotationMode MRF;` in `propellerInfo` function object `MRFProperties` file is not found even if it exists in `constant/MRFProperties`
### Steps to reproduce
1. Modify propellerInfo file to use `MRFProperties`...
### Summary
When using `rotationMode MRF;` in `propellerInfo` function object `MRFProperties` file is not found even if it exists in `constant/MRFProperties`
### Steps to reproduce
1. Modify propellerInfo file to use `MRFProperties` and run `simpleFoam -postProcess`
2. It produces an error below.
### What is the current *bug* behaviour?
Running for example `simpleFoam -postProcess` produces error below.
```
--> FOAM FATAL IO ERROR: (openfoam-2206)
Unable to find MRFProperties in the database. Is this an MRF case?
```
### What is the expected *correct* behavior?
No errors and function object executed successfully.
### Environment information
- OpenFOAM version : v2206|v2112
- Operating system : ubuntu 22.04
### Possible fixes
```
const auto* MRFZones =
new IOMRFZoneList(mesh_);
```
Using this code instead of the code below fixes the issue, but I think there might be a better way to do it, as I'm not OpenFOAM programming expert.
```
const auto* MRFZones =
mesh_.cfindObject<IOMRFZoneList>("MRFProperties");
```
https://develop.openfoam.com/Development/openfoam/-/blob/master/src/functionObjects/forces/propellerInfo/propellerInfo.C#L82
https://develop.openfoam.com/Development/openfoam/-/blob/master/src/functionObjects/forces/propellerInfo/propellerInfo.C#L148https://develop.openfoam.com/Development/openfoam/-/issues/1592Proposal: alphatWallBoilingWallFunctionFvPatchScalarField.C wall temperature ...2021-07-08T14:12:44ZRobin KamenickyProposal: alphatWallBoilingWallFunctionFvPatchScalarField.C wall temperature iterationHello everyone,
I have noticed that in the release OF-v1906 in the file OpenFOAM-v1906/src/phaseSystemModels/reactingEulerFoam/derivedFvPatchFields/alphatWallBoilingWallFunction/alphatWallBoilingWallFunctionFvPatchScalarField.C there wa...Hello everyone,
I have noticed that in the release OF-v1906 in the file OpenFOAM-v1906/src/phaseSystemModels/reactingEulerFoam/derivedFvPatchFields/alphatWallBoilingWallFunction/alphatWallBoilingWallFunctionFvPatchScalarField.C there was a for loop to evaluate wall temperature Tw. The for loop was, however, not executed because of lagging (line 1124 // NOTE: lagging Tw update.).
Thus, the wall temperature was not evaluated after the calculation of the thermal turbulent diffusivity. This led to zero error between TsupPrev and TsupNew and so the for loop was not executed. The fix to that would be the evaluation of the maximum error from all CPUs. Thus
`scalar maxErr(gMax(mag(TsupPrev - TsupNew)));`
instead of
`scalar maxErr(max(mag(TsupPrev - TsupNew)));`
When the original version is used then each processor might evaluate the error if condition on the line 1260
if (maxErr < 1e-1) differently, which means that some processor exits the for loop and some processor loops again. In this manner, the processors enter different parts of the code. Once they encounter a mpi function which requests information also from the other processor, it waits (forever, deadlock). This exactly happens when alphatWallBoilingWallFunctionFvPatchScalarField.C is used together with the turbulentTemperatureCoupledBaffleMixedFvPatchScalarField.C
I propose that the for loop to find wall temperature is implemented (as it was removed from OF-v1912) and the lagging to be fixed in the manner I showed above. It is generally recommended by literature to do this looping. Its absence might not be a big issue for heat transfer which uses correlations (film boiling and transitional boiling) but might be an issue for more complicated nucleate boiling.
Thank you,
Kind regards,
RobinKutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2718Proposal: Meson Build System2023-09-07T19:03:22ZVolker WeißmannProposal: Meson Build SystemIn [this issue](https://develop.openfoam.com/Development/openfoam/-/issues/1936) we first talked about meson as an alternative build system. In [this issue](https://develop.openfoam.com/Development/openfoam/-/issues/1984#note_57979) I p...In [this issue](https://develop.openfoam.com/Development/openfoam/-/issues/1936) we first talked about meson as an alternative build system. In [this issue](https://develop.openfoam.com/Development/openfoam/-/issues/1984#note_57979) I presented the first prototype. Now we need to talk about how this project should continue. Please either respond in writing, or we can arrange a Jitsi-Meeting in English or German, whatever you prefer.
Example How to build and run:
```shell
git clone https://develop.openfoam.com/Development/openfoam.git
cd openfoam
git checkout 988ec18ecc
wget https://codeberg.org/Volker_Weissmann/foam_meson_patches/raw/branch/trunk/for_openfoam_commit_hash_988ec18ecc.diff
git apply ../for_openfoam_commit_hash_988ec18ecc.diff
meson setup ../build # Takes about 10 seconds
cd ../build
ninja # Takes hours
meson devenv # Launches a subshell that has some environmental variables (among others: $PATH) set.
cd ../openfoam/tutorials/basic/laplacianFoam/flange
./Allrun
```
(You can replace ../build with any path you like, no matter if its inside of the openfoam folder or not.)
Note that the above is a debug build, i.e. equivalent to setting "WM_COMPILE_OPTION=Debug". If you want a release build, i.e. equivalent to "WM_COMPILE_OPTION=Opt", you need to add a flag like this:
```
meson setup ../build --buildtype=release
```
I generated patches for the openfoam version with the commit hash 988ec18ecc, but I can generate patches for other versions too, just tell me what versions you need patches for.
# Open Issues
I have not looked at the ThirdParty folder yet, but that can follow.
I know that the OpenFOAM project needs to generate binary packages for different distributions. I have not looked closer at that yet, but that can follow.
The following dependencies are currently never used:
- zoltan
- mgrid
- ccmio
- kahip
- scotch
Again, fixing this is possible, but I want to fix this after we know what direction the project is gonna take.
## Build Subfolders seperately
One good thing about wmake is that you can copy e.g. the `applications/solvers/lagrangian/reactingParcelFoam/simpleReactingParcelFoam` folder to some other path outside of the openfoam folder, modify the contents a bit and run `wmake` inside that folder to build it. I think we will have to talk about that more than about any other feature. Currently, my build system offers no similar feature, but I have ideas on how to implement something like that.
## OS Support
I only tested it on my ArchLinux machine, and on a debian docker container, with the following additional packages installed:
```sh
apt-get install -y git g++ zlib1g-dev libfftw3-dev mpi-default-dev libboost-system-dev flex
```
I installed meson from source, since the packaged version is too old (we need at least 0.59.0).
This was the script I ran on Debian:
```
set -euo pipefail
IFS=$'\n\t'
cd /root
apt update
apt install -y git g++ zlib1g-dev libfftw3-dev mpi-default-dev libboost-system-dev flex python3 ninja-build wget
wget https://codeberg.org/Volker_Weissmann/foam_meson_patches/raw/branch/trunk/for_openfoam_commit_hash_988ec18ecc.diff
git clone https://github.com/mesonbuild/meson || true
cd meson
git checkout 0.59.0
cd ..
git clone https://develop.openfoam.com/Development/openfoam.git
cd openfoam
git checkout 988ec18ecc
git apply ../for_openfoam_commit_hash_988ec18ecc.diff
../meson/meson.py setup ../build
cd ../build
ninja
../meson/meson.py devenv bash -c "cd ../openfoam/tutorials/basic/laplacianFoam/flange && ./Allrun"
```
Support for other OS's should not be much work.
If we decide to continue this project, I will setup proper testing on different OS's.
# Advantages over wmake
While wmake is only used by the openfoam project, meson is used by many different projects and has way more/better documentation that wmake. So if you know how to use meson, you know how to use it in the OpenFOAM project.
The meson.build files are very easy to read.
`meson setup` generates a compilation_commands.json file with can be [useful to IDE's](https://openfoamwiki.net/index.php/HowTo_Use_OpenFOAM_with_Visual_Studio_Code). No need for any slow hacks anymore.
I have not confirmed the following with measurements yet, but I will do so if we decide to continue this project:
A clean compile is about as fast as a clean compile with Allwmake. Incremental builds however, are *way* faster. If nothing has changed and you run `ninja` again, this takes 2-5 seconds (and we could further reduce that time). In contrast, running `./Allwmake` in the top-level directory will take over a minute on the same machine.
Afaik, meson is better at knowing what needs to be rebuilt and what does not. This results in faster incremental builds and less wrong builds (I vaguely remembering having trouble that wmake did not recompile stuff that changed, leading to a confusing debugging session).
Afaik, if you build openfoam, then do `git pull` and run `./Allwmake` again, it is possible that this will fail and you have to manually run `wclean`. This happened to me, when I upgraded from `0031cb1efac0d550334108346f26dde5e707b6fd` to `988ec18ecca76aa0cef65acbab765374416d61b6`:
```
make: *** No rule to make target 'fields/faPatchFields/constraint/processor/processorFaPatchScalarField.H', needed by '/home/volker/Documents/foam/openfoam/build/linux64GccDPInt32Opt/src/finiteArea/fields/faPatchFields/constraint/processor/processorFaPatchFields.C.dep'. Stop.
```
Meson on the other hand, is afaik quite robust in such cases. The only thing that ever forced manual intervention or a clean rebuild was if I made changes to the OS (e.g. removing a package that is an optional dependency of OpenFOAM, or when I built in on one machine and copied the build folder to a different machine).
If you just want to build a single binary, you ran run `ninja targetname` and it will build this binary and all of its dependencies. With wmake, you either have to run `./Allwmake` in the top directory, which is slow, or manually go into each directory that is a dependency of this binary and run `wmake` there.
If you add "#include something.C" to a source file, then run `wmake`, then remove that line and the file, `wmake` will fail with
```
make: *** No rule to make target 'something.C', needed by '/home/volker/Sync/git/foam_meson/legacy/build/linux64GccDPInt32Opt/src/parallel/reconstruct/faReconstruct/processorFaMeshes.C.dep'. Stop.
```
You have to run `wclean` to fix this. The same thing works fine with meson/ninja.
If you build (at least a part of) OpenFOAM, then change `WM_COMPILE_OPTION`, and run `./Allwmake`, it will not recompile the things that were compiled with the old `WM_COMPILE_OPTION`. Ninja will recompile everything that is necessary. (With wmake, I had to delete my build folder many times because I forget if I had always set WM_COMPILE_OPTION correctly.)
If your machine is missing a dependency of OpenFOAM, meson will error during the first few seconds and tell you that you are missing that dependency. With wmake on the other hand, it might compile for hours until you see that some header file cannot be found. (Trying to build OpenFOAM on a machine that uses musl-libc instead of glibc was fun.)
With meson, you can do out-of-tree builds.
Make interleaves the output of multiple cores, Ninja does not.https://develop.openfoam.com/Development/openfoam/-/issues/3018pTraits for complex looks incorrect2023-11-13T13:53:25ZMark OLESENpTraits for complex looks incorrectThe complex type is defined to have two components (ie, real, imag) but has cmptType as "complex" - doesn't really make sense, and has labelType as label anyhow.
It doesn't seem to be used anywhere but could be interesting with different...The complex type is defined to have two components (ie, real, imag) but has cmptType as "complex" - doesn't really make sense, and has labelType as label anyhow.
It doesn't seem to be used anywhere but could be interesting with different backends (eg ADIOS).
@andy @kutiv2406Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2054Question about GAMG solver strategy (only V cycles currently)2023-07-19T16:41:29ZMINHAO XUQuestion about GAMG solver strategy (only V cycles currently)### Functionality to add/problem to solve
I checked the source code of GAMG solver and found that there is only V cycle for multi-grid. From some literature it said that F and W cycly may convergence faster thant normal V cycle. My quest...### Functionality to add/problem to solve
I checked the source code of GAMG solver and found that there is only V cycle for multi-grid. From some literature it said that F and W cycly may convergence faster thant normal V cycle. My question is: why not add F and W cycle as an alternative? What are your worries?
(Brief scope)
### Target audience
GAMG are mainly used in solving matrics of pressure field and as I know it is always hard to convergence and costs much time in the whole solving proccess. So everyone who uses GAMG solver may nenifit from the changes.
(Who will benefit from the changes?)
(What type of cases?)
### Proposal
Add W and F cycle of multi-grid series solver.
(How are we going to solve the problem?)
### What does success look like, and how can we measure that?
add alternative cycles and api to let user choose own cycles.
(What are the success factors and acceptance criteria? e.g. test cases, error margins)
### Links / references
https://en.wikipedia.org/wiki/Multigrid_method
(Links to literature, supporting information)
### Funding
(Does the functionality already exist/is sponsorship available?)https://develop.openfoam.com/Development/openfoam/-/issues/2644ReactingHeterogeneousParcel and ThermoParcel interaction problem2023-06-04T07:47:36ZÖrjan FjällborgReactingHeterogeneousParcel and ThermoParcel interaction problem<!--
*** 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 -->
At line 297 in ThermoParcel.C an integration is done to get a new particle delta temperature, but only convective- and radiative heat transfer is considered in the integration. The chemical heat calculated in ReactingHeterogeneousParcel.C and put into the variable dhsTrans is not added to the integration constants (anc, ancp and bcp) like the other heat transfer mechanisms.
### 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
-->
The tutorial rectangularDuct includes both parcel types.
### What is the current *bug* behaviour?
<!-- What actually happens -->
Heat from chemical reaction does not heat up currently calculated parcle
### What is the expected *correct* behavior?
The parcel shoud be heated up with heat from chemical reaction also
<!-- What you should see instead -->
### Relevant logs and/or images
<!--
Paste any relevant logs - please use code blocks (```) to format console
output, logs, and code as it's very hard to read otherwise.
-->
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : 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 : v2112
- Operating system : ubuntu
- Hardware info :
- Compiler : g++
### 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/2647readFields function object is sticky in postProcess mode2023-06-23T09:05:09ZAndrew HeatherreadFields function object is sticky in postProcess modeThe `readFields` function object only reads from file if the field is not already found in the database. Using `postProcess` this leads to fields being initially read but not updated at the new times.The `readFields` function object only reads from file if the field is not already found in the database. Using `postProcess` this leads to fields being initially read but not updated at the new times.v2212Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/issues/2660reconstructParMesh does not handle moving mesh cases with topology changes2023-06-28T10:39:49ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comreconstructParMesh does not handle moving mesh cases with topology changes<!--
*** 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 -->
Use reconstructParMesh on a (parallel) case with topo changes. It will crash when trying to recalculate the mesh.phi() before that field has been updated.
### 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
-->
`tutorials/multiphase/compressibleInterDyMFoam/laminar/sphereDrop` and use the Allrun-parallel script.
### What is the current *bug* behaviour?
<!-- What actually happens -->
Crash with out-of-bounds error.
### 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.
-->
```
--> FOAM FATAL ERROR: (openfoam-2212)
index 2275 out of range [0,2275]
From void Foam::UList<T>::checkIndex(Foam::label) const [with T = double; Foam::label = int]
in file /home/pikachu2/mattijs/OpenFOAM/OpenFOAM-plus/work/develop/src/OpenFOAM/lnInclude/UListI.H at line 169.
FOAM aborting
#0 Foam::error::printStack(Foam::Ostream&) in ~/OpenFOAM/OpenFOAM-plus/work/develop/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so
#1 Foam::error::simpleExit(int, bool) in ~/OpenFOAM/OpenFOAM-plus/work/develop/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so
#2 Foam::error::exiting(int, bool) in ~/OpenFOAM/OpenFOAM-plus/work/develop/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so
#3 Foam::Ostream& Foam::operator<< <Foam::error>(Foam::Ostream&, Foam::errorManip<Foam::error>) at ~/OpenFOAM/OpenFOAM-plus/work/develop/src/OpenFOAM/lnInclude/errorManip.H:93 (discriminator 4)
#4 Foam::UList<double>::checkIndex(int) const at ~/OpenFOAM/OpenFOAM-plus/work/develop/src/OpenFOAM/lnInclude/UListI.H:169
#5 Foam::UList<double>::operator[](int) at ~/OpenFOAM/OpenFOAM-plus/work/develop/src/OpenFOAM/lnInclude/UListI.H:304
#6 Foam::fvGeometryScheme::setMeshPhi() const at ~/OpenFOAM/OpenFOAM-plus/work/develop/src/finiteVolume/fvMesh/fvGeometryScheme/fvGeometryScheme/fvGeometryScheme.C:103 (discriminator 2)
#7 Foam::fvGeometryScheme::movePoints() at ~/OpenFOAM/OpenFOAM-plus/work/develop/src/finiteVolume/fvMesh/fvGeometryScheme/fvGeometryScheme/fvGeometryScheme.C:159
#8 Foam::basicFvGeometryScheme::movePoints() in ~/OpenFOAM/OpenFOAM-plus/work/develop/platforms/linux64GccDPInt32Opt/lib/libfiniteVolume.so
#9 Foam::surfaceInterpolation::updateGeom() in ~/OpenFOAM/OpenFOAM-plus/work/develop/platforms/linux64GccDPInt32Opt/lib/libfiniteVolume.so
#10 Foam::primitiveMesh::faceCentres() const in ~/OpenFOAM/OpenFOAM-plus/work/develop/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so
#11 Foam::polyPatch::faceCentres() const in ~/OpenFOAM/OpenFOAM-plus/work/develop/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so
#12 Foam::cyclicAMIPolyPatch::calcTransforms() at ~/OpenFOAM/OpenFOAM-plus/work/develop/src/meshTools/AMIInterpolation/patches/cyclicAMI/cyclicAMIPolyPatch/cyclicAMIPolyPatch.C:472
#13 Foam::cyclicAMIPolyPatch::initGeometry(Foam::PstreamBuffers&) at ~/OpenFOAM/OpenFOAM-plus/work/develop/src/meshTools/AMIInterpolation/patches/cyclicAMI/cyclicAMIPolyPatch/cyclicAMIPolyPatch.C:497
#14 Foam::polyBoundaryMesh::calcGeometry() in ~/OpenFOAM/OpenFOAM-plus/work/develop/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so
#15 Foam::polyMesh::resetPrimitives(Foam::autoPtr<Foam::Field<Foam::Vector<double> > >&&, Foam::autoPtr<Foam::List<Foam::face> >&&, Foam::autoPtr<Foam::List<int> >&&, Foam::autoPtr<Foam::List<int> >&&, Foam::UList<int> const&, Foam::UList<int> const&, bool) in ~/OpenFOAM/OpenFOAM-plus/work/develop/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so
#16 Foam::polyTopoChange::changeMesh(Foam::polyMesh&, Foam::UList<int> const&, bool, bool, bool, bool) in ~/OpenFOAM/OpenFOAM-plus/work/develop/platforms/linux64GccDPInt32Opt/lib/libmeshTools.so
#17 Foam::polyTopoChange::changeMesh(Foam::polyMesh&, bool, bool, bool, bool) in ~/OpenFOAM/OpenFOAM-plus/work/develop/platforms/linux64GccDPInt32Opt/lib/libmeshTools.so
#18 Foam::fvMeshAdder::add(int, Foam::UPtrList<Foam::fvMesh>&, Foam::List<int> const&, Foam::List<Foam::List<int> > const&, Foam::List<Foam::List<int> > const&, Foam::List<Foam::List<int> > const&, Foam::List<Foam::List<int> >&, Foam::List<Foam::List<int> >&, Foam::List<Foam::List<int> >&, Foam::List<Foam::List<int> >&) in ~/OpenFOAM/OpenFOAM-plus/work/develop/platforms/linux64GccDPInt32Opt/lib/libdynamicMesh.so
#19 ? at ~/OpenFOAM/OpenFOAM-plus/work/develop/applications/utilities/parallelProcessing/reconstructParMesh/reconstructParMesh.C:1142
#20 __libc_start_main in /lib64/libc.so.6
#21 ? at /home/abuild/rpmbuild/BUILD/glibc-2.31/csu/../sysdeps/x86_64/start.S:122
```
### 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
-->
- problem is that the cyclicAMI triggers the fvMeshGemoetry::meshPhi() calculation when trying to find out the patch face correspondence and transformations
- not trigger fvGeometryScheme::setPhi before all is mapped? inside fvGeometryScheme?
- delete mesh.phi() before fvGeometryScheme::movePoints gets called (e.g. inside reconstructParMesh) (still should be reconstructed afterwards)
- can unset mesh.moving() inside reconstructParMesh but that also then gets rid of reconstruction of points0, meshPhi
- change tutorial to delete the points0, meshPhi files before running the reconstructParMesh (same problem)
- extend redistributePar -reconstruct to work on topology change cases.https://develop.openfoam.com/Development/openfoam/-/issues/2488redistributePar -decompose with inconsistent nProcs2024-01-08T13:36:51ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comredistributePar -decompose with inconsistent nProcs### Functionality to add/problem to solve
redistributePar -decompose gives illogical error message if the number of procs does not equal the number in the decomposeParDict. E.g. in decomposeParDict:
```
numberOfSubdomains 2;
```
Run wi...### Functionality to add/problem to solve
redistributePar -decompose gives illogical error message if the number of procs does not equal the number in the decomposeParDict. E.g. in decomposeParDict:
```
numberOfSubdomains 2;
```
Run with
```
mpirun -np 4 redistributePar -decompose -parallel
```
Produces output
```
[0] --> FOAM FATAL ERROR: (openfoam-2202 patch=220310)
[0] number of processor directories = 1 is not equal to the number of processors = 4
```
which is not very helpful.https://develop.openfoam.com/Development/openfoam/-/issues/768redistributePar does not do DimensionedFields2021-07-06T12:29:16ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comredistributePar does not do DimensionedFieldsMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/2489redistributePar on moving mesh cases2022-05-26T10:36:15ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comredistributePar on moving mesh cases<!--
*** 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
1)
<!-- Summarize the bug encountered concisely -->
redistributePar -decompose on case with 'meshPhi' produces error message
2)
redistributePar -reconstruct flips meshPhi
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Take time dump of any moving mesh case with meshPhi. Use
```
mpirun -np 2 redistributePar -decompose -parallel -time XXX
```
and it will produce error message
```
From time 0.025 mesh:"constant/region0" have objects:
16
(
controlPoints
pointMotionU
C_0
Cs
cellMotionU
U
U_0
fsNetPhi
Uf
phi
C
V0
meshPhi
p
Uf_0
Us
)
[0]
[0]
[0] --> FOAM FATAL ERROR: (openfoam-2202 patch=220310)
[0] mesh flux field does not exist, is the mesh actually moving?
[0]
[0] From Foam::surfaceScalarField& Foam::fvMesh::setPhi()
[0] in file fvMesh/fvMeshGeometry.C at line 422.
[0]
FOAM parallel run aborting
[0]
[0] #0 Foam::error::printStack(Foam::Ostream&) at ??:?
[0] #1 Foam::error::simpleExit(int, bool) at ??:?
[0] #2 Foam::error::exiting(int, bool) at ??:?
[0] #3 Foam::fvMesh::setPhi() at ??:?
[0] #4 Foam::fvGeometryScheme::setMeshPhi() const at ??:?
[0] #5 Foam::fvGeometryScheme::movePoints() at ??:?
[0] #6 Foam::basicFvGeometryScheme::movePoints() at ??:?
[0] #7 Foam::surfaceInterpolation::updateGeom() at ??:?
[0] #8 Foam::primitiveMesh::cellVolumes() const at ??:?
[0] #9 Foam::polyTopoChange::changeMesh(Foam::polyMesh&, Foam::UList<int> const&, bool, bool, bool, bool) at ??:?
[0] #10 Foam::polyTopoChange::changeMesh(Foam::polyMesh&, bool, bool, bool, bool) at ??:?
[0] #11 Foam::fvMeshDistribute::repatch(Foam::List<int> const&, Foam::List<Foam::List<int> >&) at ??:?
[0] #12 Foam::fvMeshDistribute::deleteProcPatches(int) at ??:?
[0] #13 Foam::fvMeshDistribute::distribute(Foam::List<int> const&) at ??:?
```
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v2112|v2106|v2012|v2006|v1912|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2202
- Operating system :
- 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
-->
Switch on mesh.moving() flag?https://develop.openfoam.com/Development/openfoam/-/issues/1937redistributePar produces illogical warning message2024-01-05T16:59:11ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comredistributePar produces illogical warning message<!--
*** 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 -->
redistributePar uses internally fvMeshSubset to subset mesh+fields to send to other processors. Exposed internal faces will produce a warning for any boundary condition holding per-face information (e.g. fixedValue v.s. uniformFixedValue).
Since the bits will get stitched later on there is actually no use for the warning message - it is just due to the current implementation.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Eg in `tutorials/incompressible/simpleFoam/pitzDaily` :
```
mpirun -np 2 redistributePar -decompose -parallel
```
This will give a warning:
```
--> FOAM Warning :
From Foam::fixedValueFvPatchField<Type>::fixedValueFvPatchField(const Foam::fixedValueFvPatchField<Type>&, const Foam::fvPatch&, const Foam::DimensionedField<Type, Foam::volMesh>&, const Foam::fvPatchFieldMapper&) [with Type = double]
in file src/finiteVolume/lnInclude/fixedValueFvPatchField.C at line 81
On field subsetepsilon patch lowerWall patchField fixedValue : mapper does not map all values.
To avoid this warning fully specify the mapping in derived patch fields.
```
### 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 : <= v2006Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/602redistributePar -reconstruct produces different phi field w.r.t. reconstructPar2024-01-10T16:22:29ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comredistributePar -reconstruct produces different phi field w.r.t. reconstructPar- take parallel/filter tutorial
- reconstruct time 0.8 (using ascii, 16 digits writeprecision) with both
```
reconstructPar -time 0.8
mpirun -np 3 redistributePar -reconstruct -time 0.8
```
The phi field differs in the last digits on som...- take parallel/filter tutorial
- reconstruct time 0.8 (using ascii, 16 digits writeprecision) with both
```
reconstructPar -time 0.8
mpirun -np 3 redistributePar -reconstruct -time 0.8
```
The phi field differs in the last digits on some faces.https://develop.openfoam.com/Development/openfoam/-/issues/3032redistributePar slow with preservePatches cosntraint2023-11-23T07:14:20ZTimofey MukharedistributePar slow with preservePatches cosntraintFollow-up to #2924, but not necessarily related in terms of what causes the issue.
To reliably decompose cyclic boundaries with `redistributePar` we currently need to use the `preservePatches` constraint for the cyclic boundaries. Unfor...Follow-up to #2924, but not necessarily related in terms of what causes the issue.
To reliably decompose cyclic boundaries with `redistributePar` we currently need to use the `preservePatches` constraint for the cyclic boundaries. Unfortunately, this seems to cause a strong dip in performance of the utility. According to @Mattijs this should not really happen. I have first observed this on my own case, but now got some numbers using the `periodicHill` tutorial.
I use the `steadyState` case in the tutorial, bump the number of processors in `decomposeParDict` to 32, and accordingly switch to 4 partitions along y. Additionally, we add
```
constraints
{
patches
{
//- Keep owner and neighbour on same processor for faces in patches
// (only makes sense for cyclic patches and cyclicAMI)
type preservePatches;
patches (inlet outlet);
}
}
```
which we can comment and uncomment to compare.
Furthermore, it is better to make the case a bit larger, so in `blockMeshDict` we set the size of the `hex` to `(200 160 400)`, and then run `blockMesh`.
Now, we decompose the case with
`time mpirun -n 32 redistributePar -decompose -latestTime -parallel -fileHandler collated`
On my machine, I get a 3x slowdown when preserving the patches.https://develop.openfoam.com/Development/openfoam/-/issues/3105redistributePar (with cyclicAMI) to more processors2024-03-18T12:15:41ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comredistributePar (with cyclicAMI) to more processors<!--
*** 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 -->
Changing decomposeParDict to be more processors and running `redistributePar -parallel` hangs.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
```
cd tutorials/incompressible/pimpleFoam/laminar/mixerVesselAMI2D/mixerVesselAMI2D
decomposePar (into e.g. 4 processors)
```
In `system/controlDict` change to `startFrom latestTime` and `stopAt writeNow`. Change decomposeParDict to use more processors (e.g. 8) and `mpirun -np 8 redistributePar -parallel`. This hangs - processors that already have mesh get stuck in `Foam::fvMesh::init`. Processors that are new get stuck in earlier code:
```
15 0x00007f2c1eecb930 in Foam::IOobject::readAndCheckHeader(bool, Foam::word const&, bool, bool, bool) () from develop/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so
#16 0x00007f2c215fae69 in Foam::fvMesh::init(bool) () from develop/platforms/linux64GccDPInt32Opt/lib/libfiniteV
```
### Example case
See above.
<!--
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?
See above.
<!-- What actually happens -->
### What is the expected *correct* behavior?
Write redistributed mesh to new time directory, including on the new processors.
<!-- What you should see instead -->
### Relevant logs and/or images
<!--
Paste any relevant logs - please use code blocks (```) to format console
output, logs, and code as it's very hard to read otherwise.
-->
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v2312|v2306|v2212|v2206|v2112 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version :v2312
- Operating system :
- 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
-->
@markhttps://develop.openfoam.com/Development/openfoam/-/issues/2231reduce/improve library settings for paraview/vtk2021-10-07T06:51:41ZMark OLESENreduce/improve library settings for paraview/vtkMore recent paraview versions do not an explicit LD_LIBRARY_PATH to run so this setting can be removed from the config.sh/ entry.
Verified with a fresh ParaView build/install under /tmp/make-thirdparty. Used these locations when buildin...More recent paraview versions do not an explicit LD_LIBRARY_PATH to run so this setting can be removed from the config.sh/ entry.
Verified with a fresh ParaView build/install under /tmp/make-thirdparty. Used these locations when building the PV-Plugins (aka, paraFoam modules). Relocated ParaView to the usual ThirdParty/platforms locations. Plugins load correctly.
Will need an additional mechanism to specify `libpaths` for catalyst and runTimePostProcessing though.
[0001-CONFIG-newer-paraview-finds-its-own-libraries.patch](/uploads/86bae44b982821277e68fe24903f94c8/0001-CONFIG-newer-paraview-finds-its-own-libraries.patch)