Development issueshttps://develop.openfoam.com/groups/Development/-/issues2023-11-14T18:53:27Zhttps://develop.openfoam.com/Development/openfoam/-/issues/2998Lagrangian ConeInjection model fails to restart smoothly2023-11-14T18:53:27ZAndrew HeatherLagrangian ConeInjection model fails to restart smoothlyWhen restarting cases with the ConeInjection injector model parcels typically fail to be injected/incorrect counts recorded.
Cross ref: EP2280When restarting cases with the ConeInjection injector model parcels typically fail to be injected/incorrect counts recorded.
Cross ref: EP2280v2312Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/issues/728Lagrangian Injections - Particles being removed from the system2019-12-09T22:18:10ZAdminLagrangian Injections - Particles being removed from the systemWithin the Lagrangian injections the incorrect mass is being introduced. This occurs when the number of particles per parcel becomes less than 1. As per the code in InjectionModel.C:
If (pPtr->nParticle() >= 1.0)
It is possible to redu...Within the Lagrangian injections the incorrect mass is being introduced. This occurs when the number of particles per parcel becomes less than 1. As per the code in InjectionModel.C:
If (pPtr->nParticle() >= 1.0)
It is possible to reduce the no. of parcels injected per second such that nP is satisfied -> however this workaround severely limits the accuracy for both the case that I'm investigating and in general
If (pPtr->nParticle() >= 1.0) is not satisfied a delayedVolume is created, however this doesn't seem to changed the results at all?
See: https://www.cfd-online.com/Forums/openfoam-solving/110325-incorrect-introduced-mass-sprayfoam.html#post595437https://develop.openfoam.com/Development/openfoam/-/issues/284Lagrangian Particle Tracking hangs in parallel - #2315@OpenFOAM-Foundation2018-09-19T16:59:31ZAdminLagrangian Particle Tracking hangs in parallel - #2315@OpenFOAM-FoundationFor full details, proposed bug fix and description of the reason why the bug happens, please check the original bug report and comments: http://bugs.openfoam.org/view.php?id=2315
Not only this is useful for OpenFOAM+, but the other re...For full details, proposed bug fix and description of the reason why the bug happens, please check the original bug report and comments: http://bugs.openfoam.org/view.php?id=2315
Not only this is useful for OpenFOAM+, but the other reason that I'm posting this here is because I could use a second/third opinion on this fix.
I'm not fully familiar with particle tracking within OpenFOAM and even though I debugged the this bug a few weeks ago for another similar type of simulation, the fix that I found, tested and proposed, seems to work as intended... but I have the nagging feeling in the back of my head that this particular fix was not used already in OpenFOAM in the past due to some other reason that I haven't seen yet.https://develop.openfoam.com/Development/openfoam/-/issues/447Lagrangian: problematic tracking with dynamic meshes2018-07-03T10:45:44ZAdminLagrangian: problematic tracking with dynamic meshesWhen using a dynamic mesh solver, the tracking of a particle may be wrong: the particle may not cross an internal face when it is moving parallel to other one. Particle rescues are not enough.
I attach a solver "dMeshSprayFoam" (based...When using a dynamic mesh solver, the tracking of a particle may be wrong: the particle may not cross an internal face when it is moving parallel to other one. Particle rescues are not enough.
I attach a solver "dMeshSprayFoam" (based on sprayDyMFoam but it only updates the mesh and evolved the particles) and a simple case named "EjemploMM". I also attach a video which shows the particle tracking problem.
After investigating the problem I found that it starts in line 175 of particleI.H: "tetPointRef tet00 = tetIs.oldTet(mesh_)". This tetrahedron has a problem in its first point which is an oldCellCenter calculated in line 89 of tetIndicesI.H.
I think that there is an issue with the memory reference of this point.
[ProblematicTracking.tar.gz](/uploads/72931680ec544f389a19e302882321a9/ProblematicTracking.tar.gz)![Injection](/uploads/2b61edcd19ff3b30d5d5b63fb9c09e82/Injection.ogv)https://develop.openfoam.com/Development/openfoam/-/issues/2426lagrangian/reactingParcelFoam/verticalChannelLTS Failing in v21122022-05-06T10:03:42ZPrashant Sonakarlagrangian/reactingParcelFoam/verticalChannelLTS Failing in v2112Tutorial runs fine if we change:
- constant/thermo.incompressiblePoly -> Hf and Sf to 0 for H20
- constant/reactingCloud1Properties -> liquidEvaporationCoeffs -> enthalpyTransfer latentHeat;
@Sergio Could you please review if this is r...Tutorial runs fine if we change:
- constant/thermo.incompressiblePoly -> Hf and Sf to 0 for H20
- constant/reactingCloud1Properties -> liquidEvaporationCoeffs -> enthalpyTransfer latentHeat;
@Sergio Could you please review if this is required?https://develop.openfoam.com/Development/openfoam/-/issues/1Lagrangian standard patch interaction model errors2023-08-19T21:13:18ZAdminLagrangian standard patch interaction model errorsReported statistics are incorrect
* Counters of number and mass of particles continuously reset on output
* Mass escape/stick not calculatedReported statistics are incorrect
* Counters of number and mass of particles continuously reset on output
* Mass escape/stick not calculatedFunctionality migration from internal development lineAdminAdminhttps://develop.openfoam.com/Development/openfoam/-/issues/935Lagrangian tracking can hang for particle exactly on cell centre2019-12-09T22:22:46ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comLagrangian tracking can hang for particle exactly on cell centreIf a particle gets seeded on exactly the cell centre (e.g. in particle::locate) the tracking might get stuck in a loop since all constituent tets all say the particle is outside.If a particle gets seeded on exactly the cell centre (e.g. in particle::locate) the tracking might get stuck in a loop since all constituent tets all say the particle is outside.Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/2316Lambda2 fails immediately in SPDP2024-01-10T10:49:39ZAaronLambda2 fails immediately in SPDPThis is very easy to reproduce :-) Just insert the lines below into controlDict for the motorBike tutorial and solve in SPDP.
Or, run postProcess -func Lambda2 in SPDP.
Expected behavior: running in both precisions (the Q functionObjec...This is very easy to reproduce :-) Just insert the lines below into controlDict for the motorBike tutorial and solve in SPDP.
Or, run postProcess -func Lambda2 in SPDP.
Expected behavior: running in both precisions (the Q functionObject, for example, produces practically identical results in both.)
```
Lambda2
{
timeStart 0;
type Lambda2;
writeControl writeTime;
executeControl timeStep;
executeInterval 1;
}
```
```
~/Desktop/motorBike$ mpirun -np 6 postProcess -func Lambda2 -parallel
/*---------------------------------------------------------------------------*\
| ========= | |
| \\ / F ield | OpenFOAM: The Open Source CFD Toolbox |
| \\ / O peration | Version: 2112 |
| \\ / A nd | Website: www.openfoam.com |
| \\/ M anipulation | |
\*---------------------------------------------------------------------------*/
Build : 145f29cc9a-20211221 OPENFOAM=2112 version=v2112
Arch : "LSB;label=32;scalar=32;solveScalar=64"
Exec : postProcess -func Lambda2 -parallel
Date : Jan 02 2022
Time : 23:31:35
Host : testing-laptop
PID : 12362
I/O : uncollated
WARNING: running without decomposeParDict "system/decomposeParDict"
Case : /home/testing/Desktop/motorBike
nProcs : 6
Hosts :
(
(testing-laptop 6)
)
Pstream initialized with:
floatTransfer : 0
nProcsSimpleSum : 0
commsType : nonBlocking
polling iterations : 0
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
Time = 0
Reading fields:
volVectorField: U
Executing functionObjects
[0] #0 Foam::error::printStack(Foam::Ostream&)[3] #0 Foam::error::printStack(Foam::Ostream&)[1] #0 Foam::error::printStack(Foam::Ostream&)[4] #0 Foam::error::printStack(Foam::Ostream&)[5] #0 Foam::error::printStack(Foam::Ostream&)[2] #0 Foam::error::printStack(Foam::Ostream&) at ??:?
at ??:?
at ??:?
at ??:?
[4] #1 Foam::sigFpe::sigHandler(int)[0] #1 Foam::sigFpe::sigHandler(int)[1] #1 Foam::sigFpe::sigHandler(int)[3] #1 Foam::sigFpe::sigHandler(int) at at ??:???:?
[5] #1 [2] #1 Foam::sigFpe::sigHandler(int)Foam::sigFpe::sigHandler(int) at ??:?
[1] #2 ? at ??:?
[0] #2 ? at at ??:?
[3] #??:?
2 ?[4] #2 ? at ??:?
[2] #2 ? at ??:?
[5] #2 ? in /lib/x86_64-linux-gnu/libpthread.so.0
in /lib/x86_64-linux-gnu/libpthread.so.0
[1] #3 Foam::cubicEqn::roots() const in /lib/x86_64-linux-gnu/libpthread.so.0
in /lib/x86_64-linux-gnu/libpthread.so.0
[3] #3 Foam::cubicEqn::roots() const[4] #3 [0] #3 Foam::cubicEqn::roots() constFoam::cubicEqn::roots() const in /lib/x86_64-linux-gnu/libpthread.so.0
in /lib/x86_64-linux-gnu/libpthread.so.0
[5] #3 Foam::cubicEqn::roots() const[2] #3 Foam::cubicEqn::roots() const at ??:?
at ??:?
[1] #4 [3] #4 Foam::eigenValues(Foam::SymmTensor<float> const&)Foam::eigenValues(Foam::SymmTensor<float> const&) at ??:?
at ??:?
[0] #4 Foam::eigenValues(Foam::SymmTensor<float> const&)[4] #4 Foam::eigenValues(Foam::SymmTensor<float> const&) at ??:?
[2] #4 Foam::eigenValues(Foam::SymmTensor<float> const&) at ??:?
[5] #4 Foam::eigenValues(Foam::SymmTensor<float> const&) at ??:?
[1] #5 Foam::eigenValues(Foam::Field<Foam::Vector<float> >&, Foam::UList<Foam::SymmTensor<float> > const&) at ??:?
[3] #5 Foam::eigenValues(Foam::Field<Foam::Vector<float> >&, Foam::UList<Foam::SymmTensor<float> > const&) at ??:?
at ??:?
[0] #5 Foam::eigenValues(Foam::Field<Foam::Vector<float> >&, Foam::UList<Foam::SymmTensor<float> > const&)[4] #5 Foam::eigenValues(Foam::Field<Foam::Vector<float> >&, Foam::UList<Foam::SymmTensor<float> > const&) at ??:?
[2] #5 Foam::eigenValues(Foam::Field<Foam::Vector<float> >&, Foam::UList<Foam::SymmTensor<float> > const&) at ??:?
[5] #5 Foam::eigenValues(Foam::Field<Foam::Vector<float> >&, Foam::UList<Foam::SymmTensor<float> > const&) at ??:?
[1] #6 Foam::tmp<Foam::GeometricField<Foam::Vector<float>, Foam::fvPatchField, Foam::volMesh> > Foam::eigenValues<Foam::fvPatchField, Foam::volMesh>(Foam::GeometricField<Foam::SymmTensor<float>, Foam::fvPatchField, Foam::volMesh> const&) at ??:?
[3] #6 Foam::tmp<Foam::GeometricField<Foam::Vector<float>, Foam::fvPatchField, Foam::volMesh> > Foam::eigenValues<Foam::fvPatchField, Foam::volMesh>(Foam::GeometricField<Foam::SymmTensor<float>, Foam::fvPatchField, Foam::volMesh> const&) at ??:?
[4] #6 Foam::tmp<Foam::GeometricField<Foam::Vector<float>, Foam::fvPatchField, Foam::volMesh> > Foam::eigenValues<Foam::fvPatchField, Foam::volMesh>(Foam::GeometricField<Foam::SymmTensor<float>, Foam::fvPatchField, Foam::volMesh> const&) at ??:?
at ??:?
[2] #6 [0] #6 Foam::tmp<Foam::GeometricField<Foam::Vector<float>, Foam::fvPatchField, Foam::volMesh> > Foam::eigenValues<Foam::fvPatchField, Foam::volMesh>(Foam::GeometricField<Foam::SymmTensor<float>, Foam::fvPatchField, Foam::volMesh> const&)Foam::tmp<Foam::GeometricField<Foam::Vector<float>, Foam::fvPatchField, Foam::volMesh> > Foam::eigenValues<Foam::fvPatchField, Foam::volMesh>(Foam::GeometricField<Foam::SymmTensor<float>, Foam::fvPatchField, Foam::volMesh> const&) at ??:?
[5] #6 Foam::tmp<Foam::GeometricField<Foam::Vector<float>, Foam::fvPatchField, Foam::volMesh> > Foam::eigenValues<Foam::fvPatchField, Foam::volMesh>(Foam::GeometricField<Foam::SymmTensor<float>, Foam::fvPatchField, Foam::volMesh> const&) at ??:?
[1] #7 Foam::functionObjects::Lambda2::calc() at ??:?
[3] #7 Foam::functionObjects::Lambda2::calc() at ??:?
[4] #7 Foam::functionObjects::Lambda2::calc() at ??:?
[2] #7 Foam::functionObjects::Lambda2::calc() at ??:?
[5] #7 Foam::functionObjects::Lambda2::calc() at ??:?
[0] #7 Foam::functionObjects::Lambda2::calc() at ??:?
[1] #8 Foam::functionObjects::fieldExpression::execute() at ??:?
[3] #8 Foam::functionObjects::fieldExpression::execute() at ??:?
[4] #8 Foam::functionObjects::fieldExpression::execute() at ??:?
[2] #8 Foam::functionObjects::fieldExpression::execute() at ??:?
[5] #8 Foam::functionObjects::fieldExpression::execute() at ??:?
[0] #8 Foam::functionObjects::fieldExpression::execute() at ??:?
[1] #9 Foam::functionObjects::timeControl::execute() at ??:?
[2] #9 Foam::functionObjects::timeControl::execute() at ??:?
at ??:?
[3] #9 Foam::functionObjects::timeControl::execute()[4] #9 Foam::functionObjects::timeControl::execute() at ??:?
[5] #9 Foam::functionObjects::timeControl::execute() at ??:?
[0] #9 Foam::functionObjects::timeControl::execute() at ??:?
at ??:?
[2] #10 Foam::functionObjectList::execute()[1] #10 Foam::functionObjectList::execute() at ??:?
at ??:?
[4] #10 Foam::functionObjectList::execute()[3] #10 Foam::functionObjectList::execute() at ??:?
[5] #10 Foam::functionObjectList::execute() at ??:?
[0] #10 Foam::functionObjectList::execute() at ??:?
[2] #11 at ??:?
[3] #11 at ??:?
[4] #11 at ??:?
[1] #11 at ??:?
[5] #11 ????? at ??:?
[0] #11 in /data/OpenFOAM/OpenFOAM-v2112/platforms/linux64GccSPDPInt32Opt/bin/postProcess
[2] #12 in /data/OpenFOAM/OpenFOAM-v2112/platforms/linux64GccSPDPInt32Opt/bin/postProcess
[3] #12 in /data/OpenFOAM/OpenFOAM-v2112/platforms/linux64GccSPDPInt32Opt/bin/postProcess
[1] #12 in /data/OpenFOAM/OpenFOAM-v2112/platforms/linux64GccSPDPInt32Opt/bin/postProcess
[4] #12 ? in /data/OpenFOAM/OpenFOAM-v2112/platforms/linux64GccSPDPInt32Opt/bin/postProcess
[5] #12 ????? in /data/OpenFOAM/OpenFOAM-v2112/platforms/linux64GccSPDPInt32Opt/bin/postProcess
[2] #13 __libc_start_main in /data/OpenFOAM/OpenFOAM-v2112/platforms/linux64GccSPDPInt32Opt/bin/postProcess
[0] #12 in /data/OpenFOAM/OpenFOAM-v2112/platforms/linux64GccSPDPInt32Opt/bin/postProcess
[3] #13 __libc_start_main? in /lib/x86_64-linux-gnu/libc.so.6
[2] #14 in /data/OpenFOAM/OpenFOAM-v2112/platforms/linux64GccSPDPInt32Opt/bin/postProcess
[1] #13 __libc_start_main in /data/OpenFOAM/OpenFOAM-v2112/platforms/linux64GccSPDPInt32Opt/bin/postProcess
[4] #13 __libc_start_main in /data/OpenFOAM/OpenFOAM-v2112/platforms/linux64GccSPDPInt32Opt/bin/postProcess
[5] #13 __libc_start_main in /lib/x86_64-linux-gnu/libc.so.6
[3] #14 ? in /lib/x86_64-linux-gnu/libc.so.6
[1] #14 in /data/OpenFOAM/OpenFOAM-v2112/platforms/linux64GccSPDPInt32Opt/bin/postProcess
[0] #13 __libc_start_main in /lib/x86_64-linux-gnu/libc.so.6
[5] #14 in /lib/x86_64-linux-gnu/libc.so.6
[4] #14 ? in /data/OpenFOAM/OpenFOAM-v2112/platforms/linux64GccSPDPInt32Opt/bin/postProcess
[testing-laptop:12364] *** Process received signal ***
[testing-laptop:12364] Signal: Floating point exception (8)
[testing-laptop:12364] Signal code: (-6)
[testing-laptop:12364] Failing at address: 0x3e80000304c
[testing-laptop:12364] [ 0] /lib/x86_64-linux-gnu/libpthread.so.0(+0x12980)[0x7f8df5ea7980]
[testing-laptop:12364] [ 1] /lib/x86_64-linux-gnu/libpthread.so.0(raise+0xc7)[0x7f8df5ea7817]
[testing-laptop:12364] [ 2] /lib/x86_64-linux-gnu/libpthread.so.0(+0x12980)[0x7f8df5ea7980]
[testing-laptop:12364] [ 3] /data/OpenFOAM/OpenFOAM-v2112/platforms/linux64GccSPDPInt32Opt/lib/libOpenFOAM.so(_ZNK4Foam8cubicEqn5rootsEv+0x15a)[0x7f8df7174dda]
[testing-laptop:12364] [ 4] /data/OpenFOAM/OpenFOAM-v2112/platforms/linux64GccSPDPInt32Opt/lib/libOpenFOAM.so(_ZN4Foam11eigenValuesERKNS_10SymmTensorIfEE+0x148)[0x7f8df702ee88]
[testing-laptop:12364] [ 5] ??/data/OpenFOAM/OpenFOAM-v2112/platforms/linux64GccSPDPInt32Opt/lib/libOpenFOAM.so(_ZN4Foam11eigenValuesERNS_5FieldINS_6VectorIfEEEERKNS_5UListINS_10SymmTensorIfEEEE+0x4f)[0x7f8df75027ff]
[testing-laptop:12364] [ 6] ?/data/OpenFOAM/OpenFOAM-v2112/platforms/linux64GccSPDPInt32Opt/lib/libfieldFunctionObjects.so(_ZN4Foam11eigenValuesINS_12fvPatchFieldENS_7volMeshEEENS_3tmpINS_14GeometricFieldINS_6VectorIfEET_T0_EEEERKNS4_INS_10SymmTensorIfEES7_S8_EE+0x280)[0x7f8dd212e1f0]
[testing-laptop:12364] [ 7] /data/OpenFOAM/OpenFOAM-v2112/platforms/linux64GccSPDPInt32Opt/lib/libfieldFunctionObjects.so(_ZN4Foam15functionObjects7Lambda24calcEv+0x1e1)[0x7f8dd212adf1]
[testing-laptop:12364] [ 8] /data/OpenFOAM/OpenFOAM-v2112/platforms/linux64GccSPDPInt32Opt/lib/libfieldFunctionObjects.so(_ZN4Foam15functionObjects15fieldExpression7executeEv+0xd)[0x7f8dd20e782d]
[testing-laptop:12364] [ 9] /data/OpenFOAM/OpenFOAM-v2112/platforms/linux64GccSPDPInt32Opt/lib/libOpenFOAM.so(_ZN4Foam15functionObjects11timeControl7executeEv+0x54)[0x7f8df723b874]
[testing-laptop:12364] [10] in /lib/x86_64-linux-gnu/libc.so.6
[0] #14 /data/OpenFOAM/OpenFOAM-v2112/platforms/linux64GccSPDPInt32Opt/lib/libOpenFOAM.so(_ZN4Foam18functionObjectList7executeEv+0x1b7)[0x7f8df722e257]
[testing-laptop:12364] [11] postProcess(+0x4de36)[0x55df1c18de36]
[testing-laptop:12364] [12] postProcess(+0x4a5ab)[0x55df1c18a5ab]
[testing-laptop:12364] [13] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xe7)[0x7f8df5ac5bf7]
[testing-laptop:12364] [14] postProcess(+0x4ae9a)[0x55df1c18ae9a]
[testing-laptop:12364] *** End of error message ***
in /data/OpenFOAM/OpenFOAM-v2112/platforms/linux64GccSPDPInt32Opt/bin/postProcess
[testing-laptop:12365] *** Process received signal ***
[testing-laptop:12365] Signal: Floating point exception (8)
[testing-laptop:12365] Signal code: (-6)
[testing-laptop:12365] Failing at address: 0x3e80000304d
[testing-laptop:12365] [ 0] /lib/x86_64-linux-gnu/libpthread.so.0(+0x12980)[0x7fb39d68f980]
[testing-laptop:12365] [ 1] /lib/x86_64-linux-gnu/libpthread.so.0(raise+0xc7)[0x7fb39d68f817]
[testing-laptop:12365] [ 2] /lib/x86_64-linux-gnu/libpthread.so.0(+0x12980)[0x7fb39d68f980]
[testing-laptop:12365] [ 3] /data/OpenFOAM/OpenFOAM-v2112/platforms/linux64GccSPDPInt32Opt/lib/libOpenFOAM.so(_ZNK4Foam8cubicEqn5rootsEv+0x15a)[0x7fb39e95cdda]
[testing-laptop:12365] [ 4] /data/OpenFOAM/OpenFOAM-v2112/platforms/linux64GccSPDPInt32Opt/lib/libOpenFOAM.so(_ZN4Foam11eigenValuesERKNS_10SymmTensorIfEE+0x148)[0x7fb39e816e88]
[testing-laptop:12365] [ 5] /data/OpenFOAM/OpenFOAM-v2112/platforms/linux64GccSPDPInt32Opt/lib/libOpenFOAM.so(_ZN4Foam11eigenValuesERNS_5FieldINS_6VectorIfEEEERKNS_5UListINS_10SymmTensorIfEEEE+0x4f)[0x7fb39ecea7ff]
[testing-laptop:12365] [ 6] /data/OpenFOAM/OpenFOAM-v2112/platforms/linux64GccSPDPInt32Opt/lib/libfieldFunctionObjects.so(_ZN4Foam11eigenValuesINS_12fvPatchFieldENS_7volMeshEEENS_3tmpINS_14GeometricFieldINS_6VectorIfEET_T0_EEEERKNS4_INS_10SymmTensorIfEES7_S8_EE+0x280)[0x7fb3798eb1f0]
[testing-laptop:12365] [ 7] /data/OpenFOAM/OpenFOAM-v2112/platforms/linux64GccSPDPInt32Opt/lib/libfieldFunctionObjects.so(_ZN4Foam15functionObjects7Lambda24calcEv+0x1e1)[0x7fb3798e7df1]
[testing-laptop:12365] [ 8] /data/OpenFOAM/OpenFOAM-v2112/platforms/linux64GccSPDPInt32Opt/lib/libfieldFunctionObjects.so(_ZN4Foam15functionObjects15fieldExpression7executeEv+0xd)[0x7fb3798a482d]
[testing-laptop:12365] [ 9] /data/OpenFOAM/OpenFOAM-v2112/platforms/linux64GccSPDPInt32Opt/lib/libOpenFOAM.so(_ZN4Foam15functionObjects11timeControl7executeEv+0x54)[0x7fb39ea23874]
[testing-laptop:12365] [10] in /data/OpenFOAM/OpenFOAM-v2112/platforms/linux64GccSPDPInt32Opt/bin/postProcess
[testing-laptop:12363] *** Process received signal ***
[testing-laptop:12363] Signal: Floating point exception (8)
[testing-laptop:12363] Signal code: (-6)
[testing-laptop:12363] Failing at address: 0x3e80000304b
[testing-laptop:12363] [ 0] /lib/x86_64-linux-gnu/libpthread.so.0(+0x12980)[0x7f4443ea4980]
[testing-laptop:12363] [ 1] /lib/x86_64-linux-gnu/libpthread.so.0(raise+0xc7)[0x7f4443ea4817]
[testing-laptop:12363] [ 2] in /data/OpenFOAM/OpenFOAM-v2112/platforms/linux64GccSPDPInt32Opt/bin/postProcess
/lib/x86_64-linux-gnu/libpthread.so.0(+0x12980)[0x7f4443ea4980]
[testing-laptop:12363] [ 3] [testing-laptop:12367] *** Process received signal ***
[testing-laptop:12367] Signal: Floating point exception (8)
[testing-laptop:12367] Signal code: (-6)
[testing-laptop:12367] Failing at address: 0x3e80000304f
/data/OpenFOAM/OpenFOAM-v2112/platforms/linux64GccSPDPInt32Opt/lib/libOpenFOAM.so(_ZN4Foam18functionObjectList7executeEv+0x1b7)[0x7fb39ea16257]
[testing-laptop:12365] [testing-laptop:12367] [ 0] /lib/x86_64-linux-gnu/libpthread.so.0(+0x12980)[0x[11] 7f9a11520980]
[testing-laptop:12367] [ 1] /lib/x86_64-linux-gnu/libpthread.so.0(raise+0xc7)[0x7f9a11520817]
[testing-laptop:12367] [ 2] postProcess(+0x4de36)[0x56424aaaae36]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x12980)[0x7f9a11520980]
[testing-laptop:12367] [ 3] [testing-laptop:12365] [12] postProcess(+0x4a5ab)[0x56424aaa75ab]
[testing-laptop:12365] [13] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xe7)[0x7fb39d2adbf7]
[testing-laptop:12365] [14] postProcess(+0x4ae9a)[0x56424aaa7e9a]
[testing-laptop:12365] *** End of error message ***
/data/OpenFOAM/OpenFOAM-v2112/platforms/linux64GccSPDPInt32Opt/lib/libOpenFOAM.so(_ZNK4Foam8cubicEqn5rootsEv+0x15a)[0x7f4445171dda]
[testing-laptop:12363] [ 4] /data/OpenFOAM/OpenFOAM-v2112/platforms/linux64GccSPDPInt32Opt/lib/libOpenFOAM.so(_ZNK4Foam8cubicEqn5rootsEv+0x15a)[0x7f9a127eddda]
[testing-laptop:12367] [ 4] /data/OpenFOAM/OpenFOAM-v2112/platforms/linux64GccSPDPInt32Opt/lib/libOpenFOAM.so(_ZN4Foam11eigenValuesERKNS_10SymmTensorIfEE+0x148)[0x7f444502be88]
[testing-laptop:12363] [ 5] /data/OpenFOAM/OpenFOAM-v2112/platforms/linux64GccSPDPInt32Opt/lib/libOpenFOAM.so(_ZN4Foam11eigenValuesERKNS_10SymmTensorIfEE+0x148)[0x7f9a126a7e88]
[testing-laptop:12367] [ 5] in ?/data/OpenFOAM/OpenFOAM-v2112/platforms/linux64GccSPDPInt32Opt/bin/postProcess
[testing-laptop:12366] *** Process received signal ***
[testing-laptop:12366] Signal: Floating point exception (8)
[testing-laptop:12366] Signal code: (-6)
[testing-laptop:12366] Failing at address: 0x3e80000304e
/data/OpenFOAM/OpenFOAM-v2112/platforms/linux64GccSPDPInt32Opt/lib/libOpenFOAM.so(_ZN4Foam11eigenValuesERNS_5FieldINS_6VectorIfEEEERKNS_5UListINS_10SymmTensorIfEEEE+0x4f)[0x7f44454ff7ff]
[testing-laptop:12363] [ 6] [testing-laptop:12366] [ 0] /lib/x86_64-linux-gnu/libpthread.so.0(+0x12980)[0x7fb8a2900980]
[testing-laptop:12366] [ 1] /lib/x86_64-linux-gnu/libpthread.so.0(raise+0xc7)[0x7fb8a2900817]
[testing-laptop:12366] [ 2] /lib/x86_64-linux-gnu/libpthread.so.0(+0x12980)[0x7fb8a2900980]
[testing-laptop:12366] [ 3] /data/OpenFOAM/OpenFOAM-v2112/platforms/linux64GccSPDPInt32Opt/lib/libOpenFOAM.so(_ZN4Foam11eigenValuesERNS_5FieldINS_6VectorIfEEEERKNS_5UListINS_10SymmTensorIfEEEE+0x4f)[0x7f9a12b7b7ff]
[testing-laptop:12367] [ 6] /data/OpenFOAM/OpenFOAM-v2112/platforms/linux64GccSPDPInt32Opt/lib/libfieldFunctionObjects.so(_ZN4Foam11eigenValuesINS_12fvPatchFieldENS_7volMeshEEENS_3tmpINS_14GeometricFieldINS_6VectorIfEET_T0_EEEERKNS4_INS_10SymmTensorIfEES7_S8_EE+0x280)[0x7f442013f1f0]
[testing-laptop:12363] [ 7] /data/OpenFOAM/OpenFOAM-v2112/platforms/linux64GccSPDPInt32Opt/lib/libfieldFunctionObjects.so(_ZN4Foam11eigenValuesINS_12fvPatchFieldENS_7volMeshEEENS_3tmpINS_14GeometricFieldINS_6VectorIfEET_T0_EEEERKNS4_INS_10SymmTensorIfEES7_S8_EE+0x280)[0x7f99ed70b1f0]
[testing-laptop:12367] [ 7] /data/OpenFOAM/OpenFOAM-v2112/platforms/linux64GccSPDPInt32Opt/lib/libfieldFunctionObjects.so(_ZN4Foam15functionObjects7Lambda24calcEv+0x1e1)[0x7f442013bdf1]
[testing-laptop:12363] [ 8] /data/OpenFOAM/OpenFOAM-v2112/platforms/linux64GccSPDPInt32Opt/lib/libfieldFunctionObjects.so(_ZN4Foam15functionObjects7Lambda24calcEv+0x1e1)[0x7f99ed707df1]
[testing-laptop:12367] [ 8] /data/OpenFOAM/OpenFOAM-v2112/platforms/linux64GccSPDPInt32Opt/lib/libOpenFOAM.so(_ZNK4Foam8cubicEqn5rootsEv+0x15a)[0x7fb8a3bcddda]
[testing-laptop:12366] [ 4] /data/OpenFOAM/OpenFOAM-v2112/platforms/linux64GccSPDPInt32Opt/lib/libfieldFunctionObjects.so(_ZN4Foam15functionObjects15fieldExpression7executeEv+0xd)[0x7f44200f882d]
[testing-laptop:12363] [ 9] /data/OpenFOAM/OpenFOAM-v2112/platforms/linux64GccSPDPInt32Opt/lib/libfieldFunctionObjects.so(_ZN4Foam15functionObjects15fieldExpression7executeEv+0xd)[0x7f99ed6c482d]
[testing-laptop:12367] [ 9] /data/OpenFOAM/OpenFOAM-v2112/platforms/linux64GccSPDPInt32Opt/lib/libOpenFOAM.so(_ZN4Foam11eigenValuesERKNS_10SymmTensorIfEE+0x148)[0x7fb8a3a87e88]
[testing-laptop:12366] [ 5] /data/OpenFOAM/OpenFOAM-v2112/platforms/linux64GccSPDPInt32Opt/lib/libOpenFOAM.so(_ZN4Foam15functionObjects11timeControl7executeEv+0x54)[0x7f4445238874]
[testing-laptop:12363] [10] /data/OpenFOAM/OpenFOAM-v2112/platforms/linux64GccSPDPInt32Opt/lib/libOpenFOAM.so(_ZN4Foam15functionObjects11timeControl7executeEv+0x54)[0x7f9a128b4874]
[testing-laptop:12367] [10] /data/OpenFOAM/OpenFOAM-v2112/platforms/linux64GccSPDPInt32Opt/lib/libOpenFOAM.so(_ZN4Foam11eigenValuesERNS_5FieldINS_6VectorIfEEEERKNS_5UListINS_10SymmTensorIfEEEE+0x4f)[0x7fb8a3f5b7ff]
[testing-laptop:12366] [ 6] /data/OpenFOAM/OpenFOAM-v2112/platforms/linux64GccSPDPInt32Opt/lib/libOpenFOAM.so(_ZN4Foam18functionObjectList7executeEv+0x1b7)[0x7f444522b257]
[testing-laptop:12363] [11] /data/OpenFOAM/OpenFOAM-v2112/platforms/linux64GccSPDPInt32Opt/lib/libOpenFOAM.so(_ZN4Foam18functionObjectList7executeEv+0x1b7)[0x7f9a128a7257]
[testing-laptop:12367] [11] postProcess(+0x4de36)[0x55e50a97be36]
[testing-laptop:12363] [12] postProcess(+0x4de36)[0x55ab5571ce36]
[testing-laptop:12367] [12] postProcess(+0x4a5ab)[0x55e50a9785ab]
[testing-laptop:12363] [13] postProcess(+0x4a5ab)[0x55ab557195ab]
[testing-laptop:12367] [13] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xe7)[0x7f4443ac2bf7]
[testing-laptop:12363] [14] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xe7)[0x7f9a1113ebf7]
[testing-laptop:12367] [14] postProcess(+0x4ae9a)[0x55e50a978e9a]
[testing-laptop:12363] *** End of error message ***
postProcess(+0x4ae9a)[0x55ab55719e9a]
/data/OpenFOAM/OpenFOAM-v2112/platforms/linux64GccSPDPInt32Opt/lib/libfieldFunctionObjects.so(_ZN4Foam11eigenValuesINS_12fvPatchFieldENS_7volMeshEEENS_3tmpINS_14GeometricFieldINS_6VectorIfEET_T0_EEEERKNS4_INS_10SymmTensorIfEES7_S8_EE+0x280)[0x7fb87eb4a1f0]
[testing-laptop:12366] [testing-laptop:12367] *** End of error message ***
[ 7] /data/OpenFOAM/OpenFOAM-v2112/platforms/linux64GccSPDPInt32Opt/lib/libfieldFunctionObjects.so(_ZN4Foam15functionObjects7Lambda24calcEv+0x1e1)[0x7fb87eb46df1]
[testing-laptop:12366] [ 8] /data/OpenFOAM/OpenFOAM-v2112/platforms/linux64GccSPDPInt32Opt/lib/libfieldFunctionObjects.so(_ZN4Foam15functionObjects15fieldExpression7executeEv+0xd)[0x7fb87eb0382d]
[testing-laptop:12366] [ 9] /data/OpenFOAM/OpenFOAM-v2112/platforms/linux64GccSPDPInt32Opt/lib/libOpenFOAM.so(_ZN4Foam15functionObjects11timeControl7executeEv+0x54)[0x7fb8a3c94874]
[testing-laptop:12366] [10] /data/OpenFOAM/OpenFOAM-v2112/platforms/linux64GccSPDPInt32Opt/lib/libOpenFOAM.so(_ZN4Foam18functionObjectList7executeEv+0x1b7)[0x7fb8a3c87257]
[testing-laptop:12366] [11] postProcess(+0x4de36)[0x55652ac94e36]
[testing-laptop:12366] [12] postProcess(+0x4a5ab)[0x55652ac915ab]
[testing-laptop:12366] [13] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xe7)[0x7fb8a251ebf7]
[testing-laptop:12366] [14] postProcess(+0x4ae9a)[0x55652ac91e9a]
[testing-laptop:12366] *** End of error message ***
in /data/OpenFOAM/OpenFOAM-v2112/platforms/linux64GccSPDPInt32Opt/bin/postProcess
[testing-laptop:12362] *** Process received signal ***
[testing-laptop:12362] Signal: Floating point exception (8)
[testing-laptop:12362] Signal code: (-6)
[testing-laptop:12362] Failing at address: 0x3e80000304a
[testing-laptop:12362] [ 0] /lib/x86_64-linux-gnu/libpthread.so.0(+0x12980)[0x7fa49eeef980]
[testing-laptop:12362] [ 1] /lib/x86_64-linux-gnu/libpthread.so.0(raise+0xc7)[0x7fa49eeef817]
[testing-laptop:12362] [ 2] /lib/x86_64-linux-gnu/libpthread.so.0(+0x12980)[0x7fa49eeef980]
[testing-laptop:12362] [ 3] /data/OpenFOAM/OpenFOAM-v2112/platforms/linux64GccSPDPInt32Opt/lib/libOpenFOAM.so(_ZNK4Foam8cubicEqn5rootsEv+0x15a)[0x7fa4a01bcdda]
[testing-laptop:12362] [ 4] /data/OpenFOAM/OpenFOAM-v2112/platforms/linux64GccSPDPInt32Opt/lib/libOpenFOAM.so(_ZN4Foam11eigenValuesERKNS_10SymmTensorIfEE+0x148)[0x7fa4a0076e88]
[testing-laptop:12362] [ 5] /data/OpenFOAM/OpenFOAM-v2112/platforms/linux64GccSPDPInt32Opt/lib/libOpenFOAM.so(_ZN4Foam11eigenValuesERNS_5FieldINS_6VectorIfEEEERKNS_5UListINS_10SymmTensorIfEEEE+0x4f)[0x7fa4a054a7ff]
[testing-laptop:12362] [ 6] /data/OpenFOAM/OpenFOAM-v2112/platforms/linux64GccSPDPInt32Opt/lib/libfieldFunctionObjects.so(_ZN4Foam11eigenValuesINS_12fvPatchFieldENS_7volMeshEEENS_3tmpINS_14GeometricFieldINS_6VectorIfEET_T0_EEEERKNS4_INS_10SymmTensorIfEES7_S8_EE+0x280)[0x7fa47b1811f0]
[testing-laptop:12362] [ 7] /data/OpenFOAM/OpenFOAM-v2112/platforms/linux64GccSPDPInt32Opt/lib/libfieldFunctionObjects.so(_ZN4Foam15functionObjects7Lambda24calcEv+0x1e1)[0x7fa47b17ddf1]
[testing-laptop:12362] [ 8] /data/OpenFOAM/OpenFOAM-v2112/platforms/linux64GccSPDPInt32Opt/lib/libfieldFunctionObjects.so(_ZN4Foam15functionObjects15fieldExpression7executeEv+0xd)[0x7fa47b13a82d]
[testing-laptop:12362] [ 9] /data/OpenFOAM/OpenFOAM-v2112/platforms/linux64GccSPDPInt32Opt/lib/libOpenFOAM.so(_ZN4Foam15functionObjects11timeControl7executeEv+0x54)[0x7fa4a0283874]
[testing-laptop:12362] [10] /data/OpenFOAM/OpenFOAM-v2112/platforms/linux64GccSPDPInt32Opt/lib/libOpenFOAM.so(_ZN4Foam18functionObjectList7executeEv+0x1b7)[0x7fa4a0276257]
[testing-laptop:12362] [11] postProcess(+0x4de36)[0x5609ed302e36]
[testing-laptop:12362] [12] postProcess(+0x4a5ab)[0x5609ed2ff5ab]
[testing-laptop:12362] [13] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xe7)[0x7fa49eb0dbf7]
[testing-laptop:12362] [14] postProcess(+0x4ae9a)[0x5609ed2ffe9a]
[testing-laptop:12362] *** End of error message ***
--------------------------------------------------------------------------
mpirun noticed that process rank 2 with PID 0 on node testing-laptop exited on signal 8 (Floating point exception).
--------------------------------------------------------------------------
```Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1386Lamb vector2020-03-13T13:28:56ZAdminLamb vectorWhen trying to compute the Lamb vector function object as suggested in the guide with:
postProcess -func lambVector
I receive the following error:
Cannot find functionObject file lambVector
Moreover, the tutorial suggested in the gui...When trying to compute the Lamb vector function object as suggested in the guide with:
postProcess -func lambVector
I receive the following error:
Cannot find functionObject file lambVector
Moreover, the tutorial suggested in the guide to test the Lamb vector does not exist in the path:
$FOAM_TUTORIALS/incompressible/pimpleFoam/LES/motorBike
\## Reattaching the author to the issue ticket: @Ricky\-11 ##Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/issues/1373laserDTRM infinite loop2020-03-13T13:31:17ZAdminlaserDTRM infinite loop<!--
*** 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 ...<!--
*** 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 -->
A bug was encountered during the use of laserDTRM model in icoReactingMultiphaseInterFoam. When running in parallel, a particle or particles get stuck in the infinite loop at processor patches. The particle jumps from one CPU to another causing increase in the memory usage up to system overload and crash.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
run icoReactingMultiphaseInterFoam on multiple CPUs with beam crossing multiple processor patches. Time to crash shorter when surface of the absorption/reflection is of complex texture.
### 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
-->
unavailable
### What is the current *bug* behaviour?
<!-- What actually happens -->
simulation hangs during the cloud evolution / particles move. The job maintains CPU load up to the moment of memory overload.
### What is the expected *correct* behavior?
<!-- What you should see instead -->
The tracking of the particles stuck at patches should be abandoned after a few particle transactions between CPUs.
### Relevant logs and/or images
The bug doesn't produce error message - stuck at "moving particles ...." message.
<!--
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 :1812, 1906
- Operating system : ubuntu 18.04 LTS
- Hardware info : 2xEpyc7601, 1TB memory; also tested on Intel Xeon arch.
- 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
-->
Introduce transaction counter.
Issue similar to [3056 bug](https://bugs.openfoam.org/view.php?id=3056 )
solution from attached file works for OF.org:
[0001-particle-Added-logic-to-break-closed-loops.patch](/uploads/4572f30ce474e37c4296df9bdce3267a/0001-particle-Added-logic-to-break-closed-loops.patch)
\#\# Reattaching the author to the issue ticket: @dawid \#\#https://develop.openfoam.com/Development/openfoam/-/issues/1610Layers are not added in pimpleFoam with dynamicMotionSolverTopoFvMesh.2021-07-06T17:07:17ZYogesh BapatLayers are not added in pimpleFoam with dynamicMotionSolverTopoFvMesh.<!--
*** 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 ...<!--
*** 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
<!-- . -->
Addition of layer does not take place with pimpleFoam and dynamicMotionSolverTopoFvMesh.
motionSolver displacementLayeredMotion; is used along with meshModifiers in constant/polyMesh directory
### Steps to reproduce
<!-- -->
The case used is attached along with the issue. The case can be run using pimpleFoam solver. Animation of mesh motion is also provided. The top boundary moves as per motion provided but layer is not added even though layer height grows.
### 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?
<!-- -->
No layers are added.
### What is the expected *correct* behavior?
<!---->
Layer addition as per inputs in constant/polyMesh/meshModifier ![animation](/uploads/1f1a07d851820acbfdd3dcb4af9ced85/animation.gif)[tank.tar.gz](/uploads/3e0af8941253e82cf532ab2e3464fa16/tank.tar.gz)
### 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 :OF1906
- Operating system :CenOS
- 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/3089leak and failed update of interpolated fields in singleCellMesh (application)2024-01-19T16:19:30ZMark OLESENleak and failed update of interpolated fields in singleCellMesh (application)The interpolated fields are stored onto the single-cell mesh for writing. However, the old stored ones (from a previous time step) are still there, which means that the store fails - resulting in memory leakage and the fields written are...The interpolated fields are stored onto the single-cell mesh for writing. However, the old stored ones (from a previous time step) are still there, which means that the store fails - resulting in memory leakage and the fields written are not the updated ones.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2760LESRegion computed wrongly when using kOmegaSSTIDDES turbulence model2023-10-17T15:06:11ZWojciech SadowskiLESRegion computed wrongly when using kOmegaSSTIDDES turbulence model### Functionality to add/problem to solve
The `LESRegion()` function in the `kOmegaSSTIDDES` turbulence model is not implemented.
Instead the implementation from the base class `kOmegaSSTDES` is used:
```cpp
template<class BasicTurbulen...### Functionality to add/problem to solve
The `LESRegion()` function in the `kOmegaSSTIDDES` turbulence model is not implemented.
Instead the implementation from the base class `kOmegaSSTDES` is used:
```cpp
template<class BasicTurbulenceModel>
tmp<volScalarField> kOmegaSSTDES<BasicTurbulenceModel>::LESRegion() const
{
const volScalarField& k = this->k_;
const volScalarField& omega = this->omega_;
const volVectorField& U = this->U_;
const volScalarField CDkOmega
(
(2*this->alphaOmega2_)*(fvc::grad(k) & fvc::grad(omega))/omega
);
const volScalarField F1(this->F1(CDkOmega));
return tmp<volScalarField>::New
(
IOobject::scopedName("DES", "LESRegion"),
neg(dTilda(mag(fvc::grad(U)), CDES(F1)) - lengthScaleRAS())
);
}
```
leading to LES region indicator computed with
different equation than the one actually used in the model:
```cpp
template<class BasicTurbulenceModel>
tmp<volScalarField> kOmegaSSTIDDES<BasicTurbulenceModel>::dTilda
(
const volScalarField& magGradU,
const volScalarField& CDES
) const
{
const volScalarField lRAS(this->lengthScaleRAS());
const volScalarField lLES(this->lengthScaleLES(CDES));
const volScalarField alpha(this->alpha());
const volScalarField expTerm(exp(sqr(alpha)));
tmp<volScalarField> fB = min(2*pow(expTerm, -9.0), scalar(1));
const volScalarField fdTilda(max(1 - fdt(magGradU), fB));
if (fe_)
{
/*
...
*/
}
// Simplified formulation from Gritskevich et al. paper (2011) where fe = 0
return max
(
fdTilda*lRAS + (1 - fdTilda)*lLES,
dimensionedScalar(dimLength, SMALL)
);
}
```
While writing this issue, I became aware that outputting `fd` is also possible now, as of v2212.
It seems that for IDDES model it is actually equivalent to the way `fdTilda` is computed in the code,
and `1-fdTilda` multiplies the LES length scale in both versions of blending, so it serves the same purpose (as far as I understand it).
Perhaps one option to resolve this would be implementing a virtual `LESRegion()` that throws `FatalError` telling the user to
output `fd` instead and subtract it from 1?
### Target audience
Target audience are the users of hybrid RANS/LES turbulence models.
Proper indication in which region the model works in a LES mode is important for
debugging and setting up cases with those models properly.
### Proposal
I have made a quick solution for myself in an out-of-repository copy of kOmegaSSTIDDES.
1. Added a protected member function, to refactor computation of `fdTilda`.
Header:
```cpp
//- Return the fdTilda function (moved to a function for
// LESRegions function)
tmp<volScalarField> fdTilda
(
const volScalarField &magGradU,
const volScalarField &expTerm
) const;
```
Implementation:
```cpp
template <class BasicTurbulenceModel>
tmp<volScalarField> kOmegaSSTIDDES<BasicTurbulenceModel>::fdTilda
(
const volScalarField &magGradU,
const volScalarField &expTerm
) const
{
tmp<volScalarField> fB = min(2 * pow(expTerm, -9.0), scalar(1));
return max(1 - fdt(magGradU), fB);
}
```
2. Added the `LESRegion()`:
Header:
```cpp
//- Return the LES field indicator
virtual tmp<volScalarField> LESRegion() const;
```
Implementation:
```cpp
template <class BasicTurbulenceModel>
tmp<volScalarField> kOmegaSSTIDDES<BasicTurbulenceModel>::LESRegion() const
{
const volScalarField magGradU(mag(fvc::grad(this->U_)));
const volScalarField expTerm(exp(sqr(this->alpha())));
tmp<volScalarField> tLESRegion
(
new volScalarField
(
IOobject::scopedName("IDDES", "LESRegion"),
1 - this->fdTilda(magGradU, expTerm)
)
);
// Solver is in RANS mode next to the wall.
// i have no clue if this can cause problems
tLESRegion.ref().boundaryFieldRef() == 0.0;
return tLESRegion;
}
```
### What does success look like, and how can we measure that?
The LES region computed with unchanged code from a sample test case:
![obraz](/uploads/a22e4dfdec687fb767946f36a9d49de9/obraz.png)
The LES region computed with the code above, using `fdTilda` as it is computed in `dTilda` function:
![obraz](/uploads/38fd2950b035e2469c5353acd245a400/obraz.png)
### Links / references
Reference from KOmegaSSTIDDES model:
Gritskevich, M.S., Garbaruk, A.V., Schuetze, J., Menter, F.R. (2011)
Development of DDES and IDDES Formulations for the k-omega
Shear Stress Transport Model, Flow, Turbulence and Combustion,
pp. 1-19Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1754LES without any SGS model2020-06-30T05:44:57ZSeo Dong-HoLES without any SGS modelHi
I'd like to do a large eddy simulation **without any SGS model** to compare with the results with it.
How can I set up "turbuleceProperties", etc. on OpenFOAM?
Thank you.Hi
I'd like to do a large eddy simulation **without any SGS model** to compare with the results with it.
How can I set up "turbuleceProperties", etc. on OpenFOAM?
Thank you.https://develop.openfoam.com/Development/openfoam/-/issues/2255LH2 boiling: EP16972022-03-30T11:03:59ZPawan GhildiyalLH2 boiling: EP1697This model is not committed to "feature-sub-cooling-ext"
i) **CHFSubCoolModels **
type Tatsumoto;
ii)For nucleate boiling : Eq [8] and Eq [10]. (Kutadeladze and exponential respectively)
exponential model is not there...This model is not committed to "feature-sub-cooling-ext"
i) **CHFSubCoolModels **
type Tatsumoto;
ii)For nucleate boiling : Eq [8] and Eq [10]. (Kutadeladze and exponential respectively)
exponential model is not there in this branch.Sergio FerrarisSergio Ferrarishttps://develop.openfoam.com/Development/openfoam/-/issues/843libFieldFunctionObjects writeInterval2018-06-01T13:04:49ZAdminlibFieldFunctionObjects writeIntervalIn the v1712 release the following libFieldFunctionObjects
dummy
{
type wallShearStress;
libs ("libfieldFunctionObjects.so")
writeControl timeStep;
writeInterval 1e+06;
writeFiel...In the v1712 release the following libFieldFunctionObjects
dummy
{
type wallShearStress;
libs ("libfieldFunctionObjects.so")
writeControl timeStep;
writeInterval 1e+06;
writeFields no;
patches ("board.*");
log no;
}
writes the wallShearStress field in the case directory every time step. The same controlDict sintax worked fine for the same case with the 2.4.0 version, with the field object written every specified write interval (using outputInterval in the old version).https://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/401Limitation: sampling FO not working with ACMI2018-05-29T05:39:49ZPrashant SonakarLimitation: sampling FO not working with ACMIAttached case replicating the behavior [oscillatingInletACMI2D.tgz](/uploads/f53bda75257196fd3688e1b7d863e71c/oscillatingInletACMI2D.tgz)
@Mattijs @mark
(Ref EP#333)Attached case replicating the behavior [oscillatingInletACMI2D.tgz](/uploads/f53bda75257196fd3688e1b7d863e71c/oscillatingInletACMI2D.tgz)
@Mattijs @mark
(Ref EP#333)AdminAdminhttps://develop.openfoam.com/Development/openfoam/-/issues/941Limit on warnings during snapping stage2019-12-09T22:37:28ZRoger AlmenarLimit on warnings during snapping stageI am runnign a sHM case, which has ended up in a log file (snappyHexMesh step) of beyond 2Gb size, due to warnings during the snapping stage, like this:
```
Did not find surface near face centre (0.0843533 0.0788768 0.0969448)
--> FO...I am runnign a sHM case, which has ended up in a log file (snappyHexMesh step) of beyond 2Gb size, due to warnings during the snapping stage, like this:
```
Did not find surface near face centre (0.0843533 0.0788768 0.0969448)
--> FOAM Warning :
From function void Foam::snappySnapDriver::calcNearestFace(Foam::label, cons
t indirectPrimitivePatch&, const scalarField&, Foam::vectorField&, Foam::vectorF
ield&, Foam::labelList&) const
in file snappyHexMeshDriver/snappySnapDriverFeature.C at line 331
```
Is it possible to limit the number of warning outputs?v1812Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/1564limitTemperature functionObject does not work with compressibleInterFoam2020-06-19T07:07:20ZPawan GhildiyallimitTemperature functionObject does not work with compressibleInterFoam<!--
*** Please read this first! ***
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
limitTemperature functionObject does not work with compressibleInterFoam
### S...<!--
*** Please read this first! ***
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
limitTemperature functionObject does not work with compressibleInterFoam
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
### Example case
<!--
If possible, please create a SMALL example and attach it to your report
If you are using an older version of OpenFOAM this will also determine
whether the bug has been fixed in a more recent version
-->
### What is the current *bug* behaviour?
<!-- What actually happens -->
### What is the expected *correct* behavior?
<!-- What you should see instead -->
### Relevant logs and/or images
<!--
Paste any relevant logs - please use code blocks (```) to format console
output, logs, and code as it's very hard to read otherwise.
-->
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : 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 and dev
- 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
-->