Development issueshttps://develop.openfoam.com/groups/Development/-/issues2021-10-26T15:18:53Zhttps://develop.openfoam.com/Development/openfoam/-/issues/2241Cannot create valid tet decomposition for wegde mesh2021-10-26T15:18:53ZJan GärtnerCannot create valid tet decomposition for wegde mesh### Summary
A wedge mesh generated with blockMesh in OpenFOAM v2012 cannot be decomposed into tets with `polyMeshTetDecomposition::cellTetIndices()` and the `tetIndices::faceTriIs()` function.
A possible reason might be that four poin...### Summary
A wedge mesh generated with blockMesh in OpenFOAM v2012 cannot be decomposed into tets with `polyMeshTetDecomposition::cellTetIndices()` and the `tetIndices::faceTriIs()` function.
A possible reason might be that four points of the tet face are reported, e.g. for the sketch below it writes face (A B C A)
```c++
// A general wege
C
+
/|
/ |
/ 1|
+---+ B
^
A
```
If the mesh is generated with blockMesh of OpenFOAM 5.x the error does not occur. Note, only the mesh is generated with 5.x decomposition into tets is then done with v2012.
### Steps to reproduce
* Generate a wedge domain with blockMesh
* Use cellTetIndices to get the tets for all cells and try to find the `faceTriIs`. An example `main()` function could be:
```c++
int main()
{
#include "setRootCase.H"
#include "createTime.H"
#include "createMesh.H"
forAll(mesh,cellI)
{
List<tetIndices> cellTets =
polyMeshTetDecomposition::cellTetIndices(mesh, cellI);
triFaceList triFaces(cellTets.size());
forAll(cellTets, cTI)
{
triFaces[cTI] = cellTets[cTI].faceTriIs(mesh);
}
}
return 0;
};
```
* This will return the warning:
> --> FOAM Warning :
> From Foam::triFace Foam::tetIndices::faceTriIs(const Foam::polyMesh&, bool) const
> in file <FILEPATH>
> No base point for face 1620, 4(0 1 442 441), produces a valid tet decomposition.
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v1806|v1812|v1906|v1912|v2006|v2012|v2106 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2012
- Operating system : ubuntu 18.04 LTS
- Hardware info : amd ryzen 7
- Compiler : g++ 7.5.0Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2244foamDebugSwitches script is still mentioned in programmer's guide2021-10-27T11:38:37Zs1291foamDebugSwitches script is still mentioned in programmer's guideHi,
In OpenFOAM Programmer's guide (Page 21), the foamDebugSwitches script is still there.
![image](/uploads/03f9c0483f16328a90fa46d87dd1735d/image.png)
RegardsHi,
In OpenFOAM Programmer's guide (Page 21), the foamDebugSwitches script is still there.
![image](/uploads/03f9c0483f16328a90fa46d87dd1735d/image.png)
Regardshttps://develop.openfoam.com/Development/openfoam/-/issues/2182interFoam for wave simulation fails in Debug but not in Opt2021-10-27T12:49:23ZValerio GraziosointerFoam for wave simulation fails in Debug but not in Opt<!--
*** 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 a wave tank simulation with interFoam, if using openfoam compiled with WM_COMPILE_OPTION=Opt everything is ok. When using openfoam compiled with WM_COMPILE_OPTION=Debug the simulation crashes during the first timestep
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
1) run Allrun script (mesh preparation)
2) run the attached case with "interFoam" with openfoam v2106 (verified also for v1812) compiled with WM_COMPILE_OPTION=Debug
### 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 attachment
### What is the current *bug* behaviour?
<!-- What actually happens -->
The code crashes
### What is the expected *correct* behavior?
<!-- What you should see instead -->
It should run until Time=25
### 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.
-->
```
/*---------------------------------------------------------------------------*\
| ========= | |
| \\ / F ield | OpenFOAM: The Open Source CFD Toolbox |
| \\ / O peration | Version: v2106 |
| \\ / A nd | Website: www.openfoam.com |
| \\/ M anipulation | |
\*---------------------------------------------------------------------------*/
Build : _c15bfde3cb-20210624 OPENFOAM=2106
Arch : "LSB;label=32;scalar=64"
Exec : interFoam
Date : Aug 16 2021
Time : 03:23:02
Host : valerio-Z370-HD3P
PID : 190691
I/O : uncollated
Case : ~/OpenFOAM/Tanks/2021/RobustControl/Hemisphere_WEC/40N
nProcs : 1
trapFpe: Floating point exception trapping enabled (FOAM_SIGFPE).
fileModificationChecking : Monitoring run-time modified files using timeStampMaster (fileModificationSkew 5, maxFileModificationPolls 20)
allowSystemOperations : Allowing user-supplied system call operations
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
Create time
Create mesh for time = 0
Selecting dynamicFvMesh dynamicMotionSolverFvMesh
Selecting motion solver: sixDoFRigidBodyMotion
Applying solid body motion to entire mesh
Selecting sixDoFSolver Newmark
Translational constraint tensor (0 0 0 0 0 0 0 0 1)
Rotational constraint tensor (0 0 0 0 0 0 0 0 0)
PIMPLE: Operating solver in PISO mode
Reading field p_rgh
Reading field U
Reading/calculating face flux field phi
Reading transportProperties
Selecting incompressible transport model Newtonian
Selecting incompressible transport model Newtonian
Selecting turbulence model type laminar
Selecting laminar stress model Stokes
Reading g
Reading hRef
Calculating field g.h
No MRF models present
No finite volume options present
GAMGPCG: Solving for pcorr, Initial residual = 0, Final residual = 0, No Iterations 0
GAMGPCG: Solving for pcorr, Initial residual = 0, Final residual = 0, No Iterations 0
GAMGPCG: Solving for pcorr, Initial residual = 0, Final residual = 0, No Iterations 0
time step continuity errors : sum local = 0, global = 0, cumulative = 0
Constructing face velocity Uf
Courant Number mean: 0 max: 0
Starting time loop
forces forces:
rho: rhoInf
Freestream density (rhoInf) set to 1000
Not including porosity effects
Courant Number mean: 0 max: 0
Interface Courant Number mean: 0 max: 0
Time = 0.001
PIMPLE: iteration 1
forces forces:
rho: rho
Not including porosity effects
Restraint Spring: attachmentPt - anchor (0 0 2.678) spring length 2.678 force (-0 -0 -16.0364)
Restraint PTO: attachmentPt - anchor (0 0 2.678) spring length 2.678 control force (0 0 0.0024) control force raw0.0024 nTimes4
6-DoF rigid body motion
Centre of rotation: (0 0 -0.131)
Centre of mass: (0 0 -0.131)
Orientation: (1 0 0 0 1 0 0 0 1)
Linear velocity: (0 0 -1.46985e-05)
Angular velocity: (0 0 0)
Selecting waveModel shallowWaterAbsorption
--> FOAM FATAL ERROR: (openfoam-2106)
Field<vector> f1(5085) and Field<vector> f2(0)
for operation f1 = s & f2
From void Foam::checkFields(const Foam::UList<T>&, const Foam::UList<Key>&, const char*) [with Type1 = Foam::Vector<double>; Type2 = Foam::Vector<double>]
in file ~/OpenFOAM/OpenFOAM-v2106/src/OpenFOAM/lnInclude/FieldM.H at line 58.
FOAM aborting
#0 Foam::error::printStack(Foam::Ostream&) at ~/OpenFOAM/OpenFOAM-v2106/src/OSspecific/POSIX/printStack/printStack.C:237
#1 Foam::error::exitOrAbort(int, bool) at ~/OpenFOAM/OpenFOAM-v2106/src/OpenFOAM/lnInclude/error.C:261
#2 Foam::error::abort() at ~/OpenFOAM/OpenFOAM-v2106/src/OpenFOAM/lnInclude/error.C:297
#3 Foam::Ostream& Foam::operator<< <Foam::error>(Foam::Ostream&, Foam::errorManip<Foam::error>) in ~/OpenFOAM/OpenFOAM-v2106/platforms/linux64GccDPInt32Debug/bin/interFoam
#4 void Foam::checkFields<Foam::Vector<double>, Foam::Vector<double> >(Foam::UList<Foam::Vector<double> > const&, Foam::UList<Foam::Vector<double> > const&, char const*) in ~/OpenFOAM/OpenFOAM-v2106/platforms/linux64GccDPInt32Debug/bin/interFoam
#5 void Foam::dot<Foam::Tensor<double>, double, (unsigned char)9, Foam::Vector<double> >(Foam::Field<Foam::innerProduct<Foam::Tensor<double>, Foam::Vector<double> >::type>&, Foam::VectorSpace<Foam::Tensor<double>, double, (unsigned char)9> const&, Foam::UList<Foam::Vector<double> > const&) at ~/OpenFOAM/OpenFOAM-v2106/src/OpenFOAM/lnInclude/FieldFunctions.C:827
#6 Foam::tmp<Foam::Field<Foam::innerProduct<Foam::Tensor<double>, Foam::Vector<double> >::type> > Foam::operator&<Foam::Tensor<double>, double, (unsigned char)9, Foam::Vector<double> >(Foam::VectorSpace<Foam::Tensor<double>, double, (unsigned char)9> const&, Foam::UList<Foam::Vector<double> > const&) at ~/OpenFOAM/OpenFOAM-v2106/src/OpenFOAM/lnInclude/FieldFunctions.C:827
#7 Foam::waveModel::initialiseGeometry() at ~/OpenFOAM/OpenFOAM-v2106/src/waveModels/waveModel/waveModel.C:94 (discriminator 1)
#8 Foam::waveModel::readDict(Foam::dictionary const&) at ~/OpenFOAM/OpenFOAM-v2106/src/waveModels/waveModel/waveModel.C:323 (discriminator 2)
#9 Foam::waveModels::waveAbsorptionModel::readDict(Foam::dictionary const&) at ~/OpenFOAM/OpenFOAM-v2106/src/waveModels/waveAbsorptionModels/base/waveAbsorptionModel/waveAbsorptionModel.C:80
#10 Foam::waveModels::shallowWaterAbsorption::readDict(Foam::dictionary const&) at ~/OpenFOAM/OpenFOAM-v2106/src/waveModels/waveAbsorptionModels/derived/shallowWaterAbsorption/shallowWaterAbsorption.C:115
#11 Foam::waveModels::shallowWaterAbsorption::shallowWaterAbsorption(Foam::dictionary const&, Foam::fvMesh const&, Foam::polyPatch const&, bool) at ~/OpenFOAM/OpenFOAM-v2106/src/waveModels/waveAbsorptionModels/derived/shallowWaterAbsorption/shallowWaterAbsorption.C:104
#12 Foam::waveModel::addpatchConstructorToTable<Foam::waveModels::shallowWaterAbsorption>::New(Foam::dictionary const&, Foam::fvMesh const&, Foam::polyPatch const&) at ~/OpenFOAM/OpenFOAM-v2106/src/waveModels/lnInclude/waveModel.H:184 (discriminator 2)
#13 Foam::waveModel::New(Foam::word const&, Foam::fvMesh const&, Foam::polyPatch const&) at ~/OpenFOAM/OpenFOAM-v2106/src/waveModels/waveModel/waveModelNew.C:81
#14 Foam::waveModel::lookupOrCreate(Foam::polyPatch const&, Foam::fvMesh const&, Foam::word const&) at ~/OpenFOAM/OpenFOAM-v2106/src/waveModels/waveModel/waveModelNew.C:98 (discriminator 1)
#15 Foam::waveVelocityFvPatchVectorField::updateCoeffs() at ~/OpenFOAM/OpenFOAM-v2106/src/waveModels/derivedFvPatchFields/waveVelocity/waveVelocityFvPatchVectorField.C:112
#16 Foam::fvPatchField<Foam::Vector<double> >::evaluate(Foam::UPstream::commsTypes) at ~/OpenFOAM/OpenFOAM-v2106/src/finiteVolume/lnInclude/fvPatchField.C:340
#17 Foam::GeometricField<Foam::Vector<double>, Foam::fvPatchField, Foam::volMesh>::Boundary::evaluate() in ~/OpenFOAM/OpenFOAM-v2106/platforms/linux64GccDPInt32Debug/bin/interFoam
#18 Foam::GeometricField<Foam::Vector<double>, Foam::fvPatchField, Foam::volMesh>::correctBoundaryConditions() in ~/OpenFOAM/OpenFOAM-v2106/platforms/linux64GccDPInt32Debug/bin/interFoam
#19 Foam::dynamicMotionSolverFvMesh::update() at ~/OpenFOAM/OpenFOAM-v2106/src/dynamicFvMesh/dynamicMotionSolverFvMesh/dynamicMotionSolverFvMesh.C:135
#20 ? in ~/OpenFOAM/OpenFOAM-v2106/platforms/linux64GccDPInt32Debug/bin/interFoam
#21 __libc_start_main in /lib/x86_64-linux-gnu/libc.so.6
#22 ? in ~/OpenFOAM/OpenFOAM-v2106/platforms/linux64GccDPInt32Debug/bin/interFoam
```
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v1806|v1812|v1906|v1912|v2006|v2012|v2106 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version :v1812 | v2106
- Operating system :ubuntu (mint)
- Hardware info :Intel i7
- 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
-->
It seems that the inner product vector * tensor ,fails a dimension check because the second operand (tensor) is "seen" with 0 dimension, while it is not. Maybe a problem with the template for the double type in the Debug case??[WaveTank_s.tar.gz](/uploads/1bce0558586853ce59222151f8476815/WaveTank_s.tar.gz)Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2246chtMultiRegionFoam looses heat due to explicit coupling2021-10-27T17:02:48ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comchtMultiRegionFoam looses heat due to explicit coupling### Functionality to add/problem to solve
chtMultiRegionFoam looses heat when evaluating 'mapped' type bcs (e.g. `compressible::turbulentTemperatureRadCoupledMixed`). This is because the owner side evaluates with 'old' neighbour side va...### Functionality to add/problem to solve
chtMultiRegionFoam looses heat when evaluating 'mapped' type bcs (e.g. `compressible::turbulentTemperatureRadCoupledMixed`). This is because the owner side evaluates with 'old' neighbour side values but the neighbour side evaluates with the 'new'
owner side values.
This should instead use a scheme where the owner side also updates the neighbour side patch.
### Target audience
cht on closed domains. See e.g. https://develop.openfoam.com/Development/openfoam/-/blob/develop/applications/test/multiWorld/solidFoam/solid1_solid2 testcase.
Switch off the kappaLayers, switch to transient, switch on the debug flag for the BC so it prints the heat flux for both sides.https://develop.openfoam.com/Development/openfoam/-/issues/2216interCondensatingEvaporatingFoam: interfaceHeatResistance model failing for c...2021-10-29T07:57:20ZMoritz MuthinterCondensatingEvaporatingFoam: interfaceHeatResistance model failing for condensation cases### Summary
I initialized a stefans problem case inside a rectangular domain with a small liquid film on the bottom wall and a vapour phase above the film. The film was set to a temperature 10K below the saturation temperature while the ...### Summary
I initialized a stefans problem case inside a rectangular domain with a small liquid film on the bottom wall and a vapour phase above the film. The film was set to a temperature 10K below the saturation temperature while the vapour was at saturation temperature. The phase change model used was the interfaceHeatResistance model. The top wall is hot and the bottom wall cold, gravity is off. Condensation should appear and the film should grow, while the evaporation massflux should be zero.
The condensation mass flux, which can be viewed in ParaView, seems to produce the correct value but there is also an evaporation mass flux, which is none zero. Also there is a strange behavior within the interface area calculation, which seems to randomly add parts of the walls. If i reversed the temperature setting and looked at an evaporation case the right behavior with growing vapour phase occurred.
### Steps to reproduce
Run the attached testcase, look at the mass fluxes and alpha-field in ParaView, especially at the interface.
### Example case
The example case is attached. [Example_case.zip](/uploads/4b1b23eb3154eb27a9cb0ac217df36e5/Example_case.zip)
### What is the current *bug* behaviour?
The solver produces an evaporation mass flux which isn't set to zero for a condensation case (T < Tsat). For information: In the reversed case (evaporation) the condensation mass flux is set to zero. Also the solver uses an wrong interface area with parts of the side walls.
### What is the expected *correct* behavior?
The evaporation mass flux should be set to zero in the case of a condensation case. And the liquid film should grow depending on the analytic solution for the Stefans problem. The interface area, which the solver uses, should only be the interface between the liquid and the vapour phase.https://develop.openfoam.com/Development/openfoam/-/issues/2192chtMultiRegionFoam -postProcess does not work2021-10-29T13:46:19ZHenning ScheuflerchtMultiRegionFoam -postProcess does not work
### Summary
The postProcessing results generated by postProcess and during runtime are not identical
### Steps to reproduce
./Allrun
and compare the postProcessing results
### Example case
[multiRegionHeater.tar.xz](/uploads/0901...
### Summary
The postProcessing results generated by postProcess and during runtime are not identical
### Steps to reproduce
./Allrun
and compare the postProcessing results
### Example case
[multiRegionHeater.tar.xz](/uploads/0901403264338b6e67029780bb33ce6b/multiRegionHeater.tar.xz)
### What is the current *bug* behaviour?
The results obtained by function object, probe and wallheatFlux, differ from the runtime results. The wallHeatflux and the temperature probe produce the same value for the whole time series. However, we see the correct behavior for the pressure ,p , with the probe function object
Is the temperature reloaded in the thermoLibraries?
PS the same behavior can also be observed in rhoPimpleFoam tut-case: helmholtzResonance
### What is the expected *correct* behavior?
The results should be identical
### Environment information
- OpenFOAM version : 2012
- Operating system : Ubuntu 2004
- Hardware info :
- 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
-->https://develop.openfoam.com/Development/openfoam/-/issues/1631Writing fields with layer information makes snappyHexMesh crash in motorbike ...2021-10-29T20:19:32ZRiccardo RossiWriting fields with layer information makes snappyHexMesh crash in motorbike tutorial (reopen)I've just tried to test the issue reported in #1420 with the v1912 and it's still there:
`
Writing fields with layer information:
nSurfaceLayers : actual number of layers
thickness : overall layer thickness
[0] #0 [1...I've just tried to test the issue reported in #1420 with the v1912 and it's still there:
`
Writing fields with layer information:
nSurfaceLayers : actual number of layers
thickness : overall layer thickness
[0] #0 [1] #0 [2] #0 [3] #0 [4] #0 [5] #0 Foam::error::printStack(Foam::Ostream&)Foam::error::printStack(Foam::Ostream&)Foam::error::printStack(Foam::Ostream&)Foam::error::printStack(Foam::Ostream&)Foam::error::printStack(Foam::Ostream&)Foam::error::printStack(Foam::Ostream&) at at ??:?
`https://develop.openfoam.com/Development/openfoam/-/issues/2189Cannot find parcel injection cell2021-11-01T12:12:49ZCongyaoCannot find parcel injection cell<!--
*** 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 -->
I'm modelling a moving rigid sphere in a medium and including lagrangian particles to trace the gas flow. But I've always met the following error:
"--> FOAM FATAL ERROR:
Cannot find parcel injection cell. Parcel position = (-5.63103 21.11 -1)"
I don't know if this is a bug or there is anything I missed. Thanks!
### 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
-->
[pimpleLPTFoam.7z](/uploads/eecf8e4772c48906b1810294f1522f55/pimpleLPTFoam.7z)
[movingCone.7z](/uploads/3fee1e9f0df2873cb3ffcc781f8ef9be/movingCone.7z)
The solver simply includes lagrangian particles in the pimpleFoam.
### What is the current *bug* behaviour?
When topology changes, particles penetrate the moving wall boundary.
### What is the expected *correct* behavior?
Particles should be reflected by the wall.
### 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|v1912|v2006|v2012|v2106 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2106
- Operating system : ubuntu
- 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/2174Possibly wrong online documentation for omegaWallFunction2021-11-01T12:30:40ZGabriel SantosPossibly wrong online documentation for omegaWallFunctionThe [omegaWallFunction](https://www.openfoam.com/documentation/guides/latest/doc/guide-bcs-wall-turbulence-omegaWallFunction.html) entry in the User Guide states that the `blinding stepwise;` is used by default. However, in [omegaWallFun...The [omegaWallFunction](https://www.openfoam.com/documentation/guides/latest/doc/guide-bcs-wall-turbulence-omegaWallFunction.html) entry in the User Guide states that the `blinding stepwise;` is used by default. However, in [omegaWallFunctionFvPatchScalarField.H](https://www.openfoam.com/documentation/guides/latest/api/omegaWallFunctionFvPatchScalarField_8H_source.html#l00239) the code actually adopts `blending binomial2;` by default.
Perhaps this should be corrected in the online documentation.Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1681SPDP : time precision2021-11-02T09:38:58ZPrashant SonakarSPDP : time precision### Functionality to add/problem to solve
The time is stored as scalar, which can accumulate truncation errors. This can show problems with follow-on applications e.g. noise
### Proposal
- Change storage of time as e.g. solveScalar an...### Functionality to add/problem to solve
The time is stored as scalar, which can accumulate truncation errors. This can show problems with follow-on applications e.g. noise
### Proposal
- Change storage of time as e.g. solveScalar and adjust API accordingly.
- look at interpolating times e.g. temporalInterpolate
### What does success look like, and how can we measure that?
- damBreak tutorial example with changes in controlDict writeControl = runTime, adjustableTimeStep=false
- run in SPDP or SP mode.
- till 0.3 folders are good, but later have fractions e.g. 0.349999
@andy @Mattijs https://develop.openfoam.com/Development/openfoam/-/issues/1798Reduce verbosity of hexRef8Data2021-11-02T09:57:21ZTimofey MukhaReduce verbosity of hexRef8DataHello!
When running reconstructPar in a case with AMR (following reconstructParMesh), the terminal is flooded with
````Reading hexRef8 data : cellLevel
Reading hexRef8 data : pointLevel
Reading hexRef8 data : level0Edge
Reading hexRef...Hello!
When running reconstructPar in a case with AMR (following reconstructParMesh), the terminal is flooded with
````Reading hexRef8 data : cellLevel
Reading hexRef8 data : pointLevel
Reading hexRef8 data : level0Edge
Reading hexRef8 data : refinementHistory
````
statements. Seems like this stems from Info statements in `Foam::hexRef8Data::hexRef8Data(const IOobject& io)`
In the case of reconstructPar the verbosity seems to definitely be redundant. Is it critical under other circumstances? Perhaps put the Infos under an `if (debug)` ?https://develop.openfoam.com/Development/openfoam/-/issues/1876icoUncoupledKinematicParcelFoam description2021-11-02T10:12:25ZAndrew RobertsicoUncoupledKinematicParcelFoam descriptionHello,
I hope this is not an inconvenient time, I am using icoUncoupledKinematicParcelFoam and I just wondered if you knew of any mathematical description of the approach (esp parcel definition, governing equations, integration)? I am on...Hello,
I hope this is not an inconvenient time, I am using icoUncoupledKinematicParcelFoam and I just wondered if you knew of any mathematical description of the approach (esp parcel definition, governing equations, integration)? I am only interested for academic purposes. I've been told to tag @Sergio. Cheers!
Kind regards,
Andyhttps://develop.openfoam.com/Development/openfoam/-/issues/2227pimpleFoam and pisoFoam deltaT not respecting controlDict value when running ...2021-11-02T10:13:48ZAaronpimpleFoam and pisoFoam deltaT not respecting controlDict value when running SPDP (but does for DP)### Summary
deltaT is not being respected by pimpleFoam and pisoFoam when in SPDP. This is for a deltaT of 7.5e-05, so not an issue of being too small for single precision. When solving in DP, deltaT is as expected.
### Steps to reprodu...### Summary
deltaT is not being respected by pimpleFoam and pisoFoam when in SPDP. This is for a deltaT of 7.5e-05, so not an issue of being too small for single precision. When solving in DP, deltaT is as expected.
### Steps to reproduce
Simply run pimpleFoam, both in SPDP and DP to see how DP respects the deltaT prescribed in controlDict, while SPDP generates a random value. The random value is not even very close to the controlDict deltaT (it's off by ~20%), and it varies with each iteration. This prevents endTime writing on the last iteration, makes results processing difficult, etc.
### Example case
https://www.dropbox.com/s/bmfxslcx7lj3wec/issue2227_deltaT_SPDP.tar.xz?dl=0
I have a solved (steady state) 500k cell case which is about ~50Mb. I can send it through another channel if you prefer.
### What is the current *bug* behaviour?
Random deltaT - differing from controlDict value by up to 20% - being applied to each iteration when running SPDP
### What is the expected *correct* behavior?
deltaT per controlDict, as is the case when running DP
### Relevant logs and/or images
controlDict
```
startFrom startTime;
**startTime 400;**
stopAt endTime;
endTime 400.20025;
**deltaT 7.5e-05;**
writeControl timeStep;
writeInterval 267;
monStart 400.1002;
purgeWrite 100;
writeFormat ascii;
writeCompression on;
writePrecision 7;
timeFormat general;
timePrecision 11;
runTimeModifiable yes;
```
DP - expected behavior
```
Build : f4ccdec894-20210902 OPENFOAM=2012 patch=210618
Arch : "LSB;label=32;scalar=64"
Starting time loop
Courant Number mean: 0.007378641 max: 2.702994
**Time = 400.000075**
PIMPLE: iteration 1
velocityDampingConstraint damp damped 3 (0.000564893%) of cells
smoothSolver: Solving for Ux, Initial residual = 4.640301e-07, Final residual = 1.441689e-08, No Iterations 1
smoothSolver: Solving for Uy, Initial residual = 4.99919e-05, Final residual = 5.043536e-08, No Iterations 3
smoothSolver: Solving for Uz, Initial residual = 6.165809e-06, Final residual = 1.953994e-08, No Iterations 2
GAMG: Solving for p, Initial residual = 0.3755113, Final residual = 0.02669367, No Iterations 1
GAMG: Solving for p, Initial residual = 0.02671251, Final residual = 0.001826018, No Iterations 3
time step continuity errors : sum local = 1.271702e-09, global = 1.048906e-11, cumulative = 1.048906e-11
GAMG: Solving for p, Initial residual = 0.01341298, Final residual = 0.000939755, No Iterations 2
GAMG: Solving for p, Initial residual = 0.001842091, Final residual = 9.379453e-07, No Iterations 28
time step continuity errors : sum local = 6.500214e-13, global = 2.663773e-17, cumulative = 1.048909e-11
smoothSolver: Solving for omega, Initial residual = 2.509855e-07, Final residual = 1.21354e-08, No Iterations 1
bounding omega, min: -5721.012 max: 283395.7 average: 3373.21
smoothSolver: Solving for k, Initial residual = 7.494289e-06, Final residual = 1.253224e-08, No Iterations 2
bounding k, min: -36.23042 max: 384.4423 average: 11.56855
ExecutionTime = 2.98 s ClockTime = 3 s
Courant Number mean: 0.007378645 max: 2.242397
**Time = 400.00015**
```
SPDP - strange time step which is different from DP and controlDict specification
```
Build : 4245909efb-20210203 OPENFOAM=2012
Arch : "LSB;label=32;scalar=32;solveScalar=64"
Starting time loop
Courant Number mean: 0.007378641 max: 2.703078
**Time = 400.00006104**
PIMPLE: iteration 1
velocityDampingConstraint damp damped 3 (0.000564893%) of cells
smoothSolver: Solving for Ux, Initial residual = 5.07782e-07, Final residual = 1.456293e-08, No Iterations 1
smoothSolver: Solving for Uy, Initial residual = 4.999212e-05, Final residual = 5.043533e-08, No Iterations 3
smoothSolver: Solving for Uz, Initial residual = 6.165838e-06, Final residual = 1.953989e-08, No Iterations 2
GAMG: Solving for p, Initial residual = 0.3754919, Final residual = 0.02666569, No Iterations 1
GAMG: Solving for p, Initial residual = 0.02669024, Final residual = 0.00183339, No Iterations 3
time step continuity errors : sum local = 1.534634e-09, global = 7.045955e-12, cumulative = 7.045955e-12
GAMG: Solving for p, Initial residual = 0.01344812, Final residual = 0.0009438513, No Iterations 2
GAMG: Solving for p, Initial residual = 0.001842122, Final residual = 9.032984e-07, No Iterations 29
time step continuity errors : sum local = 3.146365e-10, global = 1.095093e-12, cumulative = 8.141048e-12
smoothSolver: Solving for omega, Initial residual = 2.511907e-07, Final residual = 1.21357e-08, No Iterations 1
bounding omega, min: -5721.12 max: 283415 average: 3373.219
smoothSolver: Solving for k, Initial residual = 7.494291e-06, Final residual = 1.253221e-08, No Iterations 2
bounding k, min: -36.23087 max: 384.4427 average: 11.56855
ExecutionTime = 2.36 s ClockTime = 3 s
Courant Number mean: 0.007378645 max: 2.242493
**Time = 400.00012207**
```
### Environment information
- OpenFOAM version : v2012 & v2106
- Operating system : ubuntu1804
- Hardware info : x86
- Compiler : gcchttps://develop.openfoam.com/Development/openfoam/-/issues/2258createBaffles/mergeOrSplitBaffles does not duplicate points correctly2021-11-04T15:20:34ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comcreateBaffles/mergeOrSplitBaffles does not duplicate points correctly<!--
*** 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 -->
mergeOrSplitBaffles can duplicate points. It uses the underlying `localPointRegion` class to determine which faces should use what duplicate of the point. This class does not correctly mark points if a cell is fully surrounded by baffles.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Tested this only with a hacked version of extrudeMesh that does extrusion of a faceZone with internal and boundary faces. Not sure if the createBaffles/mergeOrSlitBaffles route has the same effect.
### Example case
[corner_blocked_2D.tgz](/uploads/a3acc10b5999552185cfa8726a79439d/corner_blocked_2D.tgz)
<!--
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 -->
Incorrect topology since face which is point connected to a duplicated point does not get renumbered to use the new duplicated point.
### What is the expected *correct* behavior?
<!-- What you should see instead -->
2x2x1 cells with bottom left cell (cell 0) having cells on its two internal faces and one boundary face.
### 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|v1912|v2006|v2012|v2106 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
-->
Problem is in the localPointRegion class where it walks out the per-region point connectivity. Its set of 'candidate faces' does not include the faces that become blockages so if another face only uses points from those it will not be detected as needing to use a duplicate.Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/2260forceCoeffs FO: pitchAxis keyword has no effect2021-11-08T08:35:56Zs1291forceCoeffs FO: pitchAxis keyword has no effectWhen using the `forceCoeffs` function object, it seems that the `pitchAxis` keyword has no effect. It is always set to `coordSys_.e2()`
**How to reproduce**
* Example 1: Run the tutorial: `$FOAM_TUTORIALS/incompressible/simpleFoam/simpl...When using the `forceCoeffs` function object, it seems that the `pitchAxis` keyword has no effect. It is always set to `coordSys_.e2()`
**How to reproduce**
* Example 1: Run the tutorial: `$FOAM_TUTORIALS/incompressible/simpleFoam/simpleCar`
* Example 2: Run the tutorial: `$FOAM_TUTORIALS/compressible/sonicFoam/RAS/nacaAirfoil`
Set the `pitchAxis` to some vector , the output in `postProcessing` directory will ignore that and prints the `e2` vector instead.
Checking the source code of the FO, it appears that `pitchAxis` keyword is not read. So, the presence of this keyword in the tutorials dir is _misleading_.
Running:
```
grep -r 'pitchAxis' $FOAM_TUTORIALS
```
Returns 7 tutorials using that keyword.
**OpenFOAM version**
* OpenFOAM v2106 on Ubuntu 20.04https://develop.openfoam.com/Development/openfoam/-/issues/1683Overset, inverseDistance and wall contact, possible fix2021-11-19T15:19:03ZNicolas EdhOverset, inverseDistance and wall contact, possible fix### Summary
cellTypes isn't calculated correctly when walls are close or overlaps. This is a known issue. I'm proposing a fix below for inverseDistance.
### Steps to reproduce
Run the attached testcase with inverseDistance. Any other t...### Summary
cellTypes isn't calculated correctly when walls are close or overlaps. This is a known issue. I'm proposing a fix below for inverseDistance.
### Steps to reproduce
Run the attached testcase with inverseDistance. Any other tutorial is also fine just move overset meshes outside the domain.
### Example case
I’m attaching a small test case with two zones. The second zone is object that slides along the wall of the background mesh. This case works with my proposed fixes to inverseDistance. It also works with cellVolumeWeight but one has to copy cellTypes from a fixed inverseDistanceStencil to the first time step.
[wallcontact.tgz](/uploads/56c7f38dc21a0c3dda2abf907f850a7b/wallcontact.tgz)
### What is the current *bug* behaviour?
cellTypes isn't calculated correctly when walls are close or overlaps. This is a known issue, e.g. buggs [1636](https://develop.openfoam.com/Development/openfoam/issues/1636) or [1288](https://develop.openfoam.com/Development/openfoam/issues/1288).
### What is the expected *correct* behavior?
Something like the attached animation =)
[proof.avi](/uploads/9ddb09c777b3eda6ca42c0199b2b25e6/proof.avi)
Due to the coarseness of the mesh of the attached case a rather large part of where the walls intersect is cut out. I think this could be improved by a better selection of nDivs. Currently we select the number of divisions bases on sqrt(nCells) (2D). nCells is based on the entire mesh. A better choice would be sqrt(nCells) for each zone. Still this would not guarantee the same size of the voxels across processors. However for this type of case refining the mesh near the wall should be enough or manually setting nDivs.
### Environment information
OpenFOAM version : v1912
Operating system : any
Hardware info : Intel Xeon
Compiler : gcc
### Possible fixes
A first step to allowing wall contact is to make sure the cellCellStencils calculate cellTypes correctly. This is a proposed fix: [inverseDistanceCellCellStencil.C](/uploads/cf528a31bcb8523b8bcd21766d44f08a/inverseDistanceCellCellStencil.C)
There are three changes needed to inverseDistance in order for it to work and two more which I find convenient when debugging. I’m attaching a version with all five fixes.
* In markDonors we exclude primary donors that are HOLE. It’s better to include them. See attached figure of “allStencil_hole”. The near wall cells are considered HOLE. This will create a gap for walkFront to spill out from. When walkFront “spills out” we kill the entire background mesh.
There are two checks in markDonors;
`if (srcCelli != -1 && allCellTypes[srcCellMap[srcCelli]] != HOLE)`
That should be changed to
`if (srcCelli != -1)`
![badStencil_hole](/uploads/b9d48393d66b5241cd6d1fd53efe2de0/badStencil_hole.png)
* In createStencil, HOLE cells are excluded. Meaning if the primary donor is a HOLE we don’t even try to find suitable donors among its neighbours. We have two options here that both work,
1. Try to find donors and keep them even if they are all holes. It seems like nonsense but it will work. This is what’s done in cellVolumeWeight. In order to accomplish this just keep isValidDonor true for all cells. I.e. skip the loop right after it’s created.
2. The other option is to set the amount of interpolation to zero, i.e. set
cellInterpolationWeight to zero. For this to work, we still need to have isValidDonor true otherwise the cell will be removed by globalCellCells and set to HOLE.
After createStencil we need to set the “amount of interpolation to zero”. This option is what is included in the attaced file.
* In update(), right after allCellType_patch is written a check with cellTypes from the previous time step is performed. If cells have changed from HOLE to calculated they are set to interpolated. This check is no longer necessary for inverseDistance (but is what makes cellVolumeWeight work). In fact the check should be removed. The check can cause additional layers of interpolation cells which aren’t need nor wanted. This will happen for mesh courant numbers above one. To illustrate, imagine a cylinder which in one time step move say half its diameter. Half the cells where the cylinder was the prevous time step but isn’t now would be interpolated. Wolfdynamics has a nice illustration of this here: https://youtu.be/kVMA7_1YvH0?list=PLoI86R1JVvv_rDlODjff5LUWD4WX9G9vc&t=1218
* The fourth change isn’t necessary but makes debugging easier. The stencil is written out as an wavefront file. I would prefer if one file is written per region.
* I also find it use full to create a field with the size of the final stencil.
### Disclaimer
These patches just make inverseDistance behave with some sort of decency if walls between meshes are close. It’s not a guarantee that it will work. Mass won’t be preserved at all if there is a large change in volume. Change the movement to y direction instead in the test case. But I still think these patches should be included. There are many cases were only a moderate change in volume takes place when walls interact.
Secondly another solution is required for where walls intersect. The currently solution doesn’t crash and should be stable but an additional error will be introduced. For the cases I’ve tried this error is still smaller than the general mass preservation problem already present. I’ve been looking in to that with little success. At the moment I take note that overset in foam-extend is *exact* in terms of mass balance. For the same case (where no wall-to-wall interaction occurs) v1912 might have 5% error in mass while extend has an error in the order of the tolerance in the pressure equation. If there is interest I could file a different bug with my findings but I have no fix only indications to where the problem is.https://develop.openfoam.com/Development/openfoam/-/issues/2156waveMethod called from inverseDistanceCellCellStencil returns error for empty...2021-11-19T15:20:54ZLouiswaveMethod called from inverseDistanceCellCellStencil returns error for empty source processors
### Summary
inverseDistanceCellCellStencil calls waveMethod::calculate(tgtMesh, srcMesh, tgtToSrcAddr) which then calls
FaceCellWave<meshToMeshData, meshToMeshData::trackData> calc
(
src,
...
### Summary
inverseDistanceCellCellStencil calls waveMethod::calculate(tgtMesh, srcMesh, tgtToSrcAddr) which then calls
FaceCellWave<meshToMeshData, meshToMeshData::trackData> calc
(
src,
changedFaces,
changedFacesInfo,
faceData,
cellData,
src.globalData().nTotalCells(), // max iterations
td
);
which will return an error when src.globalData().nTotalCells() is 0.
A solution is to add 1 (works for me) or maybe, more logical, make a max(1,src.globalData().nTotalCells())
### What is the current *bug* behaviour?
returns error
> Maximum number of iterations reached. Increase maxIter.
### What is the expected *correct* behavior?
overset runs
### Environment information
I think hierarchical is particularly sensible to this issue.
### Possible fixes
mentioned above
PS: I'm not sure I can get this error for the "standard" code, as I haven't tested if empty src is possible. I'm using a modified B-box inverseDistance scheme...Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/2225chtMultiRegionSimpleFoam - frozenFlow mode results in large errors2021-12-06T20:45:03ZKumar KrishnachtMultiRegionSimpleFoam - frozenFlow mode results in large errorsRunning chtMultiRegionSimpleFoam on a converged flow by activating the frozenFlow switch to calculate the heat transport results in fairly large deviations in the final temperatures as opposed to running the case in the "normal" (fully c...Running chtMultiRegionSimpleFoam on a converged flow by activating the frozenFlow switch to calculate the heat transport results in fairly large deviations in the final temperatures as opposed to running the case in the "normal" (fully coupled) mode.
Attached is a 2D case to illustrate the problem. It is a simple case of water flowing at high velocity through a narrow channel above a copper plate which is heated from below.
To reproduce the problem, please do the following steps:
(1) Run the case as it is. The case runs in fully coupled mode for 2000 iterations.
(2) Run the case for the first 1000 iterations by turning off the (h|e) solvers in the ./system/copper/fvSolution and ./system/water/fvSolution subdirectories, i.e, please activate the 'maxIter 0' statement.
(3) Now please turn on the frozenFlow keyword in the PIMPLE subdict and run for another 1000 iterations. In this case, deactivate the 'maxIter 0' statement in the respective fvSolution dicts.
We can see that the Temp. results obtained at the end of 2000 iterations in both cases are very different.
[ConjCopperWater.tar.gz](/uploads/9bbe5fd5dedce1ef301d0f0f8c86b96a/ConjCopperWater.tar.gz)
**Environment Information**
- OpenFOAM Version: v2106
- Operating System: Windows 10 (MinGW)
- Hardware Info: PC (HP Z240)https://develop.openfoam.com/Development/openfoam/-/issues/2117codedFunctionObjects: Info stream in #codeRead is executed twice + Feature re...2021-12-09T16:43:11ZHendrik HetmanncodedFunctionObjects: Info stream in #codeRead is executed twice + Feature request: Info stream number of total cells to standard log.<!--
*** 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 -->
If an Info stream is executed in the #codeRead section of a codedFunctionObject, the line is shown twice. (I don't know if any variables might be assigned twice too?)
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Put a line
`Info << "Test" << endl;`
into the #codeRead section of a codedFunctionObject and run the case.
### Example case
I attached a codedFunctionObject "addCellsInfo" to the example case. This is also sort of a feature request: It would be very neat to report the number of total cells in the mesh to standard log on mesh built-up. This would increase the information content of the logs and consequently make it possible to compare the performance between 2 runs just by analyzing their log files.
[pitzDaily_codedfObj.tar.gz](/uploads/8cf5416c96d1d238c5f91dc041faa46d/pitzDaily_codedfObj.tar.gz)
<!--
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 : v1806|v1812|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2012 and also in OF7
- Operating system : openSUSE
- Hardware info :
- 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
-->Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2259Decomposition method issue2021-12-09T16:44:05ZAshutosh MauryaDecomposition method issueI don't know whether it is a issue or limitation of hierarchical method. I ran the simulation on 12 processors to calculate force on a airfoil. The issue is with hierarchical decomposition method gives wrong result while scotch gives cor...I don't know whether it is a issue or limitation of hierarchical method. I ran the simulation on 12 processors to calculate force on a airfoil. The issue is with hierarchical decomposition method gives wrong result while scotch gives correct result.