bugpyFormex - Bugs: bug #37957, border mesh of Wedge meshes

 
 

bug #37957: border mesh of Wedge meshes

Submitted by:  gianluca de santis <gianlucadesi>
Submitted on:  Wed 19 Dec 2012 10:43:17 AM UTC  
 
Category: CoreSeverity: 3 - Normal
Item Group: Functionality errorStatus: Fixed
Privacy: PublicAssigned to: Benedict Verhegghe <bverheg>
Open/Closed: Closed

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

(Jump to the original submission Jump to the original submission)

Sat 22 Dec 2012 05:58:09 PM UTC, comment #6:

In revision 2617 Connectivity.insertLevel has been changed so that it detects identical degenerate elements even if their node numbering is different. Example: elements [0,1,1,2] and [0,1,2,2] are identical.
No further changfes are needed. All function keep returning a single Connectivity, possibly containing degenerate elements.
It is left to the user to split it using reduceDegenerate.

Benedict Verhegghe <bverheg>
Project AdministratorIn charge of this item.
Thu 20 Dec 2012 03:35:39 PM UTC, comment #5:

There still is a possibility that not all internal triangles are removed. But we could use testDegenerate/reduceDegenerate inside getFreeEntities to detect and remove them. And Leave the return value as it is: a single Connectivity with triangles and quads.
The user can then indeed easily do the final split of the border mesh himself, in the way you have shown. We should just document well which elements may produce degenerate meshes.

Benedict Verhegghe <bverheg>
Project AdministratorIn charge of this item.
Thu 20 Dec 2012 01:53:48 PM UTC, comment #4:

The border faces of a wedge mesh can now be solved using reduceDegenerate().
Check the example:

from elements import Hex8
w0=Mesh(Hex8).convert('hex8-8').convert('wedge6').fuse()
draw(w0)
w=w0.trl([2., 0., 0.])

T, Q = w.getBorderMesh().reduceDegenerate()
draw( [T.setProp(1), Q.setProp(2)])

#et, eq=w.getBorder().reduceDegenerate()
#draw(Mesh(w.coords, et).setProp(1))
#draw(Mesh(w.coords, eq).setProp(2))

gianluca de santis <gianlucadesi>
Project Member
Wed 19 Dec 2012 04:06:18 PM UTC, comment #3:

The change in revision 2613 makes your example work correctly.
And it probably will work well for most regular meshes. But I suggest we add changes in the sense of the previous comments anyway.

Benedict Verhegghe <bverheg>
Project AdministratorIn charge of this item.
Wed 19 Dec 2012 03:44:51 PM UTC, comment #2:

I have to correct myself here: the medium level, where the change is to be implemented, would have to be getFreeEntities, not getBorder.
This means that it is a little deeper than one would wish, and more changes will be needed than I had anticipated. So a good reason to give it a second thought.

- Can we avoid that different node numberings are generated for the degenerate elements?
-- OR --
- Can we (easily) detect the equality of two degenerate elements with different node numbering (e.g using masked arrays, or putting in -1 values instead of duplicating a node)?

Then we can indeed push up the proposed changes into getBorder.

Benedict Verhegghe <bverheg>
Project AdministratorIn charge of this item.
Wed 19 Dec 2012 02:57:22 PM UTC, comment #1:

The insertLevel method on which getBorder is based, can only return a single type of lower order element. For wedge elements however, the border consists of triangles and quadrilaterals. The question of how to properly deal with such cases was postponed, because there was no immediate need. Thus we just put in the triangles as degenerate quadrilaterals. Now it seems that a degenerate triangle ijk may turn up once as a quadrilateral ijjk and once as ikkj, making this two different quads, causing them to be considered part of the border.

How to fix this without having to change too much, or putting too much burden on the user for most use cases? How to generally deal with Meshes consisting of multiple element types? This could be a question to solve on the next pyFormex user meeting, but I would like to hear opinions already.

For now I propose to solve it in the following way:
- Low level methods, like insertLevel, always return a single Connectivity (of the highest plexitude) and lower plexitude elements are put in as degenerate elements. (NO CHANGE)
- Medium level methods, like getBorder, get an option to either reduce the degenerate elements (and then return a list of Connectivities with different plexitudes), or not reduce (DEFAULT) and then return a single Connectivity, possibly containing degenerate elements. (CHANGE WHEN REQUESTED)
- High level methods, like getBorderMesh, return a single Mesh when the border consist of a single element type, but return a list of Meshes when the border has multiple types. (NO CHANGE for most element types, ALWAYS CHANGE for Wedge type elements).
The fact that the return type is not fixed would only be a problem in algorithms that work independently of element type. This will probably be mostly related to drawing the result. But since the draw() function already takes a list of Meshes as well as a single Mesh, that would present no problem.

Benedict Verhegghe <bverheg>
Project AdministratorIn charge of this item.
Wed 19 Dec 2012 10:43:17 AM UTC, original submission:

The Mesh functions do not work well on wedge meshes. The border of a wedge mesh cannot be found correctly. However, I think it can be fixed easily.
This example shows where the problem occurs:

from elements import Hex8
w0=Mesh(Hex8).convert('hex8-8').convert('wedge6').fuse()
draw(w0)

w=w0.trl([2., 0., 0.])
####get the 2 border meshes (quad and tri) of of wedge mesh
brd = w.getBorder()
q = brd.removeDegenerate()
t = brd[brd.listDegenerate()]
t=t[:, [0, 1, 3]]#reduce degenerate
t.eltype ='tri3'#change from quad4 to tri3

brdQ = Mesh(w.coords, q)
brdT = Mesh(w.coords, t)
draw(brdQ, color='red')
draw(brdT, color='green')

#if you just draw brdT you can see that the triangles inside have not been
#remove by the getBorder(). Why??
draw(brdT.trl([2., 0., 0.]), color='green')

gianluca de santis <gianlucadesi>
Project Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by bverheg (Posted a comment)
  • -unavailable- added by gianlucadesi (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 6 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Sat 22 Dec 2012 05:58:09 PM UTCbverhegStatusIn Progress=>Fixed
      Open/ClosedOpen=>Closed
    Wed 19 Dec 2012 04:06:18 PM UTCbverhegCategoryNone=>Core
      Item GroupNone=>Functionality error
      StatusNone=>In Progress
      Assigned toNone=>bverheg

    Back to the top


    Powered by Savane 3.1-cleanup1