Development issueshttps://develop.openfoam.com/groups/Development/-/issues2023-06-30T15:04:24Zhttps://develop.openfoam.com/Development/openfoam/-/issues/2725changeDictionary does not work for multiple regions (i. e. for chtMultiRegion...2023-06-30T15:04:24ZMarco MüllerchangeDictionary does not work for multiple regions (i. e. for chtMultiRegionFoam) on mingw cross compilation### Summary
based on what I see, only the last solid region in the regionProperties lists can be handled with changeDictionary. All other regions abort.
### Steps to reproduce
run i. e. chtMultiRegionFoam\multiRegionHeater tutorial
...### Summary
based on what I see, only the last solid region in the regionProperties lists can be handled with changeDictionary. All other regions abort.
### Steps to reproduce
run i. e. chtMultiRegionFoam\multiRegionHeater tutorial
### What is the current *bug* behaviour?
changeDictionary sets the dictionaries correctly
### What is the expected *correct* behavior?
changeDictionary aborts
### Relevant logs and/or images
i.e. log.changeDictionary.leftSolid (unicode character 0x80 at the end):
...
Create mesh leftSolid
for time = 0
fileName::stripInvalid() called for invalid fileName leftSolid
For debug level (= 2) > 1 this is considered fatal
### Environment information
- OpenFOAM version : tested v2212|v2206|v2112|v2106|v2012|v2006
- Operating system : Win 10
- Hardware info :
- Compiler :https://develop.openfoam.com/Development/openfoam/-/issues/2724inverse of singular or small tensors is still fragile2023-06-13T18:09:43ZMark OLESENinverse of singular or small tensors is still fragileFor very small tensors, the pseudo-inverse provides a more robust, but potentially more costly approach.
Oddly, within the symmTensorField.C there is special trapping of 2D cases, but the detection and adjustment are only triggered base...For very small tensors, the pseudo-inverse provides a more robust, but potentially more costly approach.
Oddly, within the symmTensorField.C there is special trapping of 2D cases, but the detection and adjustment are only triggered based on the first element (which is probably not robust enough).Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2723avoid register/deregister of tmp fields2024-02-21T13:32:54ZMark OLESENavoid register/deregister of tmp fieldsBy default IOobject uses (REGISTER). When a tmp field is created, its name will be registered in the corresponding objectRegistry (invoking an allocation to add to the HashTable, plus calculation of a hash value etc). If the tmp leaves s...By default IOobject uses (REGISTER). When a tmp field is created, its name will be registered in the corresponding objectRegistry (invoking an allocation to add to the HashTable, plus calculation of a hash value etc). If the tmp leaves scope immediately, it is removed from the registry which incurs another delete in addition to that of the tmp itself.https://develop.openfoam.com/Development/openfoam/-/issues/2722BUG: Error in setReference behaviour with moving mesh, correctPhi and paralle...2023-04-06T12:16:12ZJohan RoenbyBUG: Error in setReference behaviour with moving mesh, correctPhi and parallel runI have noticed generation of spurious bubble generation in the bulk of the liquid when working with interIsoFoam or interFoam combined with moving mesh in parallel and using correctPhi in fvSolution->PIMPLE. My investigations indicate th...I have noticed generation of spurious bubble generation in the bulk of the liquid when working with interIsoFoam or interFoam combined with moving mesh in parallel and using correctPhi in fvSolution->PIMPLE. My investigations indicate that there is a bug in the setting of the reference pressure (fvMatrix::setReference).
I have attached a minimal test case to this issue report which illustrates the problem. The case is based on v2206. The case is a simple square domain filled water and oscillating sinusoidally back and forth with a coded dynamicMeshDict. The case only includes 1 time step since this is enough for the problem to arise. To reproduce the problem, simply run the Allrun script in the case and look with paraview at the alpha.water values in the bottom of the domain (load the state.pvsm file to also see phi vectors). What you see is overshoot in the leftmost cell, which is cell 0 in processor0, and a corresponding undershoot in the leftmost cell (label 0) at the bottom of processor1:
![Udklip](/uploads/b95d10e0d21fc6361fd4f40110f3601f/Udklip.JPG)
The problem happens with both interFoam and interIsoFoam.
The flow is not solved (frozenFlow), but the correctPhi is set to "yes" in fvSolution->PIMPLE.
If correctPhi is set to "no" the problem disappears.
If the case is run in serial, the problem disappears.
If an "atmosphere" inlet/outlet is added to the top, so that no reference pressure is set, the problem disappears.
If I use 4 or 16 subdomains in decomposeParDict instead of 2, it is clear that it is the 0'th cell on each processor that is over- or undershooting in alpha.water:
![Picture1](/uploads/8e90bd9852dfe04ca193d2c1d0460e30/Picture1.png)
In the case, phi is corrected in the first time step using CorrectPhi(...). The Foam::CorrectPhi function has hardcoded cell 0 to be the reference cell:
pcorrEqn.setReference(0, 0);
If I change this to pcorrEqn.setReference(2, 0), I observe that the problematic cells move two cells to the right.
I assume that there should not be a reference cell for each processor, but a single reference cell on the entire domain to which all other cell pressures should refer.
Plotting phi-vectors in paraview, as done with the state.pvsm file supplied with the case, I have confirmed that the alpha.water over- and undershooting arise due to nonzero div(phi) where phi is the corrected phi from CorrectPhi.
Does anyone have an idea for how to fix this problem?
Test case: [oscillatingTank.zip](/uploads/50eae14bdb13ea752164a5845bee446e/oscillatingTank.zip)https://develop.openfoam.com/Development/openfoam/-/issues/2720Build from Source Failed GCC 11.2.0 (WSL)2023-04-06T10:08:08ZBrandon DentonBuild from Source Failed GCC 11.2.0 (WSL)OpenFOAM v2212 won't compile from source. When following the wiki's instructions, the following errors result. Configuration details are provided below. I'm not sure how to fix the "error: ‘memchr’ has not been declared in ‘::’" error.
...OpenFOAM v2212 won't compile from source. When following the wiki's instructions, the following errors result. Configuration details are provided below. I'm not sure how to fix the "error: ‘memchr’ has not been declared in ‘::’" error.
```
Compiling enabled on 16 cores
gcc=/mnt/c/Users/Brandon/software/apps/gcc/11.2.0/bin/gcc
clang=
mpirun=/mnt/c/Users/Brandon/software/libs/openmpi/4.1.5/gcc/11.2.0/bin/mpirun
make=/usr/bin/make
cmake=/mnt/c/Users/Brandon/software/apps/cmake/3.22.0/bin/cmake
wmake=/mnt/c/Users/Brandon/software/builddir/OpenFOAM-v2212/wmake/wmake
m4=/usr/bin/m4
flex=/usr/bin/flex
compiler=/mnt/c/Users/Brandon/software/apps/gcc/11.2.0/bin/g++
g++ (GCC) 11.2.0
========================================
2023-03-07 19:05:43 -0500
Starting compile OpenFOAM-v2212 Allwmake
Gcc system compiler []
linux64GccDPInt64Opt, with SYSTEMOPENMPI sys-openmpi
========================================
built wmake-bin (linux64Gcc)
========================================
Compile OpenFOAM libraries
========================================
ln: OpenFOAM/lnInclude
ln: OSspecific/POSIX/lnInclude
wmake libo (POSIX)
dep: fileMonitor.C
dep: fileStat.C
dep: regExpPosix.C
dep: printStack.C
dep: sigQuit.C
dep: timer.C
dep: sigWriteNow.C
dep: sigStopAtWriteNow.C
dep: sigInt.C
dep: sigSegv.C
dep: memInfo.C
dep: sigFpe.C
dep: POSIX.C
dep: cpuInfo.C
dep: cpuTimePosix.C
Ctoo: sigFpe.C
Ctoo: memInfo.C
Ctoo: cpuTimePosix.C
Ctoo: sigInt.C
Ctoo: cpuInfo.C
Ctoo: POSIX.C
Ctoo: sigSegv.C
Ctoo: sigQuit.C
Ctoo: sigStopAtWriteNow.C
Ctoo: timer.C
Ctoo: regExpPosix.C
Ctoo: fileStat.C
Ctoo: sigWriteNow.C
Ctoo: fileMonitor.C
Ctoo: printStack.C
In file included from /mnt/c/Users/Brandon/software/builddir/OpenFOAM-v2212/src/OpenFOAM/lnInclude/string.H:56,
from /mnt/c/Users/Brandon/software/builddir/OpenFOAM-v2212/src/OpenFOAM/lnInclude/word.H:46,
from /mnt/c/Users/Brandon/software/builddir/OpenFOAM-v2212/src/OpenFOAM/lnInclude/fileName.H:51,
from /mnt/c/Users/Brandon/software/builddir/OpenFOAM-v2212/src/OpenFOAM/lnInclude/fileNameList.H:49,
from /mnt/c/Users/Brandon/software/builddir/OpenFOAM-v2212/src/OpenFOAM/lnInclude/OSspecific.H:42,
from memInfo/memInfo.C:30:
/mnt/c/Users/Brandon/software/apps/gcc/11.2.0/include/c++/11.2.0/cstring:77:11: error: ‘memchr’ has not been declared in ‘::’
77 | using ::memchr;
| ^~~~~~
/mnt/c/Users/Brandon/software/apps/gcc/11.2.0/include/c++/11.2.0/cstring:78:11: error: ‘memcmp’ has not been declared in ‘::’
78 | using ::memcmp;
| ^~~~~~
/mnt/c/Users/Brandon/software/apps/gcc/11.2.0/include/c++/11.2.0/cstring:79:11: error: ‘memcpy’ has not been declared in ‘::’
79 | using ::memcpy;
| ^~~~~~
/mnt/c/Users/Brandon/software/apps/gcc/11.2.0/include/c++/11.2.0/cstring:80:11: error: ‘memmove’ has not been declared in ‘::’
80 | using ::memmove;
| ^~~~~~~
/mnt/c/Users/Brandon/software/apps/gcc/11.2.0/include/c++/11.2.0/cstring:81:11: error: ‘memset’ has not been declared in ‘::’
81 | using ::memset;
| ^~~~~~
/mnt/c/Users/Brandon/software/apps/gcc/11.2.0/include/c++/11.2.0/cstring:82:11: error: ‘strcat’ has not been declared in ‘::’
82 | using ::strcat;
| ^~~~~~
/mnt/c/Users/Brandon/software/apps/gcc/11.2.0/include/c++/11.2.0/cstring:83:11: error: ‘strcmp’ has not been declared in ‘::’
83 | using ::strcmp;
| ^~~~~~
/mnt/c/Users/Brandon/software/apps/gcc/11.2.0/include/c++/11.2.0/cstring:84:11: error: ‘strcoll’ has not been declared in ‘::’
84 | using ::strcoll;
| ^~~~~~~
/mnt/c/Users/Brandon/software/apps/gcc/11.2.0/include/c++/11.2.0/cstring:85:11: error: ‘strcpy’ has not been declared in ‘::’
85 | using ::strcpy;
| ^~~~~~
/mnt/c/Users/Brandon/software/apps/gcc/11.2.0/include/c++/11.2.0/cstring:86:11: error: ‘strcspn’ has not been declared in ‘::’
86 | using ::strcspn;
| ^~~~~~~
/mnt/c/Users/Brandon/software/apps/gcc/11.2.0/include/c++/11.2.0/cstring:87:11: error: ‘strerror’ has not been declared in ‘::’
87 | using ::strerror;
| ^~~~~~~~
/mnt/c/Users/Brandon/software/apps/gcc/11.2.0/include/c++/11.2.0/cstring:88:11: error: ‘strlen’ has not been declared in ‘::’
88 | using ::strlen;
| ^~~~~~
/mnt/c/Users/Brandon/software/apps/gcc/11.2.0/include/c++/11.2.0/cstring:89:11: error: ‘strncat’ has not been declared in ‘::’
89 | using ::strncat;
| ^~~~~~~
/mnt/c/Users/Brandon/software/apps/gcc/11.2.0/include/c++/11.2.0/cstring:90:11: error: ‘strncmp’ has not been declared in ‘::’
90 | using ::strncmp;
| ^~~~~~~
/mnt/c/Users/Brandon/software/apps/gcc/11.2.0/include/c++/11.2.0/cstring:91:11: error: ‘strncpy’ has not been declared in ‘::’
91 | using ::strncpy;
| ^~~~~~~
/mnt/c/Users/Brandon/software/apps/gcc/11.2.0/include/c++/11.2.0/cstring:92:11: error: ‘strspn’ has not been declared in ‘::’
92 | using ::strspn;
| ^~~~~~
/mnt/c/Users/Brandon/software/apps/gcc/11.2.0/include/c++/11.2.0/cstring:93:11: error: ‘strtok’ has not been declared in ‘::’
93 | using ::strtok;
| ^~~~~~
/mnt/c/Users/Brandon/software/apps/gcc/11.2.0/include/c++/11.2.0/cstring:94:11: error: ‘strxfrm’ has not been declared in ‘::’
94 | using ::strxfrm;
| ^~~~~~~
/mnt/c/Users/Brandon/software/apps/gcc/11.2.0/include/c++/11.2.0/cstring:95:11: error: ‘strchr’ has not been declared in ‘::’
95 | using ::strchr;
| ^~~~~~
/mnt/c/Users/Brandon/software/apps/gcc/11.2.0/include/c++/11.2.0/cstring:96:11: error: ‘strpbrk’ has not been declared in ‘::’
96 | using ::strpbrk;
| ^~~~~~~
/mnt/c/Users/Brandon/software/apps/gcc/11.2.0/include/c++/11.2.0/cstring:97:11: error: ‘strrchr’ has not been declared in ‘::’
97 | using ::strrchr;
| ^~~~~~~
/mnt/c/Users/Brandon/software/apps/gcc/11.2.0/include/c++/11.2.0/cstring:98:11: error: ‘strstr’ has not been declared in ‘::’
98 | using ::strstr;
| ^~~~~~
```https://develop.openfoam.com/Development/openfoam/-/issues/2719TopoSet shows wrong cell/face count while running in parallel (only showing m...2023-03-10T17:47:09ZTobias HolzmannTopoSet shows wrong cell/face count while running in parallel (only showing master counts)<!--
*** 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
Hey all, during some tests I figured out that topoSet is showing wrong face/cell counts in the output while running in parallel. Its simply a problem of the outputted text but this should be fixed as well as it is somehow non conservative.
<!-- Summarize the bug encountered concisely -->
### Steps to reproduce
Run the motorbike tutorial (incompressible/simpleFoam/motorBike) and add the following line to the topoSetDict:
```
{
name testWallFaceSet;
type faceSet;
action new;
source patchToFace;
patch lowerWall;
}
```
after `topoSet` is executed in parallel we get the following output:
```
Time = 0
mesh not changed.
Created cellZoneSet inner
Applying source boxToCell
Adding cells with centre within boxes 1((-1 -0.5 0) (6 0.5 2))
cellZoneSet inner now size 253135
Created faceSet lowerWallFaces
Applying source patchToFace
Adding all faces of patches (lowerWall) ...
Found matching patch lowerWall with **662 **faces.
faceSet lowerWallFaces now size **5349**
End
```
As one can see, the output of faces for the *lowerWall* is **662** (which comes from the master proc). However, the total number of faces is **5349** as given in the output as well. Hence, people might be confused.
### What is the current *bug* behaviour?
The output of faces/cell count is related to the master proc.
<!-- What actually happens -->
### What is the expected *correct* behavior?
The output should include the complete amount of cells/faces of all procs.
<!-- What you should see instead -->
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v2212|v2206|v2112|v2106|v2012 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2212
### Possible fixes
Probably a global reduction of the data is missing and hence, only the master proc data is used.
<!--
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/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/2717SelectionMode geometric requires cellZone name in DarcyForchheimer fvOptions2023-03-13T13:49:27ZTobias HolzmannSelectionMode geometric requires cellZone name in DarcyForchheimer fvOptions<!--
*** 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
-->
As described by @Prashant in EP2090 the selectionMode namely geometric can be used within the DarcyForchheimer model but we need also to specify the keyword "cellZone" while specifying a cellZone in addition. This does not make sense and is inconsistent as the cellZone is comming from the geometric selection mode.
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
<!-- Summarize the bug encountered concisely -->
### Steps to reproduce
Add an fvOption in such a way:
```
porousity
{
type explicitPorositySource;
active true;
explicitPorositySourceCoeffs
{
type DarcyForchheimer;
d d [0 -2 0 0 0 0 0] (1e12 1e12 1e12);
f f [0 -1 0 0 0 0 0] (0 0 0);
coordinateSystem
{
origin (0 0 0);
e1 (1 0 0);
e2 (0 1 0);
}
selectionMode geometric;
selection
{
box
{
action use;
source box;
min (0 -1 -1);
max (1 0 1);
}
}
}
}
```
<!-- How one can reproduce the issue - this is very important -->
### Example case
Any tutorial 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?
Selection mode "geometric" requires a cellZone in addition.
<!-- What actually happens -->
### What is the expected *correct* behavior?
Selection mode "geometric" should be usable without specification of a cellZone
<!-- 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 : v2212|v2206|v2112|v2106|v2012 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2212
- Operating system :
- Hardware info :
- Compiler :Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2716OpenFOAM-v1912 with ParaView-5.10.1 with error: Cannot use ParaView reader mo...2023-12-29T11:28:04ZC SOpenFOAM-v1912 with ParaView-5.10.1 with error: Cannot use ParaView reader module library (PVFoamReader) The PV_PLUGIN_PATH environment value is not setI've installed **OpenFOAM-v1912** in Linux desktop environment with **ParaView version 5.10.1** along with **Aerosolved library**.
I tried to test run the cavity tutorial from foam, but failed with errors shown as:
**Cannot use ParaView...I've installed **OpenFOAM-v1912** in Linux desktop environment with **ParaView version 5.10.1** along with **Aerosolved library**.
I tried to test run the cavity tutorial from foam, but failed with errors shown as:
**Cannot use ParaView reader module library (PVFoamReader)
The PV_PLUGIN_PATH environment value is not set**
May I know why?
The steps were entering directory cavity in $FOAM_RUN directory,
then blockMesh
then paraFoam &
and the errors popped up as shown in the figure below.
![image](/uploads/c6e56bf1fd00085b0683395e74284865/image.png)
It does linking to the ParaView, but with no figure there.
![image](/uploads/51211298e86de260f628f46aa45a09b9/image.png)
May I know where I did wrongly? Please correct me.
Thank you in advanced.
Regards,
Cindyhttps://develop.openfoam.com/Development/openfoam/-/issues/2715Improved point-cell and cell-point topology methods2023-03-05T09:57:06ZMark OLESENImproved point-cell and cell-point topology methodsOptimization potential when building cell/point and point/cell connectivity. !596Optimization potential when building cell/point and point/cell connectivity. !596https://develop.openfoam.com/Development/openfoam/-/issues/2714compilation changes for gcc-13 and/or c++17/20 etc2023-03-05T09:56:24ZMark OLESENcompilation changes for gcc-13 and/or c++17/20 etccross-refs
- https://bugzilla.redhat.com/show_bug.cgi?id=1816301
- https://gcc.gnu.org/gcc-13/porting_to.htmlcross-refs
- https://bugzilla.redhat.com/show_bug.cgi?id=1816301
- https://gcc.gnu.org/gcc-13/porting_to.htmlMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2713searchbox in the overset is expected to move along the motion of the object, ...2023-02-24T08:35:34Zgrace wsearchbox in the overset is expected to move along the motion of the object, rather than fixed in the space### Functionality to add/problem to solve
(Brief scope)
In overset function, searchbox is set to narrow the search area and improve the hole-search efficiency. However, the searchbox is fixed in the mesh, other than moving along with t...### Functionality to add/problem to solve
(Brief scope)
In overset function, searchbox is set to narrow the search area and improve the hole-search efficiency. However, the searchbox is fixed in the mesh, other than moving along with the object.
### Target audience
(Who will benefit from the changes?)
(What type of cases?)
The efficiency of overset function can be benefited by setting the searchbox moving along the object.
### Proposal
(How are we going to solve the problem?)
1 extract the mesh motion from Mesh class, 2 add the mesh motion to searchbox, which reduces the size of the searchbox and improve the efficiency of the overset mesh.
I find the motion is calculated from transformation and transformPoints. I would like to isolate the displacement for searchbox motion.
### What does success look like, and how can we measure that?
(What are the success factors and acceptance criteria? e.g. test cases, error margins)
I think the tutorial case can be a test case.https://develop.openfoam.com/Development/openfoam/-/issues/2712Add thousand separators to meshing utility output2023-02-28T23:15:09ZGuanyang XueAdd thousand separators to meshing utility output### Functionality to add/problem to solve
Adding thousand separators to the output so it's easier for human to read long integers.
### Target audience
All meshing utilities (and probably some other applications)
### Proposal
Add s...### Functionality to add/problem to solve
Adding thousand separators to the output so it's easier for human to read long integers.
### Target audience
All meshing utilities (and probably some other applications)
### Proposal
Add some code to `messageStream` when printing integers
### What does success look like, and how can we measure that?
For example the current output of `blockMesh` is like
```
Mesh Information
----------------
boundingBox: (0 -0.0005 0) (0.012 0.0005 5e-05)
nPoints: 4911759
nCells: 4729600
nFaces: 14369360
nInternalFaces: 14008240
----------------
```
Adding thousand separators to integers will make it much easier to read.
```
Mesh Information
----------------
boundingBox: (0 -0.0005 0) (0.012 0.0005 5e-05)
nPoints: 4,911,759
nCells: 4,729,600
nFaces: 14,369,360
nInternalFaces: 14,008,240
----------------
```
### Links / references
You don't need to write any code to parse numbers. C++ has built-in functions to do that.
https://cplusplus.com/reference/locale/numpunct/https://develop.openfoam.com/Development/openfoam/-/issues/2711dynamicOversetFvMesh with displacementLaplacian/velocityLaplacian does not pr...2023-11-09T15:05:13ZPhilip CardiffdynamicOversetFvMesh with displacementLaplacian/velocityLaplacian does not preserve zeroGradient on overset 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 -->
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
The bug can be observed by making a minor modification to `$FOAM_TUTORIALS/incompressible/overPimpleDyMFoam/cylinder`:
- Change the boundary condition for the `walls` patch in `cylinderAndBackground/0/pointDisplacement` to
- ```
walls
{
type oscillatingDisplacement;
amplitude (1 0 1);
omega 3.14;
value uniform (0 0 0);
}
```
I have attached this case (bug.cylinder.displacementLaplacian.tgz) below.
Incorrect behaviour can also be produced using the velocityLaplacian motion solver on this case instead of the displacementLaplacian solver; to reproduce this behaviour, make the following modifications to the same `cylinder` case:
- rename `cylinderAndBackground/0/pointDisplacement` to `cylinderAndBackground/0/pointMotionU`
- In the header of `cylinderAndBackground/0/pointMotionU`, update the `object` to `cellMotionU`
- In `cylinderAndBackground/0/pointMotionU`, change the `walls` boundary condition to:
- ```
walls
{
type fixedValue;
value uniform (1 0 1);
}
```
- In `cylinderAndBackground/constant/dynamicMeshDict`, replace `displacementLaplacian` with `velocityLaplacian`
- In `cylinderAndBackground/system/fvSolution`, replace `cellDisplacement` with `cellMotionU`
I have also attached this case (bug.cylinder.velocityLaplacian.tgz) below.
### 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
-->
As noted above, here are the two cases:
- [bug.cylinder.displacementLaplacian.tgz](/uploads/96db22f3dc5e08cf99d1471c9185cb17/bug.cylinder.displacementLaplacian.tgz)
- [bug.cylinder.velocityLaplacian.tgz](/uploads/33646d8b4e495ee03b2de1dea3b19ed3/bug.cylinder.velocityLaplacian.tgz)
### What is the current *bug* behaviour?
<!-- What actually happens -->
As the mesh boundary condition for the overset patch is `zeroGradient` (`overset { patchType overset; type zeroGradient; }`), I expect the overset mesh region around the cylinder to rigidly translate over the background mesh. However, in the two cases above, you will see that the overset mesh patch is not acting as `zeroGradient`. For the displacementLaplacian case, it seems to act as zero `fixedValue`, whereas, for the velocityLaplacian case, it seems to act as a normal overset patch (i.e. coupled to the background mesh).
As a result, in both cases, the simulation crashes due to extreme mesh deformations in the overset region.
### What is the expected *correct* behavior?
<!-- What you should see instead -->
The expected behaviour in both cases is that the overset mesh region rigidly translates over the background mesh and the background mesh does not move.
### 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.
-->
Here is an image of the mesh just before crashing in the displacementLaplacian case, where the overset patch mesh condition seems to act like `fixedValue`:
![pointDisplacement_field_before_crash](/uploads/11eca913b55c15a996031e3a4be80d62/pointDisplacement_field_before_crash.png)
Here is an image of the mesh just before crashing in the velocityLaplacian case, where the overset patch mesh condition seems to act like a normal `overset` condition:
![pointMotionU_field_before_crash](/uploads/073fbda728b4ebeab289c9fc5b96cc70/pointMotionU_field_before_crash.png)
With the user-fix proposed below, the correct behaviour is observed for both cases:
![pointDisplacement_field_with_fix](/uploads/dab91b541c3bcf53f02b2836512d5b07/pointDisplacement_field_with_fix.png)![pointMotionU_field_with_fix](/uploads/62b501584af8455fa6b3b760b7d96ac2/pointMotionU_field_with_fix.png)
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v2212
Operating system : ubuntu|macOS (should be the same on all)
Hardware info : N/A
Compiler : gcc|clang (should be independent of the compiler, but I have checked gcc on Ubuntu and clang on macOS
-->
- OpenFOAM version : v2212
- Operating system : I have chedk ubuntu and macOS but it should be the same on all OSes
- Hardware info : N/A
- Compiler : I checked gcc (on Ubuntu) and clang (on macOS) but it should be independent of the 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
-->
The problem seems to come from the construction of the boundary conditions for the `cellDisplacement` field in the displacementLaplacian class and the `cellMotionU` field in the velocityLaplacian class. The `zeroGradient` condition on the overset mesh patch does not seem to be correctly copied from the `pointDisplacement` and `pointMotionU` fields.
A simple user workaround is to provide the cell mesh motion fields in the case, including the correct boundary conditions on the overset patch. These user-provided fields are used because the cell fields are `READ_IF_PRESENT` in the displacementLaplacian and velocityLaplacian motion solvers.
For example, to fix the `displacementLaplacian` case, add the following `cellDisplacement` file to `cylinderAndBackground/0/`:
```
FoamFile
{
version 2.0;
format ascii;
class volVectorField;
object cellDisplacement;
}
dimensions [0 1 0 0 0 0 0];
internalField uniform (0 0 0);
boundaryField
{
overset
{
patchType overset;
type zeroGradient;
}
walls
{
type cellMotion;
value uniform (0 0 0);
}
".*"
{
type uniformFixedValue;
uniformValue (0 0 0);
}
}
```
Similarly, to fix the `velocityLaplacian` case, add the following `cellMotionU` file to `cylinderAndBackground/0/`:
```
FoamFile
{
version 2.0;
format ascii;
class volVectorField;
object cellMotionU;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
dimensions [0 1 0 0 0 0 0];
internalField uniform (0 0 0);
boundaryField
{
overset
{
patchType overset;
type zeroGradient;
}
walls
{
type cellMotion;
value uniform (0 0 0);
}
".*"
{
type uniformFixedValue;
uniformValue (0 0 0);
}
}
```
Here are the two modified cases:
- [fix.cylinder.displacementLaplacian.tgz](/uploads/a5dbd28c2c608f87e37705e4f1f17b56/fix.cylinder.displacementLaplacian.tgz)
- [fix.cylinder.velocityLaplacian.tgz](/uploads/4e952262f0b1087b2132dbd4f75b6a30/fix.cylinder.velocityLaplacian.tgz)
This user fix is a simple workaround; however, it would be better if this was fixed within the code, such that `zeroGradient` conditions on overset patches are correctly mapped from point fields to cell fields.https://develop.openfoam.com/Development/openfoam/-/issues/2710GAMG + processorAgglomeration + interpolateCorrection fails2024-01-08T11:02:44ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comGAMG + processorAgglomeration + interpolateCorrection fails<!--
*** 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 -->
Divide by zero when
- GAMG
- processorAgglomerator masterCoarsests;
- interpolateCorrection true;
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Any parallel case using GAMG. E.g. `pitzDaily` tutorial.
### What is the current *bug* behaviour?
<!-- What actually happens -->
Sigfpe since coarseLevel correction is not sent across when processor agglomerating. Instead the coarse-level correction stays zero for the missing/remote elements. This causes a divide by zero when normalising.
### What is the expected *correct* behavior?
<!-- What you should see instead -->
No failure.
### 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 : v2212|v2206|v2112|v2106|v2012 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2212
### 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
-->
Avoid accessing coarse-level when interpolating correction. Or send across coarse-level correction.Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/2709[Feature request] Macro expansion: Access keywords from separate files2024-01-10T16:36:52Zs1291[Feature request] Macro expansion: Access keywords from separate filesHello,
If I am not mistaken, It appears that OpenFOAM ESI versions do not provide a way to access external keywords from separate files.
OpenFOAM 9 and newer versions allow accessing keywords from separate files with the following synt...Hello,
If I am not mistaken, It appears that OpenFOAM ESI versions do not provide a way to access external keywords from separate files.
OpenFOAM 9 and newer versions allow accessing keywords from separate files with the following syntax:
```
aValue $FOAM_CASE/otherFile!foo;
```
`aValue` will have the value of `$foo` from the file `otherFile` within the case.
My workaround is to use a temporary dictionary with include to access the external keyword, e.g:
```
temp_dict
{
#include "otherFile"
}
aValue $temp_dict/foo;
#remove temp_dict
```
Is this feature already available that I am not aware of?
Thank youhttps://develop.openfoam.com/Development/openfoam/-/issues/2708Wrong equation of volume of injectedParticleInjection model and injectedParti...2023-06-12T14:31:12ZJunichi MukaiWrong equation of volume of injectedParticleInjection model and injectedParticleDistributionInjection model### Summary
The correct coefficient would be 1/6, not 1/16.
[InjectedParticleInjection.C](https://develop.openfoam.com/Development/openfoam/-/blob/master/src/lagrangian/intermediate/submodels/Kinematic/InjectionModel/InjectedParticleIn...### Summary
The correct coefficient would be 1/6, not 1/16.
[InjectedParticleInjection.C](https://develop.openfoam.com/Development/openfoam/-/blob/master/src/lagrangian/intermediate/submodels/Kinematic/InjectionModel/InjectedParticleInjection/InjectedParticleInjection.C#:~:text=scalar%20vol%20%3D%20pow3(diameter_%5Bi%5D)*mathematical%3A%3Api/16.0%3B)
[InjectedParticleDistributionInjection.C](https://develop.openfoam.com/Development/openfoam/-/blob/master/src/lagrangian/intermediate/submodels/Kinematic/InjectionModel/InjectedParticleDistributionInjection/InjectedParticleDistributionInjection.C#:~:text=const%20scalar%20volume%20%3D%20sumPow3*mathematical%3A%3Api/16.0%3B)v2306https://develop.openfoam.com/Development/openfoam/-/issues/2707extractEulerianParticles does not work correctly if it targets a faceZone on ...2023-02-22T08:55:52ZJunichi MukaiextractEulerianParticles does not work correctly if it targets a faceZone on a boundary with patchID of zero### Summary
All particles are discarded if target faceZone is on a boundary with patchID of zero.
### Steps to reproduce
1. Copy the tutorials of 'multiphase/interFoam/laminar/vofToLagrangian/eulerianInjection'.
2. Move the boundary ...### Summary
All particles are discarded if target faceZone is on a boundary with patchID of zero.
### Steps to reproduce
1. Copy the tutorials of 'multiphase/interFoam/laminar/vofToLagrangian/eulerianInjection'.
2. Move the boundary entry of the 'bottom' patch to first in system/blockMesh dictionary.
3. Exexute Allrun.
### Example case
[eulerianInjection.tar.gz](/uploads/6f95e6bafa0452e6ad4a2459e1c2fc85/eulerianInjection.tar.gz)
### Environment information
- OpenFOAM version : v2212
### Possible fixes
```
diff extractEulerianParticlesTemplates.C extractEulerianParticlesTemplates.C_fixed
46c46
< if (patchi != 0)
---
> if (patchi != -1)
```https://develop.openfoam.com/Development/openfoam/-/issues/2706globalIndex gather fails with multi-world2023-02-22T10:17:23ZMark OLESENglobalIndex gather fails with multi-worldAs noted in discussions with @andy - the globalIndex gather uses procIDs, but these are the subranks (in the parent), not the actual ranks for the communicator.
@MattijsAs noted in discussions with @andy - the globalIndex gather uses procIDs, but these are the subranks (in the parent), not the actual ranks for the communicator.
@MattijsMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2705dynamicRefineFVMesh support for Overset meshes2023-02-22T08:55:33ZMatt GuentherdynamicRefineFVMesh support for Overset meshes### Functionality to add/problem to solve
For ship simulations using overset mesh motion, the free surface interface is difficult to capture properly. If the background mesh is refined, the cell sizes are not matched well to the overset...### Functionality to add/problem to solve
For ship simulations using overset mesh motion, the free surface interface is difficult to capture properly. If the background mesh is refined, the cell sizes are not matched well to the overset mesh of the ship. By extending the existing capability of dynamicRefineFVMesh to be able to be applied to overset simulations, the free surface could be better defined.
### Target audience
For high speed vessels that have the most to gain from overset mesh due to their large mesh motions, the wave resistance is comparatively high, so good capture of the interface is important. This feature will increase interest in openfoam in a larger number of naval architecture companies.
High speed planing hulls with large displacement motion.
### Proposal
(How are we going to solve the problem?) Rework the dynamicMesh functionality to enable both dynamicRefineFVMesh and dynamicOversetFVMesh to be defined together.
### What does success look like, and how can we measure that?
(What are the success factors and acceptance criteria? e.g. test cases, error margins)
For a simple case, use the rigidbody test case found in overInterDYMFoam and extend it to have free surface refinement, as found in damBreakWithObstacle tutorial (multiphase/interfoam/laminar).
less than 10% error resistance in head seas, See figure 8 of reference below.
### Links / references
(Links to literature, supporting information)
Jeonghwa Seo, Hak-Kyu Choi, Uh-Cheul Jeong, Dong Kun Lee, Shin Hyung Rhee, Chul-Min Jung, Jaehoon Yoo,
Model tests on resistance and seakeeping performance of wave-piercing high-speed vessel with spray rails,
International Journal of Naval Architecture and Ocean Engineering,
Volume 8, Issue 5,
2016,
Pages 442-455,
ISSN 2092-6782,
https://doi.org/10.1016/j.ijnaoe.2016.05.010.