Development issueshttps://develop.openfoam.com/groups/Development/-/issues2023-06-19T12:23:25Zhttps://develop.openfoam.com/Development/openfoam/-/issues/2453OpenFOAM v2112 Installation, Critical error, Base configuration ok. gcc and i...2023-06-19T12:23:25ZDominic McGeochOpenFOAM v2112 Installation, Critical error, Base configuration ok. gcc and icoFoam not installedI am running WSL2 on Windows 10 Pro with Ubuntu 20.04 (LTS). To install, compile, and test OpenFOAM v2112 I ran the following sequence of commands in my Ubuntu shell:
```
cp -a -r /mnt/c/Users/domin/Downloads/OpenFOAM-v2112.tgz .
sudo t...I am running WSL2 on Windows 10 Pro with Ubuntu 20.04 (LTS). To install, compile, and test OpenFOAM v2112 I ran the following sequence of commands in my Ubuntu shell:
```
cp -a -r /mnt/c/Users/domin/Downloads/OpenFOAM-v2112.tgz .
sudo tar -xvzf OpenFOAM-v2112.tgz -C /opt/
sudo chown -R $USER /opt/
sudo apt install bison flex m4
echo "source /opt/OpenFOAM-v2112/etc/bashrc" >> ~/.bashrc
source $HOME/.bashrc
foamSystemCheck
foam
./Allwmake -j -s -q -l
foamInstallationTest
```
Much of this was adapted from my previous v2012 install, for which I followed these instructions: https://www.openfoam.com/download/openfoam-installation-on-windows-10, and the quick build guide: https://develop.openfoam.com/Development/openfoam/-/blob/master/doc/Build.md
The installation passed the foamSystemCheck pre-compile, but after compiling alerted me that `Base configuration ok. The foam installation contains 2 critical error(s).` and that gcc and icoFoam were not installed.
If I run `gcc --version` however I see that I have version 9.4.0 installed, so I'm unsure what the issue is there. I am however concerned that icoFoam did not install. I'm not certain what I need to do at the moment, whether I need a fresh install, another compile pass, or a clean rebuild.
Any help would be greatly appreciated.https://develop.openfoam.com/Development/openfoam/-/issues/2454BUG: streamLineBase: attempt to access element 0 from zero sized list2022-05-11T11:24:00ZKutalmış BerçinBUG: streamLineBase: attempt to access element 0 from zero sized list### Summary
In `streamLineBase.C#L792`, `scalarNames_` has zero-size, but it was attempted to access element 0 via `scalarNames_[i]`.
### Steps to reproduce
`$FOAM_TUTORIALS/heatTransfer/buoyantBoussinesqPimpleFoam/BenardCells`
### ...### Summary
In `streamLineBase.C#L792`, `scalarNames_` has zero-size, but it was attempted to access element 0 via `scalarNames_[i]`.
### Steps to reproduce
`$FOAM_TUTORIALS/heatTransfer/buoyantBoussinesqPimpleFoam/BenardCells`
### What is the current *bug* behaviour?
```
--> FOAM FATAL ERROR: (openfoam-2202 patch=220310)
attempt to access element 0 from zero sized list
From void Foam::UList<Foam::word>::checkIndex(const Foam::label) const [T = Foam::word]
in file /home/pikachu2/kuti/OpenFOAM/base/develop/src/OpenFOAM/lnInclude/UListI.H at line 163.
...
#7 Foam::functionObjects::streamLineBase::writeToFile() at ~/OpenFOAM/base/develop/src/functionObjects/field/streamLine/streamLineBase.C:792
...
```
### Environment information
- d00445ac
### Possible fixes
Replace `scalarNames_[i]` with `vectorNames_[i]` in `streamLineBase.C#L792`.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2455processorAgglomerator masterCoarsest fails on small mesh2022-05-06T11:07:30ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comprocessorAgglomerator masterCoarsest fails on small mesh<!--
*** 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 -->
On tiny mesh switch on GAMG with processorAgglomerator masterCoarsest. Fails for scotch decomposition, not for hierarchical.
### 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
-->
[cavity.tgz](/uploads/6f7842989084b5d4e82002a3c33f959a/cavity.tgz)
```
blockMesh
decomposePar
mpirun -np 5 icoFoam -parallel -debug-switch GAMGAgglomeration=1
```
### 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.
-->
```
Courant Number mean: 0 max: 0
smoothSolver: Solving for Ux, Initial residual = 1, Final residual = 2.06898e-06, No Iterations 7
smoothSolver: Solving for Uy, Initial residual = 0, Final residual = 0, No Iterations 0
[1] #0 Foam::error::printStack(Foam::Ostream&)[2] #0 Foam::error::printStack(Foam::Ostream&)[3] #0 Foam::error::printStack(Foam::Ostream&)[4] #0 [0] #0 Foam::error::printStack(Foam::Ostream&)Foam::error::printStack(Foam::Ostream&) at ??:?
at ??:?
[3] #1 Foam::sigSegv::sigHandler(int) at ??:?
at ??:?
[2] #1 Foam::sigSegv::sigHandler(int)[4] #1 Foam::sigSegv::sigHandler(int)[1] #1 Foam::sigSegv::sigHandler(int) at ??:?
[0] #1 Foam::sigSegv::sigHandler(int) at ??:?
[3] #2 ? at ??:?
```
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v2112|v2106|v2012|v2006|v1912|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : 2112
### 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
-->
@Pawanhttps://develop.openfoam.com/Development/openfoam/-/issues/2456BUG: bitSet bitwise and does not trim2022-05-10T11:08:36ZMark OLESENBUG: bitSet bitwise and does not trimThe bitSet '&=' ignores the values from non-overlapping blocks, which means that values remain _sticky_. Should be actually zero out these blocks.The bitSet '&=' ignores the values from non-overlapping blocks, which means that values remain _sticky_. Should be actually zero out these blocks.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2458unset csh environment variables when sourcing cshrc twice2022-06-03T13:21:46ZDavid Ludlowunset csh environment variables when sourcing cshrc twice<!--
*** 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 -->
In a c-shell if sourcing `~OpenFOAM/OpenFOAM-v2112/etc/cshrc` MORE THAN ONCE, the OpenFOAM paths are missing from the environment variable `$PATH` and so OpenFOAM code will no longer operate.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
```
> source ~OpenFOAM/OpenFOAM-v2112/etc/cshrc
> echo $PATH
> source ~OpenFOAM/OpenFOAM-v2112/etc/cshrc
> echo $PATH
```
### 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 -->
OpenFOAM paths are missing from `$PATH`
### What is the expected *correct* behavior?
<!-- What you should see instead -->
OpenFOAM paths are in `$PATH`
### 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 : v2112|v2106|v2012|v2006|v1912|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version :v2112 (and possibly earlier)
- Operating system : centos or any (presumably)
- Hardware info :
- Compiler :gcc or any (presumably)
### 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
-->
In `etc/config.csh/setup` there are two occurrences of the following three lines:
```
_foamClean PATH "$foamOldDirs"
_foamClean MANPATH "$foamOldDirs"
_foamClean -lib "$foamOldDirs"
```
If you replace the second occurrence by
```
_foamClean PATH
_foamClean MANPATH
_foamClean -lib
```
This fixes the issue.https://develop.openfoam.com/Development/openfoam/-/issues/2459mpirunDebug2022-05-07T08:44:45ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.commpirunDebug### Functionality to add/problem to solve
mpirunDebug passes through arguments but does not protect "### Functionality to add/problem to solve
mpirunDebug passes through arguments but does not protect "Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/2461Unusual slow-down using collated I/O format2022-06-14T08:00:05ZMark OLESENUnusual slow-down using collated I/O formatIssue reported on [cfd-online](https://www.cfd-online.com/Forums/openfoam-bugs/232081-possible-bug-unusual-slow-down-using-collated-i-o-format.html) for cases with many timesteps.
They traced it back to the insertion/sorting of times i...Issue reported on [cfd-online](https://www.cfd-online.com/Forums/openfoam-bugs/232081-possible-bug-unusual-slow-down-using-collated-i-o-format.html) for cases with many timesteps.
They traced it back to the insertion/sorting of times in [masterUncollatedFileOperation::setTime](https://develop.openfoam.com/Development/openfoam/-/blob/master/src/OpenFOAM/global/fileOperations/masterUncollatedFileOperation/masterUncollatedFileOperation.C#L2246)Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2462Unable to set source and target faces (coupled boundary condition)2022-05-09T12:25:38ZSunag R AUnable to set source and target faces (coupled boundary condition)
### Summary
Hi,
I am trying to work on patch to patch coupled boundary condition. I came across coupled boundary condition namely AMI, CyclicAMI. I am new to this part.
1. Does AMI and CyclicAMI work only for dynamic meshes?
2. I am ...
### Summary
Hi,
I am trying to work on patch to patch coupled boundary condition. I came across coupled boundary condition namely AMI, CyclicAMI. I am new to this part.
1. Does AMI and CyclicAMI work only for dynamic meshes?
2. I am trying to interpolate the dirichlet boundary conditon values on one patch to adjacent patch using AMI boundary condition. (The mesh does not move and still I have tried to use it).
3. I am facing an issue stating as mentioned in title as "Unable to set source and target faces".
My boundary file is as follows as present in constant/polymesh/boundary:
```
3
(
AMI_patch1
{
type cyclicAMI;
inGroups 1(cyclicAMI);
matchTolerance 0.001;
transform noOrdering;
neighbourPatch AMI_patch2;
nFaces 7113;
startFace 730746;
separationVector (0.005 0 0);
}
chestwall
{
type patch;
nFaces 5196;
startFace 737859;
}
AMI_patch2
{
type cyclicAMI;
inGroups 1(cyclicAMI);
matchTolerance 0.001;
transform noOrdering;
neighbourParch AMI_patch1;
nFaces 9334;
startFace 743055;
separationVector (-0.005 0 0);
}
)
```
I am working with chtMultiRegionSimpleFoam, due to this, the region boundary corresponding to the AMI patches are also same.
### What is the current *bug* behaviour?
Error:
```
AMI: Creating addressing and weights between 7113 source faces and 9334 target faces
--> FOAM Warning :
From function void Foam::AMIMethod<SourcePatch, TargetPatch>::checkPatches() const [with SourcePatch = Foam::PrimitivePatch<Foam::face, Foam::SubList, const Foam::Field<Foam::Vector<double> >&>; TargetPatch = Foam::PrimitivePatch<Foam::face, Foam::SubList, const Foam::Field<Foam::Vector<double> >&>]
in file lnInclude/AMIMethod.C at line 57
Source and target patch bounding boxes are not similar
source box span : (0.163847 0.1670128 0.08645282)
target box span : (0.2068839 0.1798336 0.08224967)
source box : (0.003686016 -0.0002872496 0) (0.167533 0.1667256 0.08645282)
target box : (0.07743542 -0.006471181 0) (0.2843193 0.1733624 0.08224967)
inflated target box : (0.0631258 -0.0207808 -0.01430962) (0.2986289 0.187672 0.09655929)
--> FOAM FATAL ERROR:
Unable to set source and target faces
From function void Foam::faceAreaWeightAMI<SourcePatch, TargetPatch>::setNextFaces(Foam::label&, Foam::label&, Foam::label&, const boolList&, Foam::labelList&, const Foam::DynamicList<int>&, bool) const [with SourcePatch = Foam::PrimitivePatch<Foam::face, Foam::SubList, const Foam::Field<Foam::Vector<double> >&>; TargetPatch = Foam::PrimitivePatch<Foam::face, Foam::SubList, const Foam::Field<Foam::Vector<double> >&>; Foam::label = int; Foam::boolList = Foam::List<bool>; Foam::labelList = Foam::List<int>]
in file lnInclude/faceAreaWeightAMI.C at line 287.
FOAM aborting
```
### What is the expected *correct* behavior?
I need to have patch to patch interpolated field flow after each iteration.
### Other
How does this AMI work and what are the changes need to be made.? For reference, I have attached the surface image for reference, where the left patch contains the dirichlet boundary condition and right patch is the one where the interpolation from dirichlet boundary condition showed happen.
Is there a possibility of interpolating one surface patch to another for a static mesh? Open to give the case files.
![image_ami](/uploads/6472a2d08f85017de34a835c747b8df3/image_ami.png)
### Environment information
- OpenFOAM version : 5
- Operating system : Ubuntu 18.04.6 LTShttps://develop.openfoam.com/Development/openfoam/-/issues/2463SnappyHexMesh multiregion snapp of chamfer2022-05-09T13:03:20ZVojtech BetakSnappyHexMesh multiregion snapp of chamfer### Summary
SnappyHexMesh fails in the chase of multi-region snap to chamfer. At the interface is created a wavy mesh. In some cases has been observed a formation of a gap at the interface between mesh regions (cellzones). This wavy in...### Summary
SnappyHexMesh fails in the chase of multi-region snap to chamfer. At the interface is created a wavy mesh. In some cases has been observed a formation of a gap at the interface between mesh regions (cellzones). This wavy interface is not observed when the interface has e.g. cylindrical shape.
### Environment information
-->
- OpenFOAM version : v2112
- Operating system : openSuse
- Hardware info :
- Compiler : gcc-10
[snappyII.tar.xz](/uploads/8c9564e298e9d9e83132a614d1eac01a/snappyII.tar.xz)
![geom-multiRegion](/uploads/81621703ff1eb35dfd262c2db812fe68/geom-multiRegion.png)
![geomII](/uploads/37fcbfbdfbb06357bb8dd06027ed36c9/geomII.png)
![geom](/uploads/5c8daa4190f8750541c263aa72f01cc4/geom.png)
![wires](/uploads/492fda8a44fb071e80edb65ed6a42e29/wires.png)https://develop.openfoam.com/Development/openfoam/-/issues/2464Non-orthogonality mesh warning2022-05-11T12:33:36ZB HNon-orthogonality mesh warningWhy does the following blockMeshDict give this non-orthogonal warning?
Reproduce by calling blockMesh and then checkMesh.
The mesh has only about 20 degrees of non-orthogonality (not the 73
quoted in the warning) and is very simple to v...Why does the following blockMeshDict give this non-orthogonal warning?
Reproduce by calling blockMesh and then checkMesh.
The mesh has only about 20 degrees of non-orthogonality (not the 73
quoted in the warning) and is very simple to view and manually check
(I reduced a much more complex mesh to this testcase).
```
Checking geometry...
Overall domain bounding box (0 -1 0) (5 0 1)
Mesh has 2 geometric (non-empty/wedge) directions (1 1 0)
Mesh has 2 solution (non-empty) directions (1 1 0)
All edges aligned with or perpendicular to non-empty directions.
Boundary openness (-5.04647e-19 0 0) OK.
Max cell openness = 6.93889e-17 OK.
Max aspect ratio = 60 OK.
Minimum face area = 0.0333333. Maximum face area = 3.00005. Face area magnitudes OK.
Min volume = 0.1. Max volume = 2.7. Total volume = 5. Cell volumes OK.
Mesh non-orthogonality Max: 73.5683 average: 26.3638
*Number of severely non-orthogonal (> 70 degrees) faces: 1.
Non-orthogonality check OK.
<<Writing 1 non-orthogonal faces to set nonOrthoFaces
Face pyramids OK.
Max skewness = 0.0666667 OK.
Coupled point location match (average 0) OK.
```
```
/*--------------------------------*- C++ -*----------------------------------*\
| ========= | |
| \\ / F ield | OpenFOAM: The Open Source CFD Toolbox |
| \\ / O peration | Version: v2112 |
| \\ / A nd | Website: www.openfoam.com |
| \\/ M anipulation | |
\*---------------------------------------------------------------------------*/
FoamFile
{
version 2.0;
format ascii;
class dictionary;
object blockMeshDict;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
y0 -0.00000;
y1 -0.90000;
y2 -0.90000;
y3 -1.00000;
vertices
(
(0 $y2 1)
(0 $y3 1)
(2 $y3 1)
(5 $y3 1)
(2 $y2 1)
(5 $y1 1)
(5 $y0 1)
(2 $y0 1)
(0 $y0 1)
(0 $y2 0)
(0 $y3 0)
(2 $y3 0)
(5 $y3 0)
(2 $y2 0)
(5 $y1 0)
(5 $y0 0)
(2 $y0 0)
(0 $y0 0)
);
ySpacing ((1 1 2));
MX0 1; MX1 1;
MY0 1; MY1 2;
blocks
(
hex (10 11 13 9 1 2 4 0)
($MX0 $MY1 1)
simpleGrading (1 1 1)
hex (11 12 14 13 2 3 5 4)
($MX1 $MY1 1)
edgeGrading (1 1 1 1 1 $ySpacing $ySpacing 1 1 1 1 1)
hex ( 9 13 16 17 0 4 7 8)
($MX0 $MY0 1)
simpleGrading (1 1 1)
hex (13 14 15 16 4 5 6 7)
($MX1 $MY0 1)
simpleGrading (1 1 1)
);
edges
(
);
boundary
(
inlet
{
type patch;
faces
(
(9 0 8 17)
);
}
outlet
{
type patch;
faces
(
(12 14 5 3)
(14 15 6 5)
);
}
upperWall
{
type wall;
faces
(
(17 8 7 16)
(16 7 6 15)
);
}
lowerWall
{
type wall;
faces
(
(9 0 1 10)
(10 11 2 1)
(11 12 3 2)
);
}
);
```https://develop.openfoam.com/Development/openfoam/-/issues/2466redistributePar -reconstruct -constant fails2022-05-12T10:41:00ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comredistributePar -reconstruct -constant 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 -->
`redistributePar -reconstruct -constant` fails with NO_READ specified.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
e.g. in cavity:
```
blockMesh
decomposePar (with e.g. hierarchical (2 1 1))
rm -r constant/polyMesh
mpirun -np 2 redistributePar -reconstruct -constant -parallel
```
### Example case
Any e.g. cavity tutorial.
### What is the current *bug* behaviour?
<!-- What actually happens -->
Error message with `NO_READ` on constructor
### 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 : v2112|v2106|v2012|v2006|v1912|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2112
### Possible fixes
<!--
If you can, link to the line of code that might be responsible for the
problem
The "/label ~bug" text is a gitlab flag that will add the "bug" label to this
issue
-->
Add 0 size?
@markMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/2467globalIndex gather of indirect list (contiguous data) fails2022-05-12T12:27:27ZKutalmış BerçinglobalIndex gather of indirect list (contiguous data) fails- `$FOAM_TUTORIALS/finiteArea/surfactantFoam/planeTransport`
- `./Allrun-parallel` and inspect `log.makeFaMesh`.
- `runParallel makeFaMesh` also fails.
- HEAD: 809fc70166.
- The case runs with `v2112` (HEAD: 14aeaf8dab) and in serial...- `$FOAM_TUTORIALS/finiteArea/surfactantFoam/planeTransport`
- `./Allrun-parallel` and inspect `log.makeFaMesh`.
- `runParallel makeFaMesh` also fails.
- HEAD: 809fc70166.
- The case runs with `v2112` (HEAD: 14aeaf8dab) and in serial mode.
- Traceback:
```
Write finite area mesh.
[0] --> FOAM FATAL ERROR: (openfoam-2202 patch=220310)
[0] attempt to access element 0 from zero sized list
...
[0] #6 Foam::UList<char>::operator[](int) at ~/OpenFOAM/base/develop/src/OpenFOAM/lnInclude/UListI.H:302
[0] #7 Foam::UIPstreamBase::read(char&) at ~/OpenFOAM/base/develop/src/OpenFOAM/db/IOstreams/Pstreams/UIPstreamBase.C:409
[0] #8 Foam::UIPstreamBase::read(Foam::token&) at ~/OpenFOAM/base/develop/src/OpenFOAM/db/IOstreams/Pstreams/UIPstreamBase.C:25
1
[0] #9 Foam::token::token(Foam::Istream&) at ~/OpenFOAM/base/develop/src/OpenFOAM/db/IOstreams/token/tokenIO.C:128
[0] #10 Foam::UList<Foam::Vector<double> >::readList(Foam::Istream&) at ~/OpenFOAM/base/develop/src/OpenFOAM/lnInclude/UListIO.
C:168
[0] #11 Foam::Istream& Foam::operator>><Foam::Vector<double> >(Foam::Istream&, Foam::UList<Foam::Vector<double> >&) at ~/OpenFO
AM/base/develop/src/OpenFOAM/lnInclude/UList.H:610
[0] #12 void Foam::globalIndex::gather<Foam::Vector<double>, Foam::UList<int> >(Foam::UList<int> const&, int, Foam::UList<int>
const&, Foam::IndirectListBase<Foam::Vector<double>, Foam::UList<int> > const&, Foam::List<Foam::Vector<double> >&, int, Foam::U
Pstream::commsTypes) at ~/OpenFOAM/base/develop/src/OpenFOAM/lnInclude/globalIndexTemplates.C:304
[0] #13 void Foam::globalIndex::gather<Foam::Vector<double>, Foam::UList<int> >(Foam::IndirectListBase<Foam::Vector<double>, Fo
am::UList<int> > const&, Foam::List<Foam::Vector<double> >&, int, Foam::UPstream::commsTypes, int) const at ~/OpenFOAM/base/deve
lop/src/OpenFOAM/lnInclude/globalIndexTemplates.C:395
[0] #14 Foam::faMeshReconstructor::calcAddressing(Foam::UList<int> const&) at ~/OpenFOAM/base/develop/src/parallel/reconstruct/
faReconstruct/faMeshReconstructor.C:240
[0] #15 Foam::faMeshReconstructor::faMeshReconstructor(Foam::faMesh const&) at ~/OpenFOAM/base/develop/src/parallel/reconstruct
/faReconstruct/faMeshReconstructor.C:570
...
```
@mark @Mattijshttps://develop.openfoam.com/Development/openfoam/-/issues/2468potentialFoam creates unphysical velocity field in motorBike tutorial2024-01-03T14:12:44ZAaron EndrespotentialFoam creates unphysical velocity field in motorBike tutorial<!--
*** 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 -->
In OpenFOAM v2112, potentialFoam creates an unphysical velocity field.
This ultimately leads to the crash of the simulation.
In OpenFOAM v2012, this issue was not present.
Tested in serial as well as in parallel execution, on different Linux versions and on different hardware.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Copy the motorBike tutorial case, execute the Allrun script, look at the 0/U field in paraview.
### 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
-->
motorBike tutorial
### What is the current *bug* behaviour?
<!-- What actually happens -->
in v2112:
![OFv2112](/uploads/83f9006c88e31921c62fb20a6c6f39a8/OFv2112.png)
### What is the expected *correct* behavior?
<!-- What you should see instead -->
in v2012:
![OFv2012](/uploads/039e4b8f08c31fb2cb2423be6f4713a1/OFv2012.png)
### 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 : v2112|v2106|v2012|v2006|v1912|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2112: latest stable release and dev version 'patch = 220310, build = f8dc192941-20220507'
- Operating system : ArchLinux and OpenSUSE Tumbleweed
- Hardware info : AMD EPYC 7452 and Intel Xeon CPU E5-2650
- Compiler : gcc
### Possible fixes
<!--
If you can, link to the line of code that might be responsible for the
problem
The "/label ~bug" text is a gitlab flag that will add the "bug" label to this
issue
-->Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2469foamToCcm and ccmToFoam missing librairies2022-05-24T12:56:23ZalexfoamToCcm and ccmToFoam missing librairiesHello,
in OF v2112, doing ./Allwmake in the src/conversion/ccm folder leads to :
```
==> skip ccmio (no header)
==> skip optional libccm adapter
```
is there anything missing ? and how to fix this ?
regardsHello,
in OF v2112, doing ./Allwmake in the src/conversion/ccm folder leads to :
```
==> skip ccmio (no header)
==> skip optional libccm adapter
```
is there anything missing ? and how to fix this ?
regardshttps://develop.openfoam.com/Development/openfoam/-/issues/2471atmosphericModels using incorrect value for groundMin2022-05-20T09:06:52ZTom ChenatmosphericModels using incorrect value for groundMin
### Summary
When using the atmosphericModels library, the value groundMin is added to the log law equation to prevent Z value to be below 0. It appears that the groundMin value used is the minimum value of Z in the entire computation d...
### Summary
When using the atmosphericModels library, the value groundMin is added to the log law equation to prevent Z value to be below 0. It appears that the groundMin value used is the minimum value of Z in the entire computation domain, as opposed to the patch where the ABL is applied.
### Steps to reproduce
Create a computational domain, where the exterior edges's z = 0, and inside the domain, have a protrusion below ground, where z is less than 0.
When measuring the ABLInlet U value at the inlet, the profile will be calculated using the groundMin value of the protrusion, instead of the minimum z height of the patch. This, unfortunately, changes the profile at the inlet, tho the results may still be ok if a wall function is applied and enough distance between the inlet and object of interest is provided.
See below for illustration:
![image](/uploads/453fda1a762450c491bfbaeca70038e6/image.png)
### Possible fixes
I believe this line of code may be the culprit:
[atmBoundaryLayer.C#L72](https://develop.openfoam.com/Development/openfoam/-/blob/OpenFOAM-v2112/src/atmosphericModels/derivedFvPatchFields/atmBoundaryLayer/atmBoundaryLayer.C#L72)
Where:
`ppMin_((boundBox(pp.points())).min()),`
refers to the globalPoints (all points in domain), as opposed to all points in the patch.
I believe changing that line to:
`ppMin_((boundBox(pp.localPoints())).min()),`
will fix the issue.Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2474How to replicate the results of turbulent flow over NACA0012 airfoil (2D)2022-05-18T15:08:53ZhongweiHow to replicate the results of turbulent flow over NACA0012 airfoil (2D)Dear all,
I am trying to replicate the results of the validation case -- [Turbulent flow over NACA0012 airfoil (2D)](https://www.openfoam.com/documentation/guides/latest/doc/verification-validation-naca0012-airfoil-2d.html). However, I ...Dear all,
I am trying to replicate the results of the validation case -- [Turbulent flow over NACA0012 airfoil (2D)](https://www.openfoam.com/documentation/guides/latest/doc/verification-validation-naca0012-airfoil-2d.html). However, I failed to convert the mesh using `plot3dToFoam`. I find some [discussions](https://www.cfd-online.com/Forums/openfoam-solving/118148-2d-naca-0012-airfoil-validation-case-nasa-2.html) about this issue. I followed the guides but still failed to run the case.
Could you give me some suggestions, please? The attached [airFoil2D.zip](/uploads/3355892a53d8bba6fd1cb37ff8446b4f/airFoil2D.zip) file is the whole case.
OpenFOAM version: v2012
OS version: Ubuntu 20.04
Thank you for your help.https://develop.openfoam.com/Development/openfoam/-/issues/2475totalFlowRateAdvectiveDiffusive does not work with topology changes2022-09-28T15:48:09ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comtotalFlowRateAdvectiveDiffusive does not work with topology changes<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be re...<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be rendered on the platform by using the
"preview" tab above
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
<!-- Summarize the bug encountered concisely -->
totalFlowRateAdvectiveDiffusive does not map all fields in the autoMap.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
(not tested) Use refineHexMesh on a case with totalFlowRateAdvectiveDiffusive.
### 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 -->
Crash with sigsegv
### 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 : v2112|v2106|v2012|v2006|v1912|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2112
### Possible fixes
<!--
If you can, link to the line of code that might be responsible for the
problem
The "/label ~bug" text is a gitlab flag that will add the "bug" label to this
issue
-->
Use mixed level autoMapMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/2476externalWallHeatFluxTemperature wrong behavior when both thermal resistance a...2022-07-11T17:17:38ZLuca CornoltiexternalWallHeatFluxTemperature wrong behavior when both thermal resistance and radiative heat transfer are activated<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be re...<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be rendered on the platform by using the
"preview" tab above
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
The externalWallHeatFluxTemperature boundary condition provides wrong results when dealing with both thermal resistance and external radiative heat flux. This is because of some implementation errors (from line 379 to line 408) in the original boundary condition.
### Steps to reproduce
Run the attached test case named stardardBC.
### Example case
Attached you can find a folder which contains the proposed fix for this boundary condition (externalWallHeatFluxTemperatureFixed) and three test cases which show the issue and that the proposed fix works correctly.
The tests are performed with solidFoam solver: a 1D conductive problem with a fixed heat flux BC on one side and heat losses with the environment applied to the other side is solved.
In the test case named stardardBC, the currently implemented externalWallHeatFluxTemperature BC is applied on the interface with the environment. A virtual solid layer of thickness 0.003 m and conductivity equal to the value of the solid is modeled as a thermal resistance. The emissivity is set to 0.5 to activate external external radiative heat losses.
In the test named fullyResolved, one cell of thickness equal to 0.003 m is added to the solid domain, so the virtual solid layer modeled in the BC of the previous test case is fully resolved. The same externalWallHeatFluxTemperature BC without equivalent thermal resistance is applied on the interface with the environment.
Finally, the test case named fixedBC share the same setup of stardardBC case, but with the fixed boundary condition.
### What is the current *bug* behaviour?
The treatment of the radiative heat flux is not correct when the external surface temperature is different than the internal face temperature because of wrong computation of the thermal resistance. The steady state temperature profile of test case named stardardBC does not match the one of the case named fullyResolved (see picture below).
### What is the expected *correct* behavior?
The steady state temperature profile of test case named stardardBC should match the one of the case named fullyResolved (see picture below).
### Relevant logs and/or images
Comparison of the Temperature profiles of the first three cells within solid domain.
![comparison](/uploads/63bf4f6286bfafda13bda6ee5b984213/comparison.png)
### Environment information
- OpenFOAM version : v2112
- Operating system : ubuntu
- Compiler : gcc
### Possible fixes
The externalWallHeatFluxTemperatureFixed boundary condition provided in the attached folder shows a way to solve this issue.
The radiative heat flux can be rewritten as an equivalent convective heat flux with a convection coefficient which is function of the third power of the temperature. In this format, this coefficient can be introduced in the thermal resistance to correctly estimate the temperature on the virtual external surface in contact with the ambient.
As the radiative equivalent convection coefficient is a non linear function of the external surface temperature, an iterative method has to be used for find the correct value. In the provided code, this is implemented in a quite straightforward way, but which works well, with a while loop which usually converges after only one or two iterations.
The fixing lines are from 383 to 429.
Just run the Allrun script in the main folder to solve the three test cases and generate the image shown in the previous section with grace software.
[TESTfix_externalWallHeatFluxTemperature.tar](/uploads/53e41d548a683108fd21dae5b6c6f61b/TESTfix_externalWallHeatFluxTemperature.tar)https://develop.openfoam.com/Development/openfoam/-/issues/2477snappyHexMesh does not clear mesh phi when adding layers2022-06-28T09:59:09ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comsnappyHexMesh does not clear mesh phi when adding layers<!--
*** 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 -->
snappyHexMesh does not clear mesh phi when adding layers. This gives error message about mesh flux not set.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
run e.g. iglooWithFridges tutorial.
### 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 -->
Error when updating meshPhi
### 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 : v2112|v2106|v2012|v2006|v1912|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2202
- Operating system :
- Hardware info :
- Compiler :
### Possible fixes
<!--
If you can, link to the line of code that might be responsible for the
problem
The "/label ~bug" text is a gitlab flag that will add the "bug" label to this
issue
-->
Unset mesh moving flag before doing an 'updateMesh'.Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/2479The spurious velocity is too large using isoAdvection2024-01-11T18:59:52ZJinghong SuThe spurious velocity is too large using isoAdvectionI am testing the movement of a 2D bubble under a Couette flow using the interFoam and interIsoFoam, finding that the spurious velocities produced by the isoAdvection plicRDF are even larger than those produced by the MULES.The bubble is ...I am testing the movement of a 2D bubble under a Couette flow using the interFoam and interIsoFoam, finding that the spurious velocities produced by the isoAdvection plicRDF are even larger than those produced by the MULES.The bubble is in a developed Couette flow and the Reynolds number is 100 and CFL=0.1. The density ratio between the air and water is set to be 1:10. The gravity is set to be zero.
interIsoFoam
![interIsoFoam](/uploads/714bd9cab52469f8bdde7eb3a9154d49/interIsoFoam.png)
interFoam
![interFoam](/uploads/3c77e660c2051fec70907da6c21f8da7/interFoam.png)
I wonder if the isoAdvection plicRDF in opefoam-v2012 is the same as the isoAdvection plicRDF-5 in the article "Validation of volume-of-fluid OpenFOAM® isoAdvector solvers using single bubble benchmarks".
The run file is attached below
[re100_bubble.zip](/uploads/f99c3ffbf1ede7a4fffe89337c35ba45/re100_bubble.zip)
- OpenFOAM version :Openfoam-v2012
- Operating system :entOS Linux release 7.4.1708 (Core)
- Hardware info :
- Compiler :gcc-4.9.4