CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > OpenFOAM

Wrong oriented faces due to opposite face bends?

Register Blogs Members List Search Today's Posts Mark Forums Read

Reply
 
LinkBack Thread Tools Display Modes
Old   August 10, 2012, 12:32
Default Wrong oriented faces due to opposite face bends?
  #1
Senior Member
 
Arne Stahlmann
Join Date: Nov 2009
Location: Hanover, Germany
Posts: 209
Rep Power: 8
Arnoldinho is on a distinguished road
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
Attached Images
File Type: jpg bend1.jpg (30.4 KB, 75 views)
File Type: jpg bend2.jpg (29.9 KB, 53 views)
Arnoldinho is offline   Reply With Quote

Old   August 13, 2012, 07:15
Default
  #2
ngj
Senior Member
 
Niels Gjoel Jacobsen
Join Date: Mar 2009
Location: Rotterdam, The Netherlands
Posts: 1,592
Rep Power: 24
ngj will become famous soon enoughngj will become famous soon enough
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
ngj is offline   Reply With Quote

Old   August 14, 2012, 12:01
Default
  #3
Senior Member
 
Arne Stahlmann
Join Date: Nov 2009
Location: Hanover, Germany
Posts: 209
Rep Power: 8
Arnoldinho is on a distinguished road
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
Arnoldinho is offline   Reply With Quote

Old   August 16, 2012, 04:40
Default
  #4
ngj
Senior Member
 
Niels Gjoel Jacobsen
Join Date: Mar 2009
Location: Rotterdam, The Netherlands
Posts: 1,592
Rep Power: 24
ngj will become famous soon enoughngj will become famous soon enough
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
ngj is offline   Reply With Quote

Old   August 16, 2012, 04:49
Default
  #5
Senior Member
 
Arne Stahlmann
Join Date: Nov 2009
Location: Hanover, Germany
Posts: 209
Rep Power: 8
Arnoldinho is on a distinguished road
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
Arnoldinho is offline   Reply With Quote

Old   August 16, 2012, 05:00
Default
  #6
ngj
Senior Member
 
Niels Gjoel Jacobsen
Join Date: Mar 2009
Location: Rotterdam, The Netherlands
Posts: 1,592
Rep Power: 24
ngj will become famous soon enoughngj will become famous soon enough
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
ngj is offline   Reply With Quote

Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
udf error srihari FLUENT 0 February 9, 2009 10:00
BlockMeshmergePatchPairs hjasak OpenFOAM Native Meshers: blockMesh 11 August 15, 2008 07:36
Wrong face orientations after conversion from fluent mesh stevecollie OpenFOAM Other Meshers: ICEM, Star, Ansys, Pointwise, GridPro, Ansa, ... 6 July 14, 2008 07:20
Axisymmetrical mesh Rasmus Gjesing (Gjesing) OpenFOAM Native Meshers: blockMesh 10 April 2, 2007 14:00
Trimmed cell and embedded refinement mesh conversion issues michele OpenFOAM Other Meshers: ICEM, Star, Ansys, Pointwise, GridPro, Ansa, ... 2 July 15, 2005 04:15


All times are GMT -4. The time now is 00:29.