[DarioP]

I am facing the infamous error with rhoPimpleFoam.
The mesh looks good and passes every check.
Meshing and running on a single thread made no difference.
I have crosschecked the BCs with another working case but I have not been able to spot what is triggering the division by zero. Maybe that will be obvious to a fresh set of eyes...

Here is the relevant output of rhoPimpleFoam

Creating turbulence model

Selecting turbulence model type RAS
Selecting RAS turbulence model kOmegaSST
Selecting patchDistMethod meshWave
RAS
{
    RASModel        kOmegaSST;
    turbulence      on;
    printCoeffs     on;
    alphaK1         0.85;
    alphaK2         1;
    alphaOmega1     0.5;
    alphaOmega2     0.856;
    gamma1          0.555556;
    gamma2          0.44;
    beta1           0.075;
    beta2           0.0828;
    betaStar        0.09;
    a1              0.31;
    b1              1;
    c1              10;
    F3              false;
    decayControl    false;
    kInf            0;
    omegaInf        0;
}

Creating field dpdt for moving meshes

Creating field kinetic energy K

No MRF models present

No finite volume options present
Constructing face momentum rhoUf
#0  Foam::error::printStack(Foam::Ostream&) at ??:?
#1  Foam::sigFpe::sigHandler(int) at ??:?
#2  ? in /usr/lib/libpthread.so.0
#3  Foam::divide(Foam::Field<double>&, Foam::UList<double> const&, Foam::UList<double> const&) at ??:?
#4  void Foam::divide<Foam::fvPatchField, Foam::volMesh>(Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh>&, Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh> const&, Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh> const&) in /opt/OpenFOAM/OpenFOAM-v2012/platforms/linux64GccDPInt32Opt/bin/rhoPimpleFoam
#5  Foam::tmp<Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh> > Foam::operator/<Foam::fvPatchField, Foam::volMesh>(Foam::tmp<Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh> > const&, Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh> const&) at ??:?
#6  Foam::kOmegaSSTBase<Foam::eddyViscosity<Foam::RASModel<Foam::EddyDiffusivity<Foam::ThermalDiffusivity<Foam::CompressibleTurbulenceModel<Foam::fluidThermo> > > > > >::F2() const at ??:?
#7  Foam::kOmegaSSTBase<Foam::eddyViscosity<Foam::RASModel<Foam::EddyDiffusivity<Foam::ThermalDiffusivity<Foam::CompressibleTurbulenceModel<Foam::fluidThermo> > > > > >::F23() const at ??:?
#8  Foam::kOmegaSSTBase<Foam::eddyViscosity<Foam::RASModel<Foam::EddyDiffusivity<Foam::ThermalDiffusivity<Foam::CompressibleTurbulenceModel<Foam::fluidThermo> > > > > >::correctNut(Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh> const&) at ??:?
#9  Foam::RASModels::kOmegaSST<Foam::EddyDiffusivity<Foam::ThermalDiffusivity<Foam::CompressibleTurbulenceModel<Foam::fluidThermo> > > >::correctNut() at ??:?
#10  ? in /opt/OpenFOAM/OpenFOAM-v2012/platforms/linux64GccDPInt32Opt/bin/rhoPimpleFoam
#11  __libc_start_main in /usr/lib/libc.so.6
#12  ? in /opt/OpenFOAM/OpenFOAM-v2012/platforms/linux64GccDPInt32Opt/bin/rhoPimpleFoam
[1]    198975 floating point exception (core dumped)  rhoPimpleFoam

It seems to be coming from one of these lines in src/TurbulenceModels/turbulenceModels/Base/kOmegaSST/kOmegaSSTBase.C

            (scalar(2)/betaStar_)*sqrt(k_)/(omega_*y_),
            scalar(500)*(this->mu()/this->rho_)/(sqr(y_)*omega_)

yet I have not found the solution.

Thanks

[DarioP]

It seems to be a mesh problem.

I am working on a 3D model of an impeller, therefore I have mostly cylindrical symmetry. I used a blockMeshDict found online (and attached below) to produce the base mesh as in the attached picture, with the idea of simplifying the job of SHM.

The resulting mesh looks good and passes all the tests of checkMesh, but the solver does not seem to like it, maybe because of the contained AMI. I changed blockMeshDict to produce a standard box mesh and now the solver is crunching numbers.

[DarioP]

The meshing was definitely the issue, but not in the way described above, as I got the solver floating point exception again with the box base mesh as I increased the number of cells in blockMeshDict.
I noticed these kind of warnings from SHM:

--> FOAM Warning : 
    From void Foam::snappySnapDriver::calcNearestFace(Foam::label, const indirectPrimitivePatch&, const scalarField&, Foam::vectorField&, Foam::vectorField&, Foam::labelList&) const
    in file snappyHexMeshDriver/snappySnapDriverFeature.C at line 345
    Did not find surface near face centre (X Y Z)

which I corrected by increasing the tolerance under snapControls.
For the time being (fingers crossed) the solver seems to be happy also with the cylindrical mesh.