[ma-tri-x]

Hi!


Since long I try to make AMR (adaptive mesh refinement) work with my two-phase, compressible bubble.


When I try the depthCharge3D tutorial with the compressibleInterFoam, it works with any OpenFOAM or Foam-Extend-version.


However, when I try depthCharge3D with compressibleInterDyMFoam (foam-extend-4.0 as well as foam-extend-4.1), it fails with floating point error either when setting up the UEqn or when solving the pEqn with a reduced UEqn.
My dynamicMeshDict looks as follows:

dynamicFvMesh   dynamicRefineFvMesh;
dynamicRefineFvMeshCoeffs
{
    refineInterval  1;
    field           alpha1;
    lowerRefineLevel .001;
    upperRefineLevel .999;
    unrefineLevel   10;
    nBufferLayers   1;
    maxRefinement   1;
    maxCells        140000;
    correctFluxes
    (
        (phi U)
        (nHatf none) //thought might be necessary?
        (rhoPhi none) //thought might be necessary?
        (alpha1 none) //thought might be necessary?
    );
    dumpLevel       true;
}

if I unset the necessity to refine by setting

    lowerRefineLevel 1.001;
    upperRefineLevel 1.999;

The code runs fine.



Actually, the 2D code from Luca Cornolti #750894

2D adaptive Mesh Refinement
works perfectly with AMR, so there is some bug still in the 3D native code of (at least!) foam-extend! The interFoam DamBreak tutorial works fine, however. So I suppose, some compressible fluxes are handled incorrectly? I don't have the knowledge to dig through the hex-cutter-code :-( Anyone has the same problem?


Best regards,
Ma-tr-ix


--------------------


Hi,


I ran the code in debug mode and it seems that polyMeshInitMesh.C doesn't tell the solver to update the cell indices:

Selected 400 cells for refinement out of 54000.

From function void polyMesh::initMesh()
in file meshes/polyMesh/polyMeshInitMesh.C at line 81
Truncating neighbour list at 166476 for backward compatibility
Refined from 54000 to 56800 cells.
Selected 0 split points out of a possible 400.
time step continuity errors : sum local = 0.0011473583, global = -3.1287473e-19, cumulative = -3.1287473e-19
GAMGPCG: Solving for pcorr, Initial residual = 1, Final residual = 2.9710917e-06, No Iterations 24
PCG: Solving for pcorr, Initial residual = 1.4856334e-06, Final residual = 1.4856334e-06, No Iterations 0
PCG: Solving for pcorr, Initial residual = 1.4856334e-06, Final residual = 1.4856334e-06, No Iterations 0
time step continuity errors : sum local = 0.00012217958, global = -3.7530916e-19, cumulative = -6.8818388e-19
PIMPLE: iteration 1
MULES: Solving for alpha1


--> FOAM FATAL ERROR:
index 54000 out of range 0 ... 53999

From function UList<T>::checkIndex(const label)
in file /home/koch/foam/foam-extend-4.0/src/foam/lnInclude/UListI.H at line 124.

FOAM aborting

Aborted (core dumped)

it seems

[ma-tri-x]

Found the solution:


I created my Mesh with stitchMesh.
StitchMesh destroys AMR compatibility


----
with depthCharge3D it works

[HPE]

Hi Neo,

The thing I dont understand is how stitchmesh can affect the solution? if the final mesh is valid, how come the meshing procedure would have an impact on the solution? curious.

[ma-tri-x]

Originally Posted by HPE

Hi Neo,

The thing I dont understand is how stitchmesh can affect the solution? if the final mesh is valid, how come the meshing procedure would have an impact on the solution? curious.

Yep, I'd like to know, too. We've found many mysterious things like this also with snappyHexMesh destroying somehow symmetries of the solution of a two-phase calculation...


Fortunately, Luca Cornolti's dynamicRefineFvMesh2D library is robust so far against using stitchMesh or snappyHexMesh. Still, to my mind, he wrote the best AMR library.

[HPE]

Ah, I really wish the world would be full of mysteries. Sooner or later, really boring reasons appear behind each mysterious event in this f.ckng world.

I will pursue ur interesting observation in my free time though. Curious. Thank you.