[wildfire230]

Hi all,

I am working on an axisymmetric simulation (the flow in between a parallel plate rheometer). Initially I had wanted to use a wedge mesh, but that only resulted in very high non-orthogonality and very small cell volumes near the center, so I have switched to using a wedge-ish geometry that I designed with three blocks. This seems to allow higher overall resolution while eliminating the extremely high non-orthogonalities and small cell volumes. An image of the mesh is attached.

However, the cyclic rotational boundary condition doesn't seem to work as well as I would expect. In fact, it seems to introduce strange artifacts into the results. For example, in the attached image you can see the fluid pressure. The top plate rotates about the origin, the bottom plate is stationary, and the outer boundary is a slip velocity condition. The pressure should be higher towards the outside and lower near the center. However, the cyclic boundary condition introduces a large magnitude artifact into the results.

The proper boundary condition for a rotationally periodic/cyclic case should be something like d/dtheta = 0, but this result clearly has gradients in the azimuthal direction.

Just to provide a few more details, I am using cyclicAMI boundary conditions, and the cyclic patches are defined as follows:

leftCyclic
{
type cyclicAMI;
neighbourPatch rightCyclic;
transform rotational;
rotationAxis (0 0 1);
rotationCentre (0 0 0);
matchTolerance 1.0e-12;
faces
(
(0 4 7 3)
(3 7 13 10)
);
}

rightCyclic
{
type cyclicAMI;
neighbourPatch leftCyclic;
transform rotational;
rotationAxis (0 0 1);
rotationCentre (0 0 0);
matchTolerance 1.0e-12;
faces
(
(5 4 0 1)
(11 5 1 8)
);
}

I would really appreciate any advice. Has anyone else struggled with this issue?

Thanks so much

[RicardoFE95]

Hi,

Could you upload your blockMeshDict? I think it might have to do with the expansion ratio between adjacent cells in that transition between blocks, I have read that you should avoid values larger than 10-20% in order to avoid inaccuracies.

[krikre]

What does the checkMesh utility report on orthogonality? The mesh near the rheometer axis looks extremely nonorthogonal.


Isn't the AMI unnecessary? I think blockMesh can produce cyclic.

[RicardoFE95]

Hello krikre,

I am interested in this case, I wrote a blockMeshDict that produces a mesh similar to the one posted by wildfire230. At first I thought that cyclic should have been enough but for some reason there were some problems with the transformation between neighbour patches. When I ran blockMesh defining the patches as cyclicAMI for some reason it worked properly.

Regarding the orthogonality of the mesh, checkMesh reports this:

Mesh stats
    points:           96942
    faces:            274342
    internal faces:   258458
    cells:            88800
    faces per cell:   6
    boundary patches: 18
    point zones:      0
    face zones:       0
    cell zones:       0

Overall number of cells of each type:
    hexahedra:     88800
    prisms:        0
    wedges:        0
    pyramids:      0
    tet wedges:    0
    tetrahedra:    0
    polyhedra:     0

Checking topology...
    Boundary definition OK.
    Cell to face addressing OK.
    Point usage OK.
    Upper triangular ordering OK.
    Face vertices OK.
    Number of regions: 1 (OK).

Checking patch topology for multiply connected surfaces...
    Patch               Faces    Points   Surface topology                  
    inlet1              200      234      ok (non-closed singly connected)  
    inlet2              200      234      ok (non-closed singly connected)  
    outlet1             64       81       ok (non-closed singly connected)  
    outlet2             64       81       ok (non-closed singly connected)  
    outlet3             64       81       ok (non-closed singly connected)  
    outlet4             200      234      ok (non-closed singly connected)  
    outlet5             200      234      ok (non-closed singly connected)  
    bluffBody1          64       81       ok (non-closed singly connected)  
    bluffBody2          64       81       ok (non-closed singly connected)  
    bluffBody3          64       81       ok (non-closed singly connected)  
    lateralBoundary1    1200     1359     ok (non-closed singly connected)  
    lateralBoundary2    1200     1359     ok (non-closed singly connected)  
    backBoundary1       1200     1359     ok (non-closed singly connected)  
    backBoundary2       1200     1359     ok (non-closed singly connected)  
    backBoundary3       3750     3926     ok (non-closed singly connected)  
    frontBoundary1      1200     1359     ok (non-closed singly connected)  
    frontBoundary2      1200     1359     ok (non-closed singly connected)  
    frontBoundary3      3750     3926     ok (non-closed singly connected)  

Checking geometry...
    Overall domain bounding box (-0.0140791 0 0) (0.0140791 0.09 0.24)
    Mesh has 3 geometric (non-empty/wedge) directions (1 1 1)
    Mesh has 3 solution (non-empty) directions (1 1 1)
    Boundary openness (1.96998e-14 -1.05285e-14 -2.35128e-17) OK.
    Max cell openness = 2.69735e-16 OK.
    Max aspect ratio = 7.34451 OK.
    Minimum face area = 4.13497e-07. Maximum face area = 4.18433e-06.  Face area magnitudes OK.
    Min volume = 6.61595e-10. Max volume = 6.69493e-09.  Total volume = 0.000305343.  Cell volumes OK.
    Mesh non-orthogonality Max: 70.8443 average: 20.5095
   *Number of severely non-orthogonal (> 70 degrees) faces: 300.
    Non-orthogonality check OK.
  <<Writing 300 non-orthogonal faces to set nonOrthoFaces
    Face pyramids OK.
    Max skewness = 0.898211 OK.
    Coupled point location match (average 0) OK.

Mesh OK.

End

Do you think it's the non-orthogonality that's causing issues? Although checkMesh does note severe non-orthogonal faces, in the end it says mesh OK.

However I ran some simulations on this type of mesh, varying the quantity of cells, and the results are not very accurate at all. I am comparing these to an experiment and have done previous simulations on other meshes having obtained much better results overall.

In particular, there were issues in the block near the axis and a strange transition at the face shared by the outside blocks, I have circled this in the attachment.

Have you got any recommendation on improving this mesh? I am a bit lost on how to proceed.

[Hip2BL7]

Hi Wildfire,

WRT your mesh issues, I ran into this and it took me quite a long time to find the solution, and that is this extra line that needs to be added to the top of your blockMeshDict file in order to make sure that the faces on the axis of symmetry are deleted and the cells at the axis are treated as a wedge:
...

mergeType points;

...
As to your current mesh issues, it looks like there is some weird block scaling going on. I realise this was a while ago now but I would like to know what your outcome was.