overPimpleDyMFoam with kOmegaSST segmentation faults in v2406

Summary

kOmegaSST models (and maybe any turbulence model that requires wall-distance) when run with oversetPimpleDyMFoam falls over with a segmentation fault in v2406, despite running OK in v2312. There appears to be some issue with the wall-distance calculation.

Steps to reproduce

Convert the overPimpleDyMFoam/cylinder tutorial to use the kOmegaSST TM and run in v2406.

Example case

Please find case as described attached.

What is the current bug behaviour?

Running with full-debug, reveals it is attempting to access an element in a zero-size list.

What is the expected correct behavior?

No error!

Relevant logs and/or images

On the first full time-step in the example case, the following is output:

Time = 0.005

DICPCG:  Solving for cellDisplacementx, Initial residual = 0, Final residual = 0, No Iterations 0
DICPCG:  Solving for cellDisplacementz, Initial residual = 1, Final residual = 9.83456e-07, No Iterations 25
inverseDistance : detected 2 mesh regions
    zone:0 nCells:7200  voxels:(89 1 89) bb:(-5.00002 -0.0500161 -4.00002) (9.00002 0.0500161 4.0
0002)
    zone:1 nCells:750  voxels:(89 1 89) bb:(-1.19895 -0.0500034 -1.18974) (1.2 0.0500034 1.20974)
Overset analysis : nCells : 7950
    calculated   : 7769
    interpolated : 106 (from local:106  mixed local/remote:0  remote:0)
    hole         : 75



--> FOAM FATAL ERROR: (openfoam-2406)
attempt to access element 0 from zero sized list

    From void Foam::UList<T>::checkIndex(Foam::label) const [with T = int; Foam::label = int]
    in file /home/dludlow/OpenFOAM/OpenFOAM-v2406/src/OpenFOAM/lnInclude/UListI.H at line 200.

FOAM aborting

[stack trace]
=============
#1  Foam::error::simpleExit(int, bool) at ~/OpenFOAM/OpenFOAM-v2406/src/OpenFOAM/lnInclude/error.C:313
#2  Foam::error::exiting(int, bool) at ~/OpenFOAM/OpenFOAM-v2406/src/OpenFOAM/lnInclude/error.C:271
#3  Foam::error::abort() at ~/OpenFOAM/OpenFOAM-v2406/src/OpenFOAM/lnInclude/error.C:375
#4  Foam::Ostream& Foam::operator<< <Foam::error>(Foam::Ostream&, Foam::errorManip<Foam::error>) at ~/OpenFOAM/OpenFOAM-v2406A/src/OpenFOAM/lnInclude/errorManip.H:93 (discriminator 4)
#5  Foam::UList<int>::checkIndex(int) const at ~/OpenFOAM/OpenFOAM-v2406/src/OpenFOAM/lnInclude/UListI.H:202
#6  Foam::UList<int>::operator[](int) const at ~/OpenFOAM/OpenFOAM-v2406/src/OpenFOAM/lnInclude/UListI.H:384
#7  void Foam::oversetFvMeshBase::addInterpolation<double>(Foam::fvMatrix<double>&, Foam::Field<double> const&, bool, double const&) const at ~/OpenFOAM/OpenFOAM-v2406/src/overset/lnInclude/oversetFvMeshBaseTemplates.C:520
#8  Foam::oversetFvPatchField<double>::manipulateMatrix(Foam::fvMatrix<double>&) at ~/OpenFOAM/OpenFOAM-v2406/src/overset/oversetPolyPatch/oversetFvPatchField.C:812
#9  Foam::fvMatrix<double>::boundaryManipulate(Foam::GeometricBoundaryField<double, Foam::fvPatchField, Foam::volMesh>&) at ~/OpenFOAM/OpenFOAM-v2406/src/finiteVolume/lnInclude/fvMatrix.C:1273 (discriminator 2)
#10  Foam::SolverPerformance<double> Foam::oversetFvMeshBase::solveOverset<double>(Foam::fvMatrix<double>&, Foam::dictionary const&) const at ~/OpenFOAM/OpenFOAM-v2406/src/overset/lnInclude/oversetFvMeshBaseTemplates.C:809
#11  Foam::dynamicOversetFvMesh::solve(Foam::fvMatrix<double>&, Foam::dictionary const&) const at ~/OpenFOAM/OpenFOAM-v2406A/src/overset/oversetFvMesh/dynamicOversetFvMesh/dynamicOversetFvMesh.H:169
#12  Foam::fvMatrix<double>::solve(Foam::dictionary const&) at ~/OpenFOAM/OpenFOAM-v2406/src/finiteVolume/lnInclude/fvMatrixSolve.C:331
#13  Foam::fvMatrix<double>::solve() at ~/OpenFOAM/OpenFOAM-v2406/src/finiteVolume/lnInclude/fvMatrixSolve.C:360
#14  Foam::patchDistMethods::advectionDiffusion::correct(Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh>&, Foam::GeometricField<Foam::Vector<double>, Foam::fvPatchField, Foam::volMesh>&) at ~/OpenFOAM/OpenFOAM-v2406/src/finiteVolume/fvMesh/wallDist/patchDistMethods/advectionDiffusion/advectionDiffusionPatchDistMethod.C:199 (discriminator 1)
#15  Foam::patchDistMethods::advectionDiffusion::correct(Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh>&) at ~/OpenFOAM/OpenFOAM-v2406/src/finiteVolume/fvMesh/wallDist/patchDistMethods/advectionDiffusion/advectionDiffusionPatchDistMethod.C:91
#16  Foam::wallDist::movePoints() at ~/OpenFOAM/OpenFOAM-v2406/src/finiteVolume/fvMesh/wallDist/wallDist/wallDist.C:216
#17  void Foam::meshObject::movePoints<Foam::fvMesh>(Foam::objectRegistry&) at ~/OpenFOAM/OpenFOAM-v2406/src/OpenFOAM/lnInclude/MeshObject.C:260
#18  Foam::fvMesh::movePoints(Foam::Field<Foam::Vector<double> > const&) at ~/OpenFOAM/OpenFOAM-v2406/src/finiteVolume/fvMesh/fvMesh.C:998
#19  Foam::dynamicMotionSolverListFvMesh::update() at ~/OpenFOAM/OpenFOAM-v2406/src/dynamicFvMesh/dynamicMotionSolverListFvMesh/dynamicMotionSolverListFvMesh.C:183 (discriminator 6)
#20  Foam::dynamicOversetFvMesh::update() at ~/OpenFOAM/OpenFOAM-v2406/src/overset/oversetFvMesh/dynamicOversetFvMesh/dynamicOversetFvMesh.C:63
#21  ? at ~/OpenFOAM/OpenFOAM-v2406/applications/solvers/incompressible/pimpleFoam/overPimpleDyMFoam/overPimpleDyMFoam.C:100
#22  ? in /lib64/libc.so.6
#23  __libc_start_main in /lib64/libc.so.6
#24  ? in ~/OpenFOAM/OpenFOAM-v2406/platforms/linux64Gcc85DPInt32Debug/bin/overPimpleDyMFoam
=============

In v2312, the iteration completes the yWall solve before the inverse-distance calculation (see LOG below). Note that in v2406 there is no yWall solve at this time-step before the inverseDistance calculation.

Time = 0.005

DICPCG:  Solving for cellDisplacementx, Initial residual = 0, Final residual = 0, No Iterations 0
DICPCG:  Solving for cellDisplacementz, Initial residual = 1, Final residual = 9.83456e-07, No Iterations 25
DILUPBiCGStab:  Solving for yWall, Initial residual = 0.000314587, Final residual = 3.1983e-05, No Iterations 16
inverseDistance : detected 2 mesh regions
    zone:0 nCells:7200  voxels:(89 1 89) bb:(-5.00002 -0.0500161 -4.00002) (9.00002 0.0500161 4.00002)
    zone:1 nCells:750  voxels:(89 1 89) bb:(-1.19895 -0.0500034 -1.18974) (1.2 0.0500034 1.20974)
Overset analysis : nCells : 7950
    calculated   : 7769
    interpolated : 106 (from local:106  mixed local/remote:0  remote:0)
    hole         : 75

PIMPLE: iteration 1
DILUPBiCGStab:  Solving for p, Initial residual = 1, Final residual = 8.3394e-07, No Iterations 113
time step continuity errors : sum local = 9.63552e-10, global = 9.45475e-10, cumulative = 9.45475e-10
DILUPBiCGStab:  Solving for p, Initial residual = 0.020414, Final residual = 9.4636e-07, No Iterations 92
time step continuity errors : sum local = 2.90706e-08, global = -1.88234e-09, cumulative = -9.36862e-10
smoothSolver:  Solving for omega, Initial residual = 0.028511, Final residual = 5.59543e-07, No Iterations 7
smoothSolver:  Solving for k, Initial residual = 1, Final residual = 2.01972e-07, No Iterations 7
ExecutionTime = 0.47 s  ClockTime = 0 s

Environment information

• OpenFOAM version : v2406
• Operating system : Centos/Rocky
• Hardware info :
• Compiler : gcc

Possible fixes

The line of code where the error occurs is:

~/OpenFOAM/OpenFOAM-v2406/src/overset/lnInclude/oversetFvMeshBaseTemplates.C:520

and suggests the "stencilPatches_" class member isn't allocated correctly at the time of access. This list needs to be allocated correctly before-hand.

cylinderkOmegaSST2406.gz

Does it work with any of the other wall distance methods?

Hi Mattijs,

In v2406 the case runs with the exactDistance and meshWave methods but fails with advectionDiffusion/Poisson methods.

It is an update problem:

• in v2312 the order of updating meshObjects (mesh singletons) is

    Moving wallDist
    Moving cellCellStencilObject

so the wallDistance overset connectivity (cellCellStencilObject) is still from the previous time step. In v2406 the cellCellStencilObject is redone first (as it should be) but the corresponding matrix addressing (lduAddressing, lives on the lduMesh) has not been updated yet.

mentioned in commit f72670ed

Could you test if this

• solves your problem
• does not slow down any steady cases with overset?

Apologies for a slow response, I've been away. To answer your questions:

• The patch does seem to solve the problem - my two test cases now run.
• In the single steady overset case I've run (v2406 before and after patch) I've seen no evidence to suggest that there is any slow-down.

Thanks for the fix. BTW since using v2312 I had found it desirable to set checkAndWriteMesh to false in the dictionary!

@andy : in advectionDiffusionPatchDistMethod.C why default true on

checkAndWriteMesh_(coeffs_.getOrDefault("checkAndWriteMesh", true))

no - @vaggelisp ?

In shape optimisation loops, if the mesh gets invalid after a shape update, the solution of the advectionDiffusion equation may diverge bad enough to get a segmentation fault, without having a chance to write the mesh and analyze the problematic areas.

Since I was under the impression that advectionDiffusion is mainly used in optimisation loops, I chose to default this bool to true, so that we always get some kind of feedback when things fail with the mesh update. If this causes issues with other uses of advectionDiffusion, we can default it to false and will have to manually switch to true in optimization runs.

mentioned in commit 050f2791

We've changed the default to false. Maybe the mesh checking code could be moved (a bit closer) to the mesh motion - it might be useful in general to check for mesh motion.

mentioned in commit cce6f886

added community label

closed via merge request !722 (merged)

mentioned in commit 45e7c4a0