[Arnoldinho]

Hi all,

I have a huge problem with a moving mesh case. I have implemented a mesh movement routine where the points are moved in vertical direction based on calculated distance functions. It now happens from time to time that the mesh becomes somehow distorted, whereas checkMesh gives the error "wrong oriented faces". After searching for the specific error in my calculations for a long time, the problem now seems to be an opposite "folding" of the faces lying over each other.

Below there are two pictures showing the face checkMesh marked as "wrong oriented" in red. As it can be seen (at least in ParaView), the faces (in this case the boundary face and the wrong oriented, inner face) overlap in the inner part, whereas the bends of the faces are in opposite directions. This is at least what I think might be the problem. The points of the red face are all located above the boundary face points!

So my questions are:
1. Is this really the problem (overlapping faces), or does it come from the ParaView display?
2. How can I further check this?
3. The most important one: How can I avoid such a behavior?

Thanks,
Arne

[ngj]

Greetings Arne,

First of all, I would like to congratulate you on your results, which were presented at the ICCE. It looking very promising.

Secondly, to address your problem. I am not sure why checkMesh delivers that particular error message, however, I am not surprised if a continuation of that behaviour would result in face centres being placed on the wrong side of each other.

I have been discussing with myself theoretically how one could prevent this sort of problems, and using a face->point bi-linear interpolation based on the results from the Exner equation does not guarantee nice point displacement behaviour (unless you resolve to using a triangular mesh of your bottom). You would otherwise need to redistribute the points every time step, such that (i) the faces remain coplanar within a certain tolerance and (ii) the displacement of the face centre still is that of the Exner equation. My intuition tells my that these two requirements cannot be fulfilled at the same time, thus you need to come up with a clever interpolation routine, which allows for a good quality mesh motion, which reflects as closely as possible the physical displacement.

Good luck

- Niels

[Arnoldinho]

Hi Niels,

thanks for your congratulations and suggestions. Concerning the first, there is still a lot to investigate, but I am coming closer to an end.

Concerning the second (the initial problem): You are right that the two requirements cannot be always fulfilled, whereas this seems to be very grid size and height change dependent.
So I have now been able to avoid (or better correct) this by making a call to the checkMesh internal functions during mesh updating procedure. Boundary points or better point changes due to solving of the Exner equation that result in wrongOrientedFaces are now "set back" to their former stage step by step until checkMesh give no more errors.
Fortunately, only small changes/corrections are necessary and this behavior occurs only once per ~100 updating iterations on single cells lying out of the area of special interest. Therefore I can live with such a modification .

Nevertheless, I still could not fully figure out why the faces were wrong oriented, as the single point displacements were fine compared to each other. Maybe this is just due to the way OF calculates the face orientation...

Greetings,
Arne

[ngj]

Hi Arne,

I am glad that you were successful in getting the code working - it seems like a neat use of the internal mesh checking.

With respect to the figure of the overlapping faces, then I suspect it occurs because the distance between the faces is not the same in the corners, i.e. one bc-adjacent point moves farther away from the bc than another bc-adjacent point. This allows for non-parallel faces in the boundary, however, since the cells are non-convex with large aspect ratio, I can imagine that you get cell/face centres which are not inside the cell/face.

Good luck

/ Niels

[Arnoldinho]

Hi Niels,

yes, it might indeed be a problem of non-parallel faces at the boundary cells. If I find the time, I will check an implementation on parallel ones. This would further have the advantage of direct control on the y+ values.

What I find a bit curious is the fact that this behavior only occurs at the patch cells and not above. But it might be because I always have the flattest cells here.

Greeting,
Arne

[ngj]

Yes, exactly. This is what I do to achieve control on the near-wall discretisation, as I must have a cell face placed in 2d (d = grain diameter) away from the wall due to my formulation of the suspended sediment transport.

/ Niels