Parallel Crash:: Mesquite 2.3.0 / OpenFoam 2.2.x

[richpaj]

Hi Sandeep,

for a 2D case I find that Mesquite 2.3.0 / OpenFoam 2.2.x crashes with the following error:

[1] --> FOAM FATAL IO ERROR: [1] inconsistent patch and patchField types for patch type empty and patchField type fixedValue [1] [1] file: IStringStream.sourceFile.volVectorField.cellCentres.boundaryField.back from line 62 to line 64. [1] [1] From function fvPatchField::New(const fvPatch&, const DimensionedField<Type, volMesh>&, const dictionary&) [1] in file /home1/geac/ueac0002/OpenFOAM/OpenFOAM-2.2.x/src/finiteVolume/lnInclude/fvPatchFieldNew.C at line 165.

Tracking back through the code I believe the above is related to the patch type settings (topoMapper.C) in

cellCentresPtr_ =
(
    new volVectorField
    (
        IOobject
        (
            "cellCentres",
            mesh_.time().timeName(),
            mesh_,
            IOobject::NO_READ,
            IOobject::NO_WRITE,
            true
        ),
        mesh_,
        dimLength,
        SubField<vector>(Cv, mesh_.nCells()),
        volCentrePatches
    )
);

I should imagine any simple 2D case will reproduce the above error, alternatively I can supply one if you need. But perhaps there's already a workaround?

Many thanks if you have any resolution

Regards,

Richard K.

[richpaj]

P.S. I omitted to add that the mesquite/OF inteface is based on "dynamicTopoFvMesh-Port-2.2.x"

[richpaj]

PPS. Furthermore, there are no issues with 'serial' mode.

[smenon]

It looks like 'volCentrePatches' is uniformly defined as 'fixedValue', which doesn't necessarily hold in 2D. Perhaps you could additionally check for "empty" types in the patch loop prior to the statement, create an empty type instead of fixedValue, and see if that works? I agree that a more general solution is probably necessary.

[richpaj]

Thanks for that, yes I was thinking along similar lines but suspected you might have a more elegant solution. I'm actually surprised this issue hasn't cropped up before.

If memory serves me correct (!), this error doesn't occur with "wedge" type bcs.

Anyways, many thanks, I'll experiment.

Regards,

Richard K. On 10 Mar 2014, at 23:09, Sandeep Menon wrote:

It looks like 'volCentrePatches' is uniformly defined as 'fixedValue', which doesn't necessarily hold in 2D. Perhaps you could additionally check for "empty" types in the patch loop prior to the statement, create an empty type instead of fixedValue, and see if that works? I agree that a more general solution is probably necessary.

— Reply to this email directly or view it on GitHub.

[smenon]

Fixed by commit: 51a7076690d411ef2f6d7955e0f544a57284e458 on branch Port-2.3.x

[robertsawko]

Hi,

just came across the same issue and indeed commit 51a7076 fixes the error mentioned above. However, on the next time step the program segfaults. I have usePointDisplacement in my dynamicMeshDict so maybe it's a problem with mapping.

[1] #0  Foam::error::printStack(Foam::Ostream&)[0] #0  Foam::error::printStack(Foam::Ostream&)[2] #0  Foam::error::printStack(Foam::Ostream&)[3] #0  Foam::error::printStack(Foam::Ostream&) at ??:?
[2] #1  Foam::sigSegv::sigHandler(int) at ??:?
[1] #1  Foam::sigSegv::sigHandler(int) at ??:?
[0] #1  Foam::sigSegv::sigHandler(int) at ??:?
[3] #1  Foam::sigSegv::sigHandler(int) at ??:?
[2] #2   at ??:?
[1] #2   at ??:?
[0] #2   at ??:?
[3] #2   in "/usr/lib/libc.so.6"
[1] #3  Uninterpreted:
[soli31888c:10458] *** Process received signal ***
[soli31888c:10458] Signal: Segmentation fault (11)
[soli31888c:10458] Signal code:  (-6)
[soli31888c:10458] Failing at address: 0x3e8000028da
[soli31888c:10458] [ 0] /usr/lib/libc.so.6(+0x33df0) [0x7f9f10851df0]
[soli31888c:10458] [ 1] /usr/lib/libc.so.6(gsignal+0x37) [0x7f9f10851d67]
[soli31888c:10458] [ 2] /usr/lib/libc.so.6(+0x33df0) [0x7f9f10851df0]
[soli31888c:10458] [ 3] [0x7fffc720ee80]
[soli31888c:10458] *** End of error message ***
 in "/usr/lib/libc.so.6"
[2] #3  Foam::valuePointPatchField<Foam::Vector<double> >::evaluate(Foam::UPstream::commsTypes) in "/usr/lib/libc.so.6"
[3] #3  Foam::valuePointPatchField<Foam::Vector<double> >::evaluate(Foam::UPstream::commsTypes)--------------------------------------------------------------------------
mpirun noticed that process rank 1 with PID 10458 on node soli31888c exited on signal 11 (Segmentation fault).
--------------------------------------------------------------------------

Can I ask for this issue to be reopened? Here's the case which is causing problems.

[robertsawko]

Hello Sandeep,

I came back to this project and started slowly debugging this issue. For now the only thing I established is something we probably new already that is the gfault is caused by boundaryConditions_().correctBoundaryConditions(); in mesquiteMotionSolver.C. Is this properly handled in parallel? Maybe the code is creating boundaryConditions_ field for every processor. It looks a bit dodgy as creating these point fields at runtime jumps over the decomposition step which the mesh and other fields undergo. Shouldn't be this created by master process only? Let me know what you think.

This maybe a completely separate issue from the one with which this thread started so let me know if you want me to create a separate bug report.

[robertsawko]

Sorry for bumbping this thread a bit, but today I realised that I accidentally ommitted the initial part of the error message.

[0] 
[0] 
[0] --> FOAM FATAL ERROR: 
[0] given patch field does not correspond to the meshPoints. Field size: 0 meshPoints size: -617601584
[0] 
[0]     From function void pointPatchField<Type>::setInInternalField(Field<Type1>& iF, const Field<Type1>& iF) const
[0]     in file /home/c111269/OpenFOAM/OpenFOAM-2.3.x/src/OpenFOAM/lnInclude/pointPatchField.C at line 297.
[0] 
FOAM parallel run aborting
[0] 
[3] #0  Foam::error::printStack(Foam::Ostream&)[0] #0 Foam::error::printStack(Foam::Ostream&)[1] [2] #0  #0 Foam::error::printStack(Foam::Ostream&)Foam::error::printStack(Foam::Ostream&) at ??:?

This appears after running pimpleDyMFoam with a parallel switch. Let me know if you have an idea how to debug this.

[smenon]

Sorry for the late reply. I was away on vacation in July.

It's a bit concerning that the meshPoints size is inconsistent with the field. There must be a missing callback somewhere that needs to be investigated. I'll take a closer look sometime soon and let you know if I find something.

[smenon]

Fixed by commit: e2858a6271d2fdfa6e1647835f81ed24e78c1642 on branch Port-2.3.x