[Mparuz]

Hi SAI_
I'm stuck on your same issue for a 2D case in which I have assigned to the "front" and "back" patches the empty type. How could I manage the problem? I need to mantain the empty type because of the nature of the model.


Thanks,
Mparuz

[Yann]

Hi,

You can remove the "empty" type to mesh with snappy, and then use changeDictionary to set your front and back patches back to empty.

Cheers,
Yann

[Mparuz]

Hi Yann,
SnappyHexMesh now seems to work. Thank you!
I have first modified both the patches "front" and "back" in the blockMeshDict from empty type to patch type. Then, I have done the same stuff in each boundary condition file (I've set both those patches in U, p_rgh, nut, etc. files to zeroGradient, just to give a dummy patch type). Meanwhile I've compiled the changeDictionaryDict like that:

/*--------------------------------*- C++ -*----------------------------------*\
  =========                 |
  \\      /  F ield         | OpenFOAM: The Open Source CFD Toolbox
   \\    /   O peration     | Website:  https://openfoam.org
    \\  /    A nd           | Version:  9
     \\/     M anipulation  |
\*---------------------------------------------------------------------------*/
FoamFile
{
    format      ascii;
    class       dictionary;
    object      changeDictionaryDict;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

boundary
{
    front
    {
        type            empty;
    }

    back
    {
        type            empty;
    }

}


omega
{

    boundaryField
    {
        front
        {
            type            empty;
        }

        back
        {
            type            empty;
        }
    }
}

U
{

    boundaryField
    {
        front
        {
            type            empty;
        }

        back
        {
            type            empty;
        }
    }
}

p_rgh
{

    boundaryField
    {
        front
        {
            type            empty;
        }

        back
        {
            type            empty;
        }
    }
}


alpha.water
{

    boundaryField
    {
        front
        {
            type            empty;
        }

        back
        {
            type            empty;
        }
    }
}


nut
{

    boundaryField
    {
        front
        {
            type            empty;
        }

        back
        {
            type            empty;
        }
    }
}


k
{

    boundaryField
    {
        front
        {
            type            empty;
        }

        back
        {
            type            empty;
        }
    }
}



// ************************************************************************* //

After that I've run the Dictionaries:


blockMesh


decomposePar -force -copyZero


mpirun -n 8 snappyHexMesh -parallel -overwrite


mpirun -n 8 renumberMesh -parallel -overwrite


mpirun -n 8 changeDictionary -parallel


mpirun -n 8 setFields -parallel


mpirun -n 8 interFoam -parallel


and IT'S EXECUTING!

[Yann]

All good Mparuz, good job!

I think you can skip the changes in the 0 directory and leave the boundary conditions on type empty for all your variables. Snappy should not read these files anyway, the important thing is the type in the polyMesh/boundary file.

Maybe I miss something since I did not try it, so it has to be tested, but I think it should work and it will make your changeDictionaryDict shorter.

Or you can just leave it like this, since you already have a working workflow. But I just wanted to add this for the sake of completness.

Cheers,
Yann

[Mparuz]

Hi Yann,
leaving the boundary conditions on type empty the dictionary renumberMesh gives me those errors:

Using default renumberMethod.

Selecting renumberMethod CuthillMcKee

Reading geometric fields

Reading volScalarField nut
[2]
[2]
[2] --> FOAM FATAL IO ERROR:
[2]
    patch type 'patch' not constraint type 'empty'
    for patch front of field nut in file "/mnt/c/Users/Gianluca/Desktop/ofdesk/presa3changedict2/processor2/0/nut"
[2]
[2] file: /mnt/c/Users/Gianluca/Desktop/ofdesk/presa3changedict2/processor2/0/nut/boundaryField/front from line 58[7]

Cheers,
Mparuz

[Yann]

Right I did not think about renumberMesh. Then run changeDictionary before renumberMesh and it should be fine.

Yann

[Mparuz]

Hi Yann,
I've added a RefinementBox in the snappyHexMeshDict with level of refinement=2 and interFoam works, but if I set refinement=1 for the SAME box, interFoam stops after the first iteration, giving me this message:

Create time

Create mesh for time = 0


PIMPLE: No convergence criteria found


PIMPLE: Operating solver in transient mode with 1 outer corrector
PIMPLE: Operating solver in PISO mode


Reading field p_rgh

Reading field U

Reading/calculating face flux field phi

Reading transportProperties

Selecting incompressible transport model Newtonian
Selecting incompressible transport model Newtonian
No phase change: phaseChangeProperties not found
Selecting phaseChange model none
Selecting turbulence model type RAS
Selecting RAS turbulence model kOmegaSST
Selecting patchDistMethod meshWave
RAS
{
    model           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;
}


Reading g

Reading hRef
Calculating field g.h

No MRF models present

No fvModels present
No fvConstraints present
GAMGPCG:  Solving for pcorr, Initial residual = 0, Final residual = 0, No Iterations 0
time step continuity errors : sum local = 0, global = 0, cumulative = 0
Courant Number mean: 0 max: 0

Starting time loop

Courant Number mean: 0 max: 0
Interface Courant Number mean: 0 max: 0
deltaT = 0.00119904
Time = 0.00119904

smoothSolver:  Solving for alpha.water, Initial residual = 0, Final residual = 0, No Iterations 0
Phase-1 volume fraction = 0.235967  Min(alpha.water) = 0  Max(alpha.water) = 1
MULES: Correcting alpha.water
Phase-1 volume fraction = 0.235967  Min(alpha.water) = 0  Max(alpha.water) = 1
GAMG:  Solving for p_rgh, Initial residual = 0.0253419, Final residual = 5.76349e-05, No Iterations 2
-------------------------------------------------------
Primary job  terminated normally, but 1 process returned
a non-zero exit code.. Per user-direction, the job has been aborted.
-------------------------------------------------------
--------------------------------------------------------------------------
mpirun detected that one or more processes exited with non-zero status, thus causing
the job to be terminated. The first process to do so was:

  Process name: [[43676,1],0]
  Exit code:    144
--------------------------------------------------------------------------
[DESKTOP-JQU5Q3J:01244] 7 more processes have sent help message help-btl-vader.txt / cma-permission-denied
[DESKTOP-JQU5Q3J:01244] Set MCA parameter "orte_base_help_aggregate" to 0 to see all help / error messages

what do you think could be the reason?


Thanks,
Mparuz

[Yann]

Hi Mparuz,

This is hard to tell without knowing more about your case, but it seems to be crashing while solving for the pressure. It could come from a lot of things: mesh, boundary conditions, numerical setup...

Have you checked the results of your case running with the additional refinement level? If the flow seems correct, then the source of the error is probably the mesh.

Yann

[Mparuz]

Hi Yann,
since the computation stops at "Time = 0.00119904", I cannot see if the results are good or not.

it seems to be crashing while solving for the pressure

What part of the error message makes you think that the model crashes for the pressure?


The model is a driven-pressure flow on interFoam: I have the geometry of a Spillway and I'm setting a fixed water level upstream (far away from the dam, to ensure non-interference between flow inlet and geometry) to allow the water pass over it.
The blockMesh is thinner than the body of the geometry and is 1 cell in the front-to-back direction.
When I run the model in serial process, it works perfectly and also the results seem to be near to the reality. The only error message that I see in Paraview is the following:

ERROR: In C:\glr\builds\paraview\paraview-ci\build\superbuild\paraview\src\VTK\IO\Geometry\vtkOpenFOAMReader.cxx, line 7184
vtkOpenFOAMReaderPrivate (00000299B6C2DFA0): Error reading line 2661 of C:\Users\GG\Desktop\ofdesk\presa3bis\1/p_rgh: Found duplicated entries with keyword rho

but I don't think that is correlated with the issue I have in the parallel processing.

I'm posting just the patches that are interested for the pressure-driven flow, because the other patches are walls, atmosphere and outlet.
The patch bottom1 is the real inlet patch to which I impose a hydrostatic pressure equivalent to a water height = 39 meters.
The patch wallLeftDown is the wall on the left "wetted" by the fixed level (in my model water flows from left to right).
The patch wallLeftUp is the wall above wallLeftDown and it will be in contact with air.

The alpha.water file is this one.

boundaryField
{
    
	#includeEtc "caseDicts/setConstraintTypes"
	
    wallLeftDown
    {
        type            fixedValue;
        value           uniform 1;
    }

    wallLeftUp
    {
        type            fixedValue;
        value           uniform 0;
    }

    bottom1
    {
        type            inletOutlet;//Using bottom1 as inlet
        inletValue      uniform 1;
        value           uniform 1;
    }

The p_rgh file is this one. I used prghTotalPressure to set the desired hydrostatic pressure to the "bottom1" patch, that will be the real inlet.

boundaryField
{
    
	#includeEtc "caseDicts/setConstraintTypes"
	
	bottom1
    {
        type            prghTotalPressure;
        //psi             none;
        //gamma           1;
        p0              uniform 390000;
        //value           uniform 390000;
    }
     
	wallLeftDown
    {
        type            fixedFluxPressure;
        gradient        uniform 0;
        value           uniform 0;
    }
    
	wallLeftUp
    {
        type            fixedFluxPressure;
        gradient        uniform 0;
        value           uniform 0;
    }

Finally, the U file. I use pressureInletOutletVelocity to give a flow rate based on the pressure on the patch "bottom1"

boundaryField
{   

    bottom1
    {
        type            pressureInletOutletVelocity;
        value           uniform (0 0 0);
    }

    wallLeftUp
    {
        type            fixedValue;
        value           uniform (0 0 0);
    }
    
    wallLeftDown
    {
        type            fixedValue;
        value           uniform (0 0 0);

I hope I've not forgotten anything.

Thanks,
Mparuz

[Yann]

Hi,

I just realized I forgot something in your workflow:

blockMesh
decomposePar -force -copyZero
mpirun -n 8 snappyHexMesh -parallel -overwrite
mpirun -n 8 extrudeMesh -parallel
mpirun -n 8 changeDictionary -parallel
mpirun -n 8 renumberMesh -parallel -overwrite
mpirun -n 8 setFields -parallel
mpirun -n 8 interFoam -parallel

Snappy cannot mesh in 2D since the mesh refinement process uses an octree structure. It means while meshing snappy will also add cells along the 3rd dimension.

This is why we need to use the extrudeMesh utility on 2D cases after meshing with snappyHexMesh. Basically it is used to extrude a one layer thickness mesh out of the front or back patch, and remove the rest of the mesh so you can get a clean one layer thickness mesh of your domain.

I'm not sure this is related to your issue, but it's better to have a clean start before debugging further.

Once it is done, if you still have issues can you post your case setup here?

Yann

[Mparuz]

Hi!

Maybe I've not understood so good. Should I use extrudeMesh to reduce the thickness of the mesh to the dimention of the smallest cell? Won't it affect the aspect ratio of all the other bigger cells?

I'm wondering why in serial processing it works and in parallel processing it doesn't

[Yann]

You should find some examples using extrudeMesh in the tutorials and also on the forum (have a look at this thread)

Basically the point is to take, lets say your front patch, extrude it to the desired thickness and get rid of everything else so you end up with a mesh having a single cell thickness in the 3rd direction everywhere.

The thickness value doesn't really matter as long as your front and back patches have a type empty and you run in 2D.

I hope this helps
Yann

[Mparuz]

Ok Yann! I'll try using extrudeMesh after some tutorials, anyway it sounds also to be a good procedure to cut down drastically the number of the mesh cells, i.e. time of simulation.
I'll let you know.

Cheers,
Mparuz

[Mparuz]

Hi Yann!
I've used extrudeMesh and it's working perfectly even after adding two refinementBoxes in the snappyHexMesh. Thanks a lot!

Cheers,
Mparuz