CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > Software User Forums > OpenFOAM > OpenFOAM Running, Solving & CFD

Faces during change of topology in the mesh

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

Reply
 
LinkBack Thread Tools Search this Thread Display Modes
Old   July 3, 2009, 10:05
Default Faces during change of topology in the mesh
  #1
Member
 
Virginie Ehrlacher
Join Date: Mar 2009
Posts: 52
Rep Power: 17
virginie_e is on a distinguished road
Hi Foamers,

I have a question about OpenFOAM and the mesh handling.

I am trying to code an interTrackFoam solver which would keep the quality of the mesh above a certain level (typically, I use as an indicator the ratio of the inradius and the circumradius of the tetrahedra of the mesh and I do not allow it to be under a minimum value).

So I coded functions which enables the cells of the mesh to check this criterion and when I look at the resulting mesh, everything seems fine: there is no irregularity or holes in the mesh and the process runs without any error message.

However, when I perform this function, the calculus of U and p goes on a little while but quickly produce a time step continuity error.

I think this is due to the fact that I did not correctly orient my faces: I read somewhere that an internal face should be such has neighbour label > owner label and such that the ordering of the points produce a normal which points into the neighbour cell (with the right-hand rule).

Is there a way to set the orientation of the faces right automatically with the class directTopoChange? I saw variables such as flipFaceFlux... Is that it? Should I set this to true?

Or have you got any idea of what this error could be due to? Thank you a lot in advance.

Virginie
virginie_e is offline   Reply With Quote

Old   July 11, 2009, 22:54
Default
  #2
Senior Member
 
Sandeep Menon
Join Date: Mar 2009
Location: Amherst, MA
Posts: 403
Rep Power: 25
deepsterblue will become famous soon enough
I'm quite sure that the error is due to a wrong flux value, and you're right - flipFaceFlux is used to reverse the face-flux if the face changed orientation due to a topo-change. However, you can choose to correct fluxes explicitly using an additional pressure Poisson equation - take a cue from icoDyMFoam, where a correctPhi.H is used.

It's up to you to decide whether the Poisson solution is warranted - it may or may not be a performance issue. For simple topo-changes, flipFaceFlux is a convenient way to maintain divergence-free fluxes, but more complicated situations might simply be too difficult to handle, and a Poisson solution is a more convenient solution (which I'm really not fond of).

Hope this helps.
__________________
Sandeep Menon
University of Massachusetts Amherst
https://github.com/smenon
deepsterblue is offline   Reply With Quote

Old   August 13, 2009, 04:47
Default
  #3
Member
 
Virginie Ehrlacher
Join Date: Mar 2009
Posts: 52
Rep Power: 17
virginie_e is on a distinguished road
Thank you very much Sandeep for your answer. It helped me indeed to solve the problems I had. I had though another question: I read somewhere that for a given face, the cell label of the neighbour cell should be greater than the label owner. What might happen if it is not the case? If i set the option cells renumbering true in the directTopoChange function update mesh, does it set cell labels so that this rule is respected?

Thank you a lot.

Virginie
virginie_e is offline   Reply With Quote

Old   August 15, 2009, 14:32
Default
  #4
Senior Member
 
Sandeep Menon
Join Date: Mar 2009
Location: Amherst, MA
Posts: 403
Rep Power: 25
deepsterblue will become famous soon enough
Yup. It's good to be consistent about owner-neighbour ordering, since this approach has the advantage of being able to assume (without a priori knowledge about the mesh) that face normals will point from owner to neighbour, and that face right-handedness defines that direction as well. The face-normal direction is fairly important while defining gradient/divergence operators, and I suspect that improper owner-neighbour numbering won't have an impact on solution results, but I haven't tested this. I think it would be easier to play safe and stick to the convention.

A cursory glance at the directTopoChange code suggests that the owner-neighbour ordering is taken care of during the re-ordering stage. I found this bit of code in directTopoChange.C:

Code:
            // Renumber owner/neighbour. Take into account if neighbour suddenly
            // gets lower cell than owner.
            forAll(faceOwner_, faceI)
            {
                label own = faceOwner_[faceI];
                label nei = faceNeighbour_[faceI];

                if (own >= 0)
                {
                    // Update owner
                    faceOwner_[faceI] = localCellMap[own];

                    if (nei >= 0)
                    {
                        // Update neighbour.
                        faceNeighbour_[faceI] = localCellMap[nei];

                        // Check if face needs reversing.
                        if
                        (
                            faceNeighbour_[faceI] >= 0
                         && faceNeighbour_[faceI] < faceOwner_[faceI]
                        )
                        {
                            faces_[faceI] = faces_[faceI].reverseFace();
                            Swap(faceOwner_[faceI], faceNeighbour_[faceI]);
                        }
                    }
                }
                else if (nei >= 0)
                {
                    // Update neighbour.
                    faceNeighbour_[faceI] = localCellMap[nei];
                }
            }
Hope this helps.
__________________
Sandeep Menon
University of Massachusetts Amherst
https://github.com/smenon
deepsterblue is offline   Reply With Quote

Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
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 Off
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
Gambit problems Althea FLUENT 22 January 4, 2017 04:19
fluent add additional zones for the mesh file SSL FLUENT 2 January 26, 2008 12:55
Error to re-open fluent case file J.Gimbun FLUENT 0 April 27, 2006 09:42
How to control Minximum mesh space? hung FLUENT 7 April 18, 2005 10:38
Sliding mesh error Karl Kevala FLUENT 4 February 21, 2001 16:52


All times are GMT -4. The time now is 07:01.