Development issueshttps://develop.openfoam.com/groups/Development/-/issues2020-08-04T15:08:53Zhttps://develop.openfoam.com/Development/openfoam/-/issues/1790Position interpolation in tabulated6DoFMotion does not give expected result2020-08-04T15:08:53ZMike WorthPosition interpolation in tabulated6DoFMotion does not give expected result<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be re...<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be rendered on the platform by using the
"preview" tab above
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
When the position of a dynamic mesh is calculated using tabulated6DoFMotion, the result is neither intuitive nor smooth. I don't know enough about the purported method to know if it's a bug or just not a very suitable algorithm.
<!-- Summarize the bug encountered concisely -->
### Steps to reproduce
With at least 4 defined steps, define a motion that moves, pauses and returns. Example below:
<!-- How one can reproduce the issue - this is very important -->
### Example case
dynamicMeshDict:
```
/*--------------------------------*- C++ -*----------------------------------*\
| ========= | |
| \\ / F ield | OpenFOAM: The Open Source CFD Toolbox |
| \\ / O peration | Version: v1912 |
| \\ / A nd | Website: www.openfoam.com |
| \\/ M anipulation | |
\*---------------------------------------------------------------------------*/
FoamFile
{
version 2.0;
format ascii;
class dictionary;
object dynamicMeshDict;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
dynamicFvMesh dynamicOversetFvMesh;
dynamicOversetFvMeshCoeffs
{
// layerRelax 0.3;
}
solver multiSolidBodyMotionSolver;
multiSolidBodyMotionSolverCoeffs
{
movingZone
{
solidBodyMotionFunction tabulated6DoFMotion;
tabulated6DoFMotionCoeffs
{
CofG (0.001 0.001 0.001);
timeDataFileName "constant/dipMotion.dat";
}
}
}
// ************************************************************************* //
```
Dipmotion.dat:
```4 //number of data points in the file
//Position formatting is not important. File is based on the character sequence only.
//Vectors are not relative. Each vector is total displacement and total rotation.
(
//(time_point ( (linear displacement vector) (rotation vector) ) )
//(seconds ( (following unit system, usually meters) (radians) ) )
(0 ( (0 0 0) (0 0 0) ) )
(4.19042 ( (0 -0.159236 0) (0 0 0) ) )
(5.19042 ( (0 -0.159236 0) (0 0 0) ) )
(38.141 ( (0 0.05 0) (0 0 0) ) )
)
```
<!--
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?
Instead of pausing between the middle two times (as would be expected from linear interpolation), there is a rapid further movement. See below for a graph where I've re-implemented the interpolateSplineXY.C algorithm to investigate what it returns:
![image](/uploads/5067c1cff761d69a58c1dca81dc50108/image.png)
<!-- What actually happens -->
### What is the expected *correct* behavior?
Interpolation should either be linear (which would potentially cause problems with derivative values being high/undefined), or should approximate to linear with rounded corners of some kind.
<!-- 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 : v1806|v1812|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : 1912 & 2006
- Operating system : Ubuntu 18.04
- Hardware info :
- Compiler :
### Possible fixes
Either use a different interpolation method here, or adjust what values the existing one returns:
https://develop.openfoam.com/Development/openfoam/-/blob/master/src/dynamicMesh/motionSolvers/displacement/solidBody/solidBodyMotionFunctions/tabulated6DoFMotion/tabulated6DoFMotion.C#L93
<!--
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/1789Turbulence models (kEpsilon, kOmegaSSTSato) TwoPhaseSystem - preconditioner2020-07-29T18:16:49ZRobin KamenickyTurbulence models (kEpsilon, kOmegaSSTSato) TwoPhaseSystem - preconditioner<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be re...<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be rendered on the platform by using the
"preview" tab above
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
When kEpsolin, kOmegaSST, kOmegaSSTSato is used and the alpha fields are initialized via utility such as setField to value 0 or 1 the preconditioner gives floating point exception during usage of preconditioner class. This happens during first iteration.
<!-- Summarize the bug encountered concisely -->
### Steps to reproduce
Use the tutorial $FOAM_TUTORIALS/heatTransfer/chtMultiRegionTwoPhaseEulerFoam/solidQuenching2D. Change the constant/water/turbulenceProperties.liquid from
`simulationType RAS;
RAS
{
RASModel mixtureKEpsilon;//kEpsilon;
turbulence on;
printCoeffs on;
}`
to
`simulationType RAS;
RAS
{
RASModel kEpsilon;
turbulence on;
printCoeffs on;
}`
and
change file constant/water/turbulenceProperties.gas from
`simulationType RAS;
RAS
{
RASModel mixtureKEpsilon;
turbulence on;
printCoeffs on;
}`
to
`simulationType RAS;
RAS
{
RASModel kEpsilon;
turbulence on;
printCoeffs on;
}`
The same happens if we use for instance a combination for gas-liquid kEpsilon-laminar or kOmegaSST-kOmegaSSTSato.
The error is
```#0 Foam::error::printStack(Foam::Ostream&) at ~/OpenFOAM/OpenFOAM-v1906-debug/src/OSspecific/POSIX/printStack/printStack.C:236
#1 Foam::sigFpe::sigHandler(int) at ~/OpenFOAM/OpenFOAM-v1906-debug/src/OSspecific/POSIX/signals/sigFpe.C:130
#2 ? in /lib/x86_64-linux-gnu/libc.so.6
#3 Foam::DILUPreconditioner::calcReciprocalD(Foam::Field<double>&, Foam::lduMatrix const&) at ~/OpenFOAM/OpenFOAM-v1906-debug/src/OpenFOAM/matrices/lduMatrix/preconditioners/DILUPreconditioner/DILUPreconditioner.C:80 (discriminator 2)
```
It happens already at first construction of the class. It seems that division by 0 occurs on line 80 in DILUPreconditioner.C. Change of preconditioner or solver does not help. The only option is not to use preconditioner at all. When that is done, the simulation runs smoothly and the results seem to be fine.
<!-- How one can reproduce the issue - this is very important -->
### Example case
Described in the steps to reproduce.
<!--
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?
SIGFPE when preconditioner used with kEpsilon, kOmegaSST, kOmegaSSSato and internalField of phase volume fractions initialized to 0 or 1.
<!-- What actually happens -->
### What is the expected *correct* behavior?
No SIGFPE.
<!-- 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 : v1806|v1812|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v1906
- Operating system : Ubuntu 16.04.6 LTS
- Hardware info :
- Compiler : gcc
### Possible fixes
Bound the phase fraction in $FOAM_SRC/phaseSystemModels/reactingEulerFoam/reactingTwoPhaseEulerFoam/twoPhaseSystem/twoPhaseSystem.C:342
from
`alpha1.clip(0, 1);`
to
`alpha1.clip(SMALL, 1 - SMALL);`
the same will probably happen also for twoPhaseEulerFoam. I have not tested that.
the fix would be in $FOAM_APP/solvers/multiphase/twoPhaseEulerFoam/twoPhaseSystem/twoPhaseSystem.C
where lines 532, 533 would need to be changed from
`
alpha1.max(0);
alpha1.min(1);
`
to
`
alpha1.max(SMALL);
alpha1.min(1 - SMALL);
`
<!--
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
-->Sergio FerrarisSergio Ferrarishttps://develop.openfoam.com/Development/openfoam/-/issues/1788interfaceHeight does not work in parallel2020-09-08T16:21:31ZzackinterfaceHeight does not work in parallel<!--
*** 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
interfaceHeight does not work with parallel solver.
### Steps to reproduce
Run with single and multiple processor. Single processor writes output where as parallel processor outputs an empty file.
### 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
OpenFOAM version: OpenFOAM v2006
Operating system: ubuntu 18.04
### 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/1786checkMesh -writeFields does not check correctness2023-12-13T17:01:12ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comcheckMesh -writeFields does not check correctness### Functionality to add/problem to solve
`checkMesh -writeFields '(BANANA)'`
will happily run and not give any indication about illegal input. Attached file checks.
@mark : happy with this?
[checkMesh.C](/uploads/32222724bb5d738f8c4...### Functionality to add/problem to solve
`checkMesh -writeFields '(BANANA)'`
will happily run and not give any indication about illegal input. Attached file checks.
@mark : happy with this?
[checkMesh.C](/uploads/32222724bb5d738f8c498a8faf9930aa/checkMesh.C)https://develop.openfoam.com/Development/openfoam/-/issues/1784cyclic BC in blockMeshDict -> snappyHexMesh not in parallel mode2021-07-07T09:03:18ZAlexander Kospachcyclic BC in blockMeshDict -> snappyHexMesh not in parallel modeHi,
I have noticed that when I added my cyclic BC in my blockMeshDict directly I can't perform snappyHexMesh in parallel mode.
Then I always get the error message:
face area does not match to neighbour by 22.222% possible face orderin...Hi,
I have noticed that when I added my cyclic BC in my blockMeshDict directly I can't perform snappyHexMesh in parallel mode.
Then I always get the error message:
face area does not match to neighbour by 22.222% possible face ordering problem
When I don't add the cyclic BC in my blockMeshDict I don't get the error messagehttps://develop.openfoam.com/Development/openfoam/-/issues/1783openfoam rpm on Centos/Fedora2020-07-23T09:03:59ZBjörn Selentopenfoam rpm on Centos/Fedora### Summary
openfoam prebuilt packages (rpm) cannot be installed on Centos 7
### Steps to reproduce
On any computer running Centos 7 try:
yum install openfoam
### Example case
yum install yum-plugin-copr
yum copr enable openfoam/...### Summary
openfoam prebuilt packages (rpm) cannot be installed on Centos 7
### Steps to reproduce
On any computer running Centos 7 try:
yum install openfoam
### Example case
yum install yum-plugin-copr
yum copr enable openfoam/openfoam
yum install openfoam
### What is the current *bug* behaviour?
Installation fails
### What is the expected *correct* behavior?
rpm is installed without error
### Relevant logs and/or images
Error: Paket: openfoam2006-common-1-200629.el7.noarch (copr:copr.fedorainfracloud.org:openfoam:openfoam)
Benötigt: awk
### Environment information
- OpenFOAM version : v2006
- Operating system : centos 7
### Possible fixes
replace "awk" with "gawk" in file openfoam2006.spec"Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1782Wrong installation dir of modules on Ubuntu2020-08-09T18:31:24ZShinji NakagawaWrong installation dir of modules on Ubuntu
<!--
*** 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 r...
<!--
*** 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 Ubuntu 18.04 (and other version using dash), compilation of modules such as runTimePostProcessing finishes successfully. However, installation directory is wrong.
Expected dir: `$WM_PROJECT_DIR/platforms/linux64GccDPInt32Opt/lib`
Installed dir: `$WM_PROJECT_DIR/platforms/linux64GccDPInt32Opt/lib/lib`
Related issue:
https://develop.openfoam.com/Development/ThirdParty-common/-/issues/48
https://develop.openfoam.com/Development/ThirdParty-common/-/commit/cd811d9b2852e600038fd875d61ba2a52ff1f8bb
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
```
cd $WM_THIRD_PARTY_DIR
makeParaView
ln -s ParaView-v5.6.3/VTK/ VTK-8.2.0
makeVTK
wmRefresh
cd $WM_PROJECT_DIR
export ParaView_DIR=$WM_THIRD_PARTY_DIR/platforms/linux64Gcc/ParaView-5.6.3
export VTK_DIR=$WM_THIRD_PARTY_DIR/platforms/linux64Gcc/VTK-8.2.0
foam
./Allwmake -j -s -l
```
You can check the functionality with tutorials/incompressible/simpleFoam/windAroundBuildings.
You will get the error message like this `librunTimePostProcessing.so: cannot open shared object file: No such file or directory`.
### 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 -->
Library files like `librunTimePostProcessing.so` are stored in the directory `$WM_PROJECT_DIR/platforms/linux64GccDPInt32Opt/lib/lib`.
### What is the expected *correct* behavior?
<!-- What you should see instead -->
Library files like `librunTimePostProcessing.so` should be stored in the directory `$WM_PROJECT_DIR/platforms/linux64GccDPInt32Opt/lib`.
### 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.
-->
Partially modified (to smear a user name) `$WM_PROJECT_DIR/build/linux64GccDPInt32Opt/modules/visualization/src/runTimePostProcessing/cmake_install.cmake` file
```
# Install script for directory: $WM_PROJECT_DIR/modules/visualization/src/runTimePostProcessing
# Set the install prefix
if(NOT DEFINED CMAKE_INSTALL_PREFIX)
set(CMAKE_INSTALL_PREFIX "$WM_PROJECT_DIR/platforms/linux64GccDPInt32Opt/lib")
endif()
string(REGEX REPLACE "/$" "" CMAKE_INSTALL_PREFIX "${CMAKE_INSTALL_PREFIX}")
```
CMAKE_INSTALL_PREFIX does not need the last “lib”.
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v1806|v1812|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : OpenFOAM v2006
- Operating system : Ubuntu 18.04.4
- Hardware info :
- Compiler : gcc 7.5.0
### 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
-->
This will be related to dash (not bash) used in Ubuntu.
The test script is created using line 17 of `$WM_PROJECT_DIR/modules/visualization/src/runTimePostProcessing/Allwmake.
The above modification rips “lib” off from $FOAM_LIBBIN with dash or bash.
Original:
`: "${CMAKE_INSTALL_PREFIX:=${FOAM_LIBBIN%/*}}"`
Modification:
`: "${CMAKE_INSTALL_PREFIX:="${FOAM_LIBBIN%/*}"}"`
[test01.sh](/uploads/f221964f62fc601b2f27f4e502e75288/test01.sh) <- not modified with sh
[test01bash.sh](/uploads/a2d9b2889f65ff944d768d35772d6875/test01bash.sh) <- not modified with bash
[test02.sh](/uploads/236956d411cf3a3235e7bc3dcba8f14e/test02.sh) <- modified with sh
[test02bash.sh](/uploads/f11005f6c147d46ca19b7c720853da5c/test02bash.sh) <- modified with bash
```
$ ./test01.sh
#!/bin/sh
/home/user/OpenFOAM/OpenFOAM-v2006/platforms/linux64GccDPInt32Opt/lib
/home/user/OpenFOAM/OpenFOAM-v2006/platforms/linux64GccDPInt32Opt/lib
$ ./test01bash.sh
#!/bin/bash
/home/user/OpenFOAM/OpenFOAM-v2006/platforms/linux64GccDPInt32Opt/lib
/home/user/OpenFOAM/OpenFOAM-v2006/platforms/linux64GccDPInt32Opt
$ ./test02.sh
#!/bin/sh
/home/user/OpenFOAM/OpenFOAM-v2006/platforms/linux64GccDPInt32Opt/lib
/home/user/OpenFOAM/OpenFOAM-v2006/platforms/linux64GccDPInt32Opt
$ ./test02bash.sh
#!/bin/bash
/home/user/OpenFOAM/OpenFOAM-v2006/platforms/linux64GccDPInt32Opt/lib
/home/user/OpenFOAM/OpenFOAM-v2006/platforms/linux64GccDPInt32Opt
```
/label ~bugMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1780FOAM_ABORT pre-empts throwing exceptions2020-08-05T10:33:56ZMark OLESENFOAM_ABORT pre-empts throwing exceptionsAs noted prior to release by @andy, running with FOAM_ABORT means that failed loading of function objects translates into a real failure instead of being generous and emitting a warning. With issue #1779, it looks like time to make a min...As noted prior to release by @andy, running with FOAM_ABORT means that failed loading of function objects translates into a real failure instead of being generous and emitting a warning. With issue #1779, it looks like time to make a minor adjustment to the `error` class.
I think that if code has requested `throwExceptions()` this should be honoured by the internals of `error`. Ie, swap the order of if/else if in error.C around line 240.
Opinions, objections? @andy and @MattijsMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1779additional handling of function object failure2022-05-29T15:09:02ZMark OLESENadditional handling of function object failureAs raised in EP1338, the change of sampled surfaces causes a different in later OpenFOAM versions.
In the earlier versions, if the surface was out-of-domain (wrong location, but most likely incorrect scaling), this would fail on constru...As raised in EP1338, the change of sampled surfaces causes a different in later OpenFOAM versions.
In the earlier versions, if the surface was out-of-domain (wrong location, but most likely incorrect scaling), this would fail on construction which would emit a warning and discard the function object.
More recent updates for sampling are much _"lazier"_ - they only construct the surface as required. This is particularly useful in cases of an iso-surface for a field that does not exist until later in the simulation.
However, as a side-effect of this, the failure can now occur during execute() or write() of the functionObject, which means that even if the dry-run was successful, the job can crash because of the bad function object.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1778Function1Expression vector2020-07-20T14:15:05ZMatej FormanFunction1Expression vectorExample in file Function1Expression.H
for vector is not working (tested on cavity case in U file as is).
Entry in U:
```
movingWall
{
type uniformFixedValue;
uniformValue
{
typ...Example in file Function1Expression.H
for vector is not working (tested on cavity case in U file as is).
Entry in U:
```
movingWall
{
type uniformFixedValue;
uniformValue
{
type expression;
variables
(
"start = 0.5"
"stop = 1"
);
expression #{mag(arg() > start && arg() < stop) * vector(1, 0, 0) #};
}
}
```
Error message:
```
Reading field U
--> FOAM Warning :
From virtual Foam::Istream& Foam::ISstream::read(Foam::word&)
in file db/IOstreams/Sstreams/ISstream.C at line 482
Reading "/home/matej/PROJECTS/release2006/cavity/0/U" at line 35
Missing 1 closing ')' while parsing
mag(arg()
--> FOAM Warning :
Reading "/home/matej/PROJECTS/release2006/cavity/0/U" at line 35
Imbalanced '{' with ')'
--> FOAM Warning :
From virtual Foam::Istream& Foam::ISstream::read(Foam::word&)
in file db/IOstreams/Sstreams/ISstream.C at line 482
Reading "/home/matej/PROJECTS/release2006/cavity/0/U" at line 35
Missing 1 closing ')' while parsing
vector(1,
```Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1776Instructions to build Paraview FoamReader plugin2021-07-07T09:01:40ZGhost UserInstructions to build Paraview FoamReader pluginHello,
I've compiled OpenFOAM v2006 on Ubuntu 20.04. However, I have already Paraview 5.7 installed on my machine, so I didn't compile Paraview, because that will take more than 10 hours on my machine.
I can't figure out how to compile t...Hello,
I've compiled OpenFOAM v2006 on Ubuntu 20.04. However, I have already Paraview 5.7 installed on my machine, so I didn't compile Paraview, because that will take more than 10 hours on my machine.
I can't figure out how to compile the Paraview Foam Reader Plugin alone to be able to use `paraFoam`, I can't find instructions on your website.
Thank youhttps://develop.openfoam.com/Development/openfoam/-/issues/1775cleanup of autoPtr, tmp classes2020-08-11T17:17:55ZMark OLESENcleanup of autoPtr, tmp classesShould remove some slight inconsistencies between autoPtr and tmp, and reduce some coding verbosity.
- For autoPtr, can use assignment from `nullptr` to effect a reset. Should also be allowed for tmp.
- Reduce use of autoPtr `empty()` a...Should remove some slight inconsistencies between autoPtr and tmp, and reduce some coding verbosity.
- For autoPtr, can use assignment from `nullptr` to effect a reset. Should also be allowed for tmp.
- Reduce use of autoPtr `empty()` and `valid()` methods.
The autoPtr empty() method was introduced (Jan-2009) to reduce these types of constructs:
```
if (!myPtr.valid()) ...
if (myPtr.empty()) ...
```
But now there are some places with this type of thing:
```
if (!myPtr.empty()) ...
```
Since we now have an explicit `bool` operator, probably makes sense to use that instead:
```
if (myPtr) ...
if (!myPtr) ...
```Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1774questionable code in shortestPathSet genSamples2020-07-15T06:43:41ZMark OLESENquestionable code in shortestPathSet genSamplesFrom inspection looks like size mismatch or funny comments
// Seed faces and points on 'real' boundary
bitSet isBlockedPoint(mesh.nPoints());
{
// Real boundaries
const polyBoundaryMesh& pbm = mesh.boundaryMe...From inspection looks like size mismatch or funny comments
// Seed faces and points on 'real' boundary
bitSet isBlockedPoint(mesh.nPoints());
{
// Real boundaries
const polyBoundaryMesh& pbm = mesh.boundaryMesh();
for (label patchi : wallPatches)
{
const polyPatch& pp = pbm[patchi];
forAll(pp, i)
{
isBlockedPoint.set(pp[i]);
}
}
// Meshed boundaries
forAll(isBlockedFace, facei)
{
if (isBlockedFace[facei])
{
isBlockedPoint.set(mesh.faces()[facei]);
}
}
syncTools::syncPointList
(
mesh,
isBlockedPoint,
orEqOp<unsigned int>(),
0u
);
Looks to be seeding with faces, but treating as points?
@Mattijshttps://develop.openfoam.com/Development/openfoam/-/issues/1772snappyHexMesh creates disconnected regions2024-01-05T17:03:11ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comsnappyHexMesh creates disconnected regions### Functionality to add/problem to solve
snappyHexMesh is sometimes used to create multiple regions which later on get 'connected' through e.g. cyclicAMI. This does make it impossible to detect what is a properly resolved region and wh...### Functionality to add/problem to solve
snappyHexMesh is sometimes used to create multiple regions which later on get 'connected' through e.g. cyclicAMI. This does make it impossible to detect what is a properly resolved region and what is just a dangling few cells.
### Target audience
Cases with faceZones that are intersecting the geometry.
### Proposal
For now have option to remove small regions. This should be expressed as a fraction of 'main' region for a given zone.
@PrashantMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/1771checkMesh -writeAllFields does not handle faceZones with boundary faces in them2020-07-28T15:15:56ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comcheckMesh -writeAllFields does not handle faceZones with boundary faces in them<!--
*** 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 -->
`checkMesh -writeAllFields` does not handle faceZones with boundary faces in them. It fills a surfaceScalarField without checking if the faceZone does not contain any boundary faces.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Use topoSet or setSet to put some boundary faces in a faceZone. In setSet on e.g. the lid-driven cavity tutorial:
```
faceSet f0 new labelToFace (0 100 200 300 400 800 1000 1639)
faceZoneSet f0Zone new setToFaceZone f0
```
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v1806|v1812|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : developMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/1769CrankNicolson ddtScheme gives wrong results for even nOuterCorrectors2020-08-03T15:39:05ZHenning ScheuflerCrankNicolson ddtScheme gives wrong results for even nOuterCorrectorsIn order to increase the numerical stability or accuracy of the scheme, we have the possibility to solve the equation multiple times during a time step. A common example for this is the pimple algorithm. However, the combination multiple...In order to increase the numerical stability or accuracy of the scheme, we have the possibility to solve the equation multiple times during a time step. A common example for this is the pimple algorithm. However, the combination multiple nOuterCorrectors with the CrankNicolson scheme leads to wrong results:
**CrankNicolson nOuter 1:**
![CNNouter1_damBreak_U](/uploads/3a5a989261c43afa604bcd820c7e2a84/CNNouter1_damBreak_U.png)
![CNNouter1_damBreak_alpha](/uploads/da84dec4c018050d1536086fc948df65/CNNouter1_damBreak_alpha.png)
**CrankNicolson nOuter 2:**
![CNNouter2_damBreak_U](/uploads/c329af32ac84586bbd566dcfae0aa56d/CNNouter2_damBreak_U.png)
![CNNouter2_damBreak_alpha](/uploads/3eb9ecd54af0243c1a1a917fe3ed3159/CNNouter2_damBreak_alpha.png)
**CrankNicolson nOuter 2 with fix:**
![CNNouter2_damBreak_U_fixed](/uploads/3b38acbf9a994a9d8cac5ac6ff4b867e/CNNouter2_damBreak_U_fixed.png)
![CNNouter2_damBreak_alpha_fixed](/uploads/5967cde4a3db48021b3be137cf304f05/CNNouter2_damBreak_alpha_fixed.png)
Solving the equations with the CrankNicolson time scheme results in wrong values if nOuterCorrectors is an even number. The reason is that (evaluate(ddt0)) in fvmDDt is always true:
```
{
if (evaluate(ddt0))
{
ddt0 = rDtCoef0_(ddt0)*rho*(vf.oldTime() - vf.oldTime().oldTime())
- offCentre_(ddt0());
}
fvm.source() =
(
rDtCoef*rho.value()*vf.oldTime().primitiveField()
+ offCentre_(ddt0.primitiveField())
)*mesh().V();
}
```
as the timeIndex of the geometricField is not update in the above scenario.
A possible solution might be:
```
template<class Type>
template<class GeoField>
bool CrankNicolsonDdtScheme<Type>::evaluate
(
DDt0Field<GeoField>& ddt0
)
{
bool evaluated = ddt0.timeIndex() != mesh().time().timeIndex();
ddt0.timeIndex() = mesh().time().timeIndex();
return evaluated;
}
```
### Reproduce
interFoam -> damBreak
ddtSchemes -> CrankNicolson 0.9;
nOuterCorrectors -> 2;
### Environment information
- OpenFOAM version : v1806
- Operating system : ubuntu
- Hardware info :
- Compiler :https://develop.openfoam.com/Development/openfoam/-/issues/1766HashTable completely broken in OF-v20062020-07-10T07:37:29ZVasu JaganathHashTable completely broken in OF-v2006`HashTable<vector, label> testHash;
testHash.insert(1,vector(0,2,1));
`
when I compile this, I get the following error
error: function "Foam::string::hash::operator()" cannot be called with the given argument list
argume...`HashTable<vector, label> testHash;
testHash.insert(1,vector(0,2,1));
`
when I compile this, I get the following error
error: function "Foam::string::hash::operator()" cannot be called with the given argument list
argument types are: (const Foam::label)
object type is: Foam::string::hash
return Hash()(key) & (capacity_ - 1);
I am using the exact syntax recommended in the API and as it worked in OF-6 and below.
https://www.openfoam.com/documentation/guides/latest/api/classFoam_1_1HashTable.htmlMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1765collated fileHandler hangs when using #include clause in decomposeParDict2020-07-09T14:13:58ZMiguel Castellanocollated fileHandler hangs when using #include clause in decomposeParDict<!--
*** 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 the case with collated output, for any given solver, if there is an #include clause into the decomposeParDict, introducing for example an external dictionary with variables but also EVEN if it is a empty dictionary, the run will hang forever. Just the fact that there is an #include clause into the decomposeParDict causes the run to hang indefinitely.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
For ANY OpenFOAM tutorial (or at least/tested on sineWaveDamping(rhoPimpleFoam) and damBreak(interFoam)):
1. Just add an #include clause into your decomposeParDict (#include myDict)
2. RUN:
blockMesh -fileHandler collated
decomposePar -fileHandler collated
mpirun -np $CORES $SOLVER -parallel -fileHandler collated
HANGS INDEFINITELY ...
3. Remove the #include clause and try again.
4. RUNS SMOOTHLY.
### Example case
ANY OPENFOAM TUTORIAL
<!--
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
-->
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v1806|v1812|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v5. , v6. , v1912
- Operating system : SUSE Linux Enterprise, Arch Linux
- Hardware info :
- Compiler : icc, gcchttps://develop.openfoam.com/Development/openfoam/-/issues/1762libs with word instead of filenames fails re-reading2020-07-06T07:41:13ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comlibs with word instead of filenames fails re-reading<!--
*** 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 case (pisoFoam/LES/pitzDaily) the library loading (in e.g. the `functions` functionObjectList) uses the new syntax:
```
libs (sampling)
```
When forcing re-reading by touching system/controlDict it gives an error since it expects a fileName.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
- take above tutorial
- comment out functions section
- start running
- uncomment functions section & save
### 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.
-->
```
Re-reading object controlDict from file "ep_1328_fileModification/pitzDaily/system/controlDict"
Overriding OptimisationSwitches according to controlDict
fileModificationSkew 1;
--> FOAM FATAL IO ERROR:
Wrong token type - expected string, found on line 58: word 'sampling'
file: ep_1328_fileModification/pitzDaily/system/controlDict.functions.probes.libs at line 58.
From function Foam::Istream& Foam::operator>>(Foam::Istream&, Foam::fileName&)
in file primitives/strings/fileName/fileNameIO.C at line 58.
FOAM aborting (FOAM_ABORT set)
```
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v1806|v1812|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v1812Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1760mingw :test case fail2021-07-06T17:36:26ZPawan Ghildiyalmingw :test case fail
@mark
Creating a list of tutorial(except multiphase) which fail in windows version.
I will keep on updating the list.
1. heatTransfer/buoyantBoussinesqSimpleFoam/iglooWithFridges/
The tutorial fail in windows mingw versi...
@mark
Creating a list of tutorial(except multiphase) which fail in windows version.
I will keep on updating the list.
1. heatTransfer/buoyantBoussinesqSimpleFoam/iglooWithFridges/
The tutorial fail in windows mingw version while running snappyHexMesh
It was unable to find "displacementLaplacian" Solver
Adding libs(libfvMotionSolvers) in controlDict, resolve the issue .
2. incompressible/pimpleFoam/LES/surfaceMountedCube/initChannel (Edited)
functionObject surface: to output turbulenceProperties:L,turbulenceProperties:R, turbulenceProperties:R
write variablefile as turbulenceProperties and not turbulenceProperties:R