Development issueshttps://develop.openfoam.com/groups/Development/-/issues2023-06-26T10:33:01Zhttps://develop.openfoam.com/Development/openfoam/-/issues/2741faceAgglomerate not robust2023-06-26T10:33:01ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comfaceAgglomerate not robust<!--
*** 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 -->
- faceAgglomerate utility can hang
- sharp angles are not detected as features
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
in tutorials/heatTransfer/chtMultiRegionFoam/externalSolarLoad specify some agglomeration for air:
[viewFactorsDict](/uploads/22120b2cc9b482b1c69a71026772f5b7/viewFactorsDict)
### Example case
<!--
If possible, please create a SMALL example and attach it to your report
If you are using an older version of OpenFOAM this will also determine
whether the bug has been fixed in a more recent version
-->
### What is the current *bug* behaviour?
<!-- What actually happens -->
Hangs since agglomerated-face-forms-single-loop check does not count whether any new restraints have been added.
### What is the expected *correct* behavior?
<!-- What you should see instead -->
Agglomeration not getting stuck. It might not be able to agglomerate down to the wanted level because of topological constraints but it should not hang.
### 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 :
### Possible fixes
<!--
If you can, link to the line of code that might be responsible for the
problem
The "/label ~bug" text is a gitlab flag that will add the "bug" label to this
issue
-->Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/2739multiLevel at the scotch level2023-05-09T13:04:47ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.commultiLevel at the scotch level### Functionality to add/problem to solve
multiLevel decomposition can be used to minimise 'expensive' cuts. scotch can support this natively using SCOTCH_archTleaf.
### Target audience
multi-node runs
### Proposal
E.g. start from ...### Functionality to add/problem to solve
multiLevel decomposition can be used to minimise 'expensive' cuts. scotch can support this natively using SCOTCH_archTleaf.
### Target audience
multi-node runs
### Proposal
E.g. start from the extended multiLevel input:
```
numberOfSubdomains 1024;
method multiLevel;
multiLevelCoeffs
{
method scotch
domains (2 8); //< inferred as domains (64 2 8);
}
```
Just needs additional spec of the individual cut weights.
### What does success look like, and how can we measure that?
Would be nice to have stats about cuts*weights on the individual levels...
@mark @andyhttps://develop.openfoam.com/Development/openfoam/-/issues/2738Binaries fail to install on Ubuntu 20.04 LTS2023-05-08T11:51:24ZAdam EricksonBinaries fail to install on Ubuntu 20.04 LTS<!--
*** 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
Binaries fail to install on Ubuntu 20.04 LTS (focal).
### Steps to reproduce
```bash
pubkey_url='https://dl.openfoam.com/pubkey.gpg'
repos_url='https://dl.openfoam.com/repos/deb'
apt_pubkey_path='/etc/apt/trusted.gpg.d/openfoam.gpg'
apt_source_path='/etc/apt/sources.list.d/openfoam.list'
ARCH='amd64'
DISTRIB_CODENAME='focal'
echo "deb [arch=${ARCH}] ${repos_url} ${DISTRIB_CODENAME} main" | sudo tee "${apt_source_path}"
curl -L "${pubkey_url}" | gpg --dearmor | sudo tee "${apt_pubkey_path}"
sudo apt update
sudo apt install openfoam2212-default
Reading package lists... Done
Building dependency tree
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:
The following packages have unmet dependencies:
openfoam2212-default : Depends: openfoam2212-tutorials (= 2212.230110-1) but it is not going to be installed
E: Unable to correct problems, you have held broken packages.
```
### Example case
See above.
### What is the current *bug* behaviour?
Fails to install.
### What is the expected *correct* behavior?
Installs.
### 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 : Ubuntu 20.04 LTS
- Hardware info : amd64, x86_64
- Compiler : gcc, clang
### Possible fixes
It looks like `openfoam2212-tutorials` depends on a release candidate for `openfoam2212-common` that is unavailable:
```bash
openfoam2212-tutorials : Depends: openfoam2212-common (= 2212.0~rc2-1) but 2212.230110-1 is to be installed
```https://develop.openfoam.com/Development/openfoam/-/issues/2736dynamicMesh failure restarting using CrankNicholson2024-01-04T10:56:23ZJamie MacLeoddynamicMesh failure restarting using CrankNicholson<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be re...<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be rendered on the platform by using the
"preview" tab above
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
<!-- Summarize the bug encountered concisely -->
When restarting a case using dynamic meshing the first step fails with an error:
```
--> FOAM FATAL IO ERROR: (openfoam-2212 patch=230110)
size 77961 is not equal to the expected length 78325
file: 0.002/ddt0(rho,U).internalField at line 21.
From void Foam::Field<Type>::assign(const Foam::entry&, Foam::label) [with Type = Foam::Vector<double>; Foam::label = int]
in file ./src/OpenFOAM/lnInclude/Field.C at line 241.
FOAM exiting
```
This occurs regardless of whether dynamicMeshDict is altered or not (it may work sometimes if it is set to not refine every step, and happens to not align with the restart step, as previous tests have found that it works this way).
Almost certainly this associated with the 2nd order time scheme (which I would certainly strongly prefer to use), as Euler has no issues with the restart vs CN.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Run attached case until a new time, in this instance 0.002, and then try to restart.
### 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
-->
[dynMfail.zip](/uploads/384f0ef04572001fa268baf4d8ffcea3/dynMfail.zip)
### What is the current *bug* behaviour?
<!-- What actually happens -->
Restarting when using dynamic meshing fails with size error when using Crank Nicholson timeScheme.
### What is the expected *correct* behavior?
<!-- What you should see instead -->
The simulation restarts as a normal timestep would.
### 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
-->
```
Build : _c9081d5d-20230220 OPENFOAM=2212 patch=230110 version=2212
Arch : "LSB;label=32;scalar=64"
Exec : interFoam1
```
- Operating system : WSL Ubuntu 22.04
- Hardware info : Tested on Ryzen 5 2600 and Intel X chip
- Compiler : gcc?https://develop.openfoam.com/Development/openfoam/-/issues/2735BUG: function object: Failed to store pointer: grad(U). Risk of memory leakage2023-04-05T14:45:47ZJuan SalazarBUG: function object: Failed to store pointer: grad(U). Risk of memory leakage<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be re...<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be rendered on the platform by using the
"preview" tab above
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
<!-- Summarize the bug encountered concisely -->
When running grad function object on U field, the following error is issued (occurs with postProcess option and/or during simulation):
"Failed to store pointer: grad(U). Risk of memory leakage"
Possibly related to Development/openfoam#2381, recommendation of including `useNamePrefix true;` in function object did not make the bug go away.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Run grad function object on turbulentFlatPlate tutorial (solver simpleFoam). I ran it on the setup with kOmegaSST with y plus = 1.
`postProcess -func "grad(U)"`
or
`simpleFoam -postProcess -latestTime`
with FO grad included in controlDict.
### 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 explained above. Below is modified controlDict from standard turbulentFlatPlateTutorial.
```
/*--------------------------------*- C++ -*----------------------------------*\
| ========= | |
| \\ / F ield | OpenFOAM: The Open Source CFD Toolbox |
| \\ / O peration | Version: v2206 |
| \\ / A nd | Website: www.openfoam.com |
| \\/ M anipulation | |
\*---------------------------------------------------------------------------*/
FoamFile
{
version 2.0;
format ascii;
class dictionary;
object controlDict;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
application simpleFoam;
startFrom startTime;
startTime 0;
stopAt endTime;
endTime 5000;
deltaT 1;
writeControl timeStep;
writeInterval 100;
purgeWrite 1;
writeFormat ascii;
writePrecision 8;
writeCompression off;
timeFormat general;
timePrecision 8;
runTimeModifiable true;
functions
{
minMax
{
type fieldMinMax;
libs ("libfieldFunctionObjects.so");
writeControl timeStep;
fields (U);
}
yPlus
{
type yPlus;
libs ("libfieldFunctionObjects.so");
patches (fixedWall);
writeControl writeTime;
}
#includeFunc "writeCellCentres"
#includeFunc "wallShearStress"
#include "FOgrad"
}
```
The file "FOgrad" is in system folder.
```
/*--------------------------------*- C++ -*----------------------------------*\
| ========= | |
| \\ / F ield | OpenFOAM: The Open Source CFD Toolbox |
| \\ / O peration | Version: v2212 |
| \\ / A nd | Website: www.openfoam.com |
| \\/ M anipulation | |
\*---------------------------------------------------------------------------*/
grad1
{
// Mandatory entries
type grad;
libs ("libfieldFunctionObjects.so");
field U;
// Optional (inherited) entries
useNamePrefix true;
//result gradientU;
log true;
writeControl outputTime;
}
grad2
{
// Mandatory entries
type grad;
libs ("libfieldFunctionObjects.so");
field phi;
// Optional (inherited) entries
result gradPhi;
log true;
writeControl outputTime;
}
// ************************************************************************* //
```
### What is the current *bug* behaviour?
Error `Failed to store pointer: grad(U). Risk of memory leakage` is issued.
<!-- What actually happens -->
### What is the expected *correct* behavior?
<!-- What you should see instead -->
gradient of U field should be computed and file created in time folder. Tested on v2212, v2206, v2112. Works as expected with version v1706.
### 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.
-->
OpenFOAM v2206
```
--> FOAM Warning :
From bool Foam::regIOobject::store()
in file /Users/jsalazar/openfoam/OpenFOAM-v2206/src/OpenFOAM/lnInclude/regIOobjectI.H at line 51
Refuse to store unregistered object: grad(U)
--> FOAM FATAL ERROR: (openfoam-2206)
Failed to store pointer: grad(U). Risk of memory leakage
From static Type &Foam::regIOobject::store(Type *) [Type = Foam::GeometricField<Foam::Tensor<double>, Foam::fvPatchField, Foam::volMesh>]
in file /Users/jsalazar/openfoam/OpenFOAM-v2206/src/OpenFOAM/lnInclude/regIOobjectI.H at line 73.
FOAM aborting
#0 Foam::error::printStack(Foam::Ostream&) in /Volumes/OpenFOAM/OpenFOAM-v2206/platforms/darwinARM64ClangDPInt32Opt/lib/libOpenFOAM.dylib
#1 Foam::error::simpleExit(int, bool) (.cold.2) in /Volumes/OpenFOAM/OpenFOAM-v2206/platforms/darwinARM64ClangDPInt32Opt/lib/libOpenFOAM.dylib
#2 Foam::error::simpleExit(int, bool) in /Volumes/OpenFOAM/OpenFOAM-v2206/platforms/darwinARM64ClangDPInt32Opt/lib/libOpenFOAM.dylib
#3 Foam::error::exiting(int, bool) in /Volumes/OpenFOAM/OpenFOAM-v2206/platforms/darwinARM64ClangDPInt32Opt/lib/libOpenFOAM.dylib
#4 Foam::GeometricField<Foam::Tensor<double>, Foam::fvPatchField, Foam::volMesh>& Foam::regIOobject::store<Foam::GeometricField<Foam::Tensor<double>, Foam::fvPatchField, Foam::volMesh> >(Foam::GeometricField<Foam::Tensor<double>, Foam::fvPatchField, Foam::volMesh>*) in /Volumes/OpenFOAM/OpenFOAM-v2206/platforms/darwinARM64ClangDPInt32Opt/lib/libfieldFunctionObjects.dylib
#5 bool Foam::functionObjects::regionFunctionObject::store<Foam::GeometricField<Foam::Tensor<double>, Foam::fvPatchField, Foam::volMesh> >(Foam::word&, Foam::tmp<Foam::GeometricField<Foam::Tensor<double>, Foam::fvPatchField, Foam::volMesh> > const&, bool) in /Volumes/OpenFOAM/OpenFOAM-v2206/platforms/darwinARM64ClangDPInt32Opt/lib/libfieldFunctionObjects.dylib
#6 bool Foam::functionObjects::grad::calcGrad<Foam::Vector<double> >() in /Volumes/OpenFOAM/OpenFOAM-v2206/platforms/darwinARM64ClangDPInt32Opt/lib/libfieldFunctionObjects.dylib
#7 Foam::functionObjects::fieldExpression::execute() in /Volumes/OpenFOAM/OpenFOAM-v2206/platforms/darwinARM64ClangDPInt32Opt/lib/libfieldFunctionObjects.dylib
#8 Foam::functionObjects::timeControl::execute() in /Volumes/OpenFOAM/OpenFOAM-v2206/platforms/darwinARM64ClangDPInt32Opt/lib/libOpenFOAM.dylib
#9 Foam::functionObjectList::execute() in /Volumes/OpenFOAM/OpenFOAM-v2206/platforms/darwinARM64ClangDPInt32Opt/lib/libOpenFOAM.dylib
#10 main in /Volumes/OpenFOAM/OpenFOAM-v2206/platforms/darwinARM64ClangDPInt32Opt/bin/simpleFoam
#11 start in /usr/lib/dyld
zsh: abort simpleFoam -postProcess -latestTime
```
OpenFOAM v2212
```
--> FOAM Warning :
From bool Foam::regIOobject::store()
in file /Volumes/OpenFOAM-v2212/src/OpenFOAM/lnInclude/regIOobjectI.H at line 51
Refuse to store unregistered object: grad(U)
--> FOAM FATAL ERROR: (openfoam-2212)
Failed to store pointer: grad(U). Risk of memory leakage
From static Type &Foam::regIOobject::store(Type *) [Type = Foam::GeometricField<Foam::Tensor<double>, Foam::fvPatchField, Foam::volMesh>]
in file /Volumes/OpenFOAM-v2212/src/OpenFOAM/lnInclude/regIOobjectI.H at line 73.
FOAM aborting
#0 Foam::error::printStack(Foam::Ostream&) in /Volumes/OpenFOAM-v2212/platforms/darwin64ClangDPInt32Opt/lib/libOpenFOAM.dylib
#1 Foam::error::simpleExit(int, bool) (.cold.2) in /Volumes/OpenFOAM-v2212/platforms/darwin64ClangDPInt32Opt/lib/libOpenFOAM.dylib
#2 Foam::error::simpleExit(int, bool) in /Volumes/OpenFOAM-v2212/platforms/darwin64ClangDPInt32Opt/lib/libOpenFOAM.dylib
#3 Foam::error::exiting(int, bool) in /Volumes/OpenFOAM-v2212/platforms/darwin64ClangDPInt32Opt/lib/libOpenFOAM.dylib
#4 Foam::GeometricField<Foam::Tensor<double>, Foam::fvPatchField, Foam::volMesh>& Foam::regIOobject::store<Foam::GeometricField<Foam::Tensor<double>, Foam::fvPatchField, Foam::volMesh> >(Foam::GeometricField<Foam::Tensor<double>, Foam::fvPatchField, Foam::volMesh>*) in /Volumes/OpenFOAM-v2212/platforms/darwin64ClangDPInt32Opt/lib/libfieldFunctionObjects.dylib
#5 bool Foam::functionObjects::regionFunctionObject::store<Foam::GeometricField<Foam::Tensor<double>, Foam::fvPatchField, Foam::volMesh> >(Foam::word&, Foam::tmp<Foam::GeometricField<Foam::Tensor<double>, Foam::fvPatchField, Foam::volMesh> > const&, bool) in /Volumes/OpenFOAM-v2212/platforms/darwin64ClangDPInt32Opt/lib/libfieldFunctionObjects.dylib
#6 bool Foam::functionObjects::grad::calcGrad<Foam::Vector<double> >() in /Volumes/OpenFOAM-v2212/platforms/darwin64ClangDPInt32Opt/lib/libfieldFunctionObjects.dylib
#7 Foam::functionObjects::fieldExpression::execute() in /Volumes/OpenFOAM-v2212/platforms/darwin64ClangDPInt32Opt/lib/libfieldFunctionObjects.dylib
#8 Foam::functionObjects::timeControl::execute() in /Volumes/OpenFOAM-v2212/platforms/darwin64ClangDPInt32Opt/lib/libOpenFOAM.dylib
#9 Foam::functionObjectList::execute() in /Volumes/OpenFOAM-v2212/platforms/darwin64ClangDPInt32Opt/lib/libOpenFOAM.dylib
#10 main in /Volumes/OpenFOAM-v2212/platforms/darwin64ClangDPInt32Opt/bin/simpleFoam
#11 start in /usr/lib/dyld
Abort trap: 6
```
OpenFOAM v2112
```
--> FOAM FATAL ERROR: (openfoam-2112)
Failed to store pointer: grad(U). Risk of memory leakage
From static Type &Foam::regIOobject::store(Type *) [Type = Foam::GeometricField<Foam::Tensor<double>, fvPatchField, Foam::volMesh>]
in file /Users/jsalazar/openfoam/OpenFOAM-v2112/src/OpenFOAM/lnInclude/regIOobjectI.H at line 67.
FOAM aborting
#0 Foam::error::printStack(Foam::Ostream&) in /Volumes/OpenFOAM/OpenFOAM-v2112/platforms/darwin64ClangDPInt32Opt/lib/libOpenFOAM.dylib
#1 Foam::error::simpleExit(int, bool) (.cold.2) in /Volumes/OpenFOAM/OpenFOAM-v2112/platforms/darwin64ClangDPInt32Opt/lib/libOpenFOAM.dylib
#2 Foam::error::simpleExit(int, bool) in /Volumes/OpenFOAM/OpenFOAM-v2112/platforms/darwin64ClangDPInt32Opt/lib/libOpenFOAM.dylib
#3 Foam::error::exiting(int, bool) in /Volumes/OpenFOAM/OpenFOAM-v2112/platforms/darwin64ClangDPInt32Opt/lib/libOpenFOAM.dylib
#4 Foam::GeometricField<Foam::Tensor<double>, Foam::fvPatchField, Foam::volMesh>& Foam::regIOobject::store<Foam::GeometricField<Foam::Tensor<double>, Foam::fvPatchField, Foam::volMesh> >(Foam::GeometricField<Foam::Tensor<double>, Foam::fvPatchField, Foam::volMesh>*) in /Volumes/OpenFOAM/OpenFOAM-v2112/platforms/darwin64ClangDPInt32Opt/lib/libfieldFunctionObjects.dylib
#5 bool Foam::functionObjects::regionFunctionObject::store<Foam::GeometricField<Foam::Tensor<double>, Foam::fvPatchField, Foam::volMesh> >(Foam::word&, Foam::tmp<Foam::GeometricField<Foam::Tensor<double>, Foam::fvPatchField, Foam::volMesh> > const&, bool) in /Volumes/OpenFOAM/OpenFOAM-v2112/platforms/darwin64ClangDPInt32Opt/lib/libfieldFunctionObjects.dylib
#6 bool Foam::functionObjects::grad::calcGrad<Foam::Vector<double> >() in /Volumes/OpenFOAM/OpenFOAM-v2112/platforms/darwin64ClangDPInt32Opt/lib/libfieldFunctionObjects.dylib
#7 Foam::functionObjects::fieldExpression::execute() in /Volumes/OpenFOAM/OpenFOAM-v2112/platforms/darwin64ClangDPInt32Opt/lib/libfieldFunctionObjects.dylib
#8 Foam::functionObjects::timeControl::execute() in /Volumes/OpenFOAM/OpenFOAM-v2112/platforms/darwin64ClangDPInt32Opt/lib/libOpenFOAM.dylib
#9 Foam::functionObjectList::execute() in /Volumes/OpenFOAM/OpenFOAM-v2112/platforms/darwin64ClangDPInt32Opt/lib/libOpenFOAM.dylib
#10 main in /Volumes/OpenFOAM/OpenFOAM-v2112/platforms/darwin64ClangDPInt32Opt/bin/simpleFoam
#11 start in /usr/lib/dyld
```
### 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 or v2206 or v2112
- Operating system : macOS. Also tested with OpenFOAM v2112 on docker container (Ubuntu 20.04)
- Hardware info : MacBookPro Apple M1 Max 2021.
- Compiler : clang (gcc on docker container)
### 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/2734Dockerhub containers for v2206 and above2023-06-19T13:37:22ZTimofey MukhaDockerhub containers for v2206 and aboveDear all,
I'm testing some CI tools for compiling OpenFOAM applications, and managed to get Cirrus CI to work nicely.
I currently have 2 workflows: one which installs OpenFOAM via apt-get and the other using an OpenCFD docker container f...Dear all,
I'm testing some CI tools for compiling OpenFOAM applications, and managed to get Cirrus CI to work nicely.
I currently have 2 workflows: one which installs OpenFOAM via apt-get and the other using an OpenCFD docker container from Dockerhub:
```
v2212_task:
container:
image: ubuntu:jammy
test_script:
- apt-get update
- apt-get install -y wget
- wget -q -O - https://dl.openfoam.com/add-debian-repo.sh | bash
- apt-get install -qq openfoam2212-dev
- /usr/bin/openfoam2212 wmake
v2112_task:
container:
image: opencfd/openfoam2112-dev
test_script:
- /usr/bin/openfoam2112 wmake
```
The one in the OpenCFD container runs 5 seconds and the other one about a minute, so it seems there is quite some benefit in using Dockerhub.
Which leads to the question: what is the status of the [Dockerhub repository](https://hub.docker.com/u/opencfd/)? The latest container seems to be 2112, so the two latest versions are missing. There is, however, a version-less container, which was updated 3 months ago. Is this a snapshot of the `develop` branch? I am aware of the new `openfoam-docker` script, which is very nice. But I don't think I can use it in the CI, since it will be launching Docker inside Docker. It seems that ideally one would like to have the containers on Dockerhub.
Best,
Timofeyhttps://develop.openfoam.com/Development/openfoam/-/issues/2733XiFoam tutorial moriyoshiHomogeneous fails with sigfpe2024-01-04T10:07:26ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comXiFoam tutorial moriyoshiHomogeneous fails with sigfpe<!--
*** 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 -->
combustion/XiFoam/RAS/moriyoshiHomogeneous tutorial does not run
### Steps to reproduce
cd combustion/XiFoam/RAS/moriyoshiHomogeneous
foamRunTutorials
### Example case
<!--
If possible, please create a SMALL example and attach it to your report
If you are using an older version of OpenFOAM this will also determine
whether the bug has been fixed in a more recent version
-->
See above
### What is the current *bug* behaviour?
<!-- What actually happens -->
sigfpe when obtaining `psiu()` in the first iteration.
### 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 : v2212https://develop.openfoam.com/Development/openfoam/-/issues/2732An error occurred with the reconstructPar command2024-01-04T10:57:34Zliu haoAn error occurred with the reconstructPar command<!--
*** 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
An error occurred when executing the reconstructPar command with parallel computation
### Steps to reproduce
Run the example case
### 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
-->
Use Case From [https://turbmodels.larc.nasa.gov/naca0012_val.html](url) and https://github.com/tomrobin-teschner/OpenFOAMCaseGenerator [](url)
[Naca0012_number_of_processors_2_number_of_corrector_steps_3.zip](/uploads/174a417be398fc0c7f7af5d1ac8084fb/Naca0012_number_of_processors_2_number_of_corrector_steps_3.zip)
### 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.
-->
```
Reconstructing fields
region=region0
Time = 0.01
Reconstructing FV fields
Reconstructing volScalarFields
cp
--> FOAM FATAL IO ERROR: (openfoam-2206)
size 110 is not equal to the expected length 64
file: processor0/0.01/cp.boundaryField.farfield at line 7214 to 7215.
From Foam::Field<Type>::Field(const Foam::word&, const Foam::dictionary&, Foam::label) [with Type = double; Foam::label = int]
in file ./src/OpenFOAM/lnInclude/Field.C at line 218.
FOAM exiting
```
### 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 :v2206
- Operating system :windows
- Hardware info :N/A
- Compiler :gcc(Ubuntu on WSL)https://develop.openfoam.com/Development/openfoam/-/issues/2729The calculation using slip velocity boundary condition on the wall in chtMult...2023-03-27T19:34:40ZLEI WANGThe calculation using slip velocity boundary condition on the wall in chtMultiRegionFoam can not converge<!--
*** 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 -->
### Example case
<!--
If possible, please create a SMALL example and attach it to your report
If you are using an older version of OpenFOAM this will also determine
whether the bug has been fixed in a more recent version
-->
### What is the current *bug* behaviour?
<!-- What actually happens -->
### What is the expected *correct* behavior?
<!-- 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 :Ubuntu-18.04
- Hardware info :
- Compiler :
### Possible fixes
<!--
If you can, link to the line of code that might be responsible for the
problem
The "/label ~bug" text is a gitlab flag that will add the "bug" label to this
issue
-->https://develop.openfoam.com/Development/openfoam/-/issues/2728fvGeometryScheme parallel does not handle transformations2023-03-23T14:15:07ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comfvGeometryScheme parallel does not handle transformations<!--
*** 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 -->
The parallel fvGeometryScheme does not handle transformations.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
- switch in system/fvSchemes the geometry scheme to use parallel
- in annularCombustor tutorial use ./Allrun.pre to run snappyHexMesh
- it will fail reporting a problem about hexRef8 anchors.
- works fine with `basic` scheme
### 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
-->https://develop.openfoam.com/Development/openfoam/-/issues/2726createPatch removes newly added patches2023-03-22T11:23:39ZDarren GarveycreatePatch removes newly added patchesI am using [CfdOf](https://github.com/jaheyns/CfdOF) to which in my use-case creates an empty patch using `createPatch` before extruding it with `extrudeMesh`. This approach appears to have broken between v2106 and v2206. I think the com...I am using [CfdOf](https://github.com/jaheyns/CfdOF) to which in my use-case creates an empty patch using `createPatch` before extruding it with `extrudeMesh`. This approach appears to have broken between v2106 and v2206. I think the commit ad6d3a088eb5bfeab806e159f25526a102deb3bc changed the behaviour, specifically with the removal of
```
void filterPatches(polyMesh& mesh, const wordHashSet& addedPatchNames)
```
Where `addPatchNames` was there to make sure that `createPatch` doesn't remove newly created patches when they have no faces.
The `system/createPatchDict` to reproduce this is simple:
```
pointSync false;
patches
(
{
name patch_0_1_back;
patchInfo
{
type patch;
}
constructFrom patches;
patches ();
}
);
```
The newer versions of `createPatch` (since v2206) add then remove this patch:
```
Removed zero-sized patch patch_0_1_back type patch at position 9
```
It is possible that this use-case isn't supported and/or there is a Better Way to do it. Is there a good reason this feature should not be added back into `createPatch` (before I look at doing that)?https://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/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/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 OLESEN