I wrote a paper on the subject of canonical ordering for FE meshes (DOI 10.1002/cnm.1237) that provides an API for getting numbering information; it's also implemented in a relatively dependency-free class in MOAB (https://svn.mcs.anl.gov/repos/ITAPS/MOAB/trunk/src/moab/CN.hpp, https://svn.mcs.anl.gov/repos/ITAPS/MOAB/trunk/src/CN.cpp). Higher-order node numbering follows corner node numbering, similar to ExodusII, and numbering of e.g. edge-resolving HO nodes comes before face-resolving HO nodes, etc. This has proven very useful for evaluating side numbers, relative orientations, and other numbering-related things.
The numbering of HO nodes should work for third order and higher, assuming if one facet of a given dimension is resolved with an HO node all the facets of that dimension are. For quadratic and linear elements, the total # nodes in an element is unambiguous too, at least for the element types covered by MOAB. In the general case for unstructured meshes, for matching faces to adjacent elements, you'll need not only sense (+1 or -1), but also relative rotation of the vertices. - tim On 09/11/2012 02:15 PM, libmesh-devel-requ...@lists.sourceforge.net wrote: > Date: Thu, 6 Sep 2012 10:49:57 -0500 (CDT) > From: Roy Stogner <royst...@ices.utexas.edu> > Subject: Re: [Libmesh-devel] Handling edge/face orientation and > element order > To: "Paul T. Bauman" <ptbau...@gmail.com> > Cc: libmesh-devel <libmesh-devel@lists.sourceforge.net> > Message-ID: > <alpine.lrh.2.02.1209061032490.28...@spark.ices.utexas.edu> > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > > On Wed, 5 Sep 2012, Paul T. Bauman wrote: > >> I wanted to solicit ideas and discussion for designs handling the >> edge/face orientation and element order. In particular, for scalar >> Lagrange elements of order >= 3 (and other scalar elements) or >> oriented vector elements (e.g. Nedelec), the orientation of the >> element matters > > Orientation ends up important for us for anything where we end up > having more than one DoF supported on an edge or face. I think that's > *everything* of order 3+, except for the C1 elements, where in one > sense orientation matters immediately but in another sense it doesn't > start mattering until you get into quartics or quintics. > >> and must be taken into account to ensure continuity of the solution. >> Right now, this is handled on a case-by-case basis in the hierarchic >> elements and the nedelec elements, but we ought to be able to do >> better. In particular, for 3-D, higher order, the face orientation >> handling is going to be ugly (I think). For sure, even >> the edge orientation for the hexes and tets will be a bit long >> winded and it would be nice to have that in one place. > > Agreed, if that's possible. > >> My thinking is that such an FEOrientation (other suggestions for >> names?) function (object?) should return a scaling factor (either 1 >> or -1 ) that depends on the geometric element and finite element >> type and order and then each finite element class can call as >> needed. > > Scaling factor isn't enough in general, though. It works for the > hierarchics and nedelecs, but for high-order Lagrange you'd need to > "reshuffle" local->global degree of freedom indexing too. And I don't > think the scaling factors for the hierarchics match the ones for the > nedelecs. > >> 3. Implement an edge (and face in 3D) orientation function within >> each geometric element type that returns the scaling factor and then >> have each finite element type worry about the element order scaling >> factor. > > This sounds ideal, if it could be made to owrk. > --- > Roy > > > > ------------------------------ > > Message: 4 > Date: Thu, 6 Sep 2012 16:53:52 -0500 (CDT) > From: Roy Stogner <royst...@ices.utexas.edu> > Subject: [Libmesh-devel] libmesh 0.7.3.2 release > To: libmesh-us...@lists.sourceforge.net, > libmesh-devel@lists.sourceforge.net > Message-ID: > <alpine.lrh.2.02.1209061650260.28...@spark.ices.utexas.edu> > Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII > > > Our svn head is going to be in quite a bit of flux for the forseeable > future, but our stable releases' ability to build against the latest > PETSc/SLEPc shouldn't be subject to unforeseeable delay. Hence this > afternoon's release of libMesh 0.7.3.2, a.k.a. "libMesh 0.7.3.1 plus a > couple tiny backported compatibility fixes". > > https://sourceforge.net/projects/libmesh/files/libmesh/libmesh-0.7.3.2/ > --- > Roy > > > > ------------------------------ > > Message: 5 > Date: Mon, 10 Sep 2012 15:34:06 -0500 > From: "Paul T. Bauman" <ptbau...@gmail.com> > Subject: Re: [Libmesh-devel] FENedelecOne > To: Roy Stogner <royst...@ices.utexas.edu> > Cc: libmesh-devel <libmesh-devel@lists.sourceforge.net> > Message-ID: > <CAKiVBtvum9Y=m2kLrQXe3PsjAYpeOAjCk2P8JCKNr=A9dN=2...@mail.gmail.com> > Content-Type: text/plain; charset="iso-8859-1" > > On Wed, Sep 5, 2012 at 3:48 PM, Roy Stogner <royst...@ices.utexas.edu>wrote: > >> >> On Wed, 5 Sep 2012, Paul T. Bauman wrote: >> >> The patch can be found here: http://users.ices.utexas.edu/~** >>> pbauman/nedelec_one.patch<http://users.ices.utexas.edu/~pbauman/nedelec_one.patch> >>> >>> Comments? OK for trunk? >>> >> >> I'd give others some time to comment first, but all looks great to me. >> --- >> Roy >> > > Committed in r6003. Went ahead and tested --disable-second after seeing > r6002 and, indeed, had to make 1 small change to the patch. Thanks! > -------------- next part -------------- > An HTML attachment was scrubbed... > > ------------------------------ > > Message: 6 > Date: Tue, 11 Sep 2012 11:36:42 -0600 > From: Derek Gaston <fried...@gmail.com> > Subject: [Libmesh-devel] Periodic BCs with Offset > To: libmesh-devel@lists.sourceforge.net > Message-ID: > <caffxpjo6v2ipjpozuygza4r3xr3yidhbnb8t0s61dg8usac...@mail.gmail.com> > Content-Type: text/plain; charset="iso-8859-1" > > One of our users is looking for the ability to do Periodic BCs... but where > instead of have _equality_ on either side of the periodic boundary you > instead have a constant offset. > > So if u_i is periodic with u_j you would then have the constraint that u_j > = u_i + c ... where c is that specified offset. > > What's really tricky is that they want a different constant value for each > variable. > > Anyone see a way to make that happen? > > Derek > -------------- next part -------------- > An HTML attachment was scrubbed... > > ------------------------------ > > Message: 7 > Date: Tue, 11 Sep 2012 12:44:35 -0500 (CDT) > From: Roy Stogner <royst...@ices.utexas.edu> > Subject: Re: [Libmesh-devel] Periodic BCs with Offset > To: Derek Gaston <fried...@gmail.com> > Cc: libmesh-devel@lists.sourceforge.net > Message-ID: > <alpine.lrh.2.02.1209111242050.29...@spark.ices.utexas.edu> > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > > On Tue, 11 Sep 2012, Derek Gaston wrote: > >> One of our users is looking for the ability to do Periodic BCs... but where >> instead of have _equality_ on either side of the periodic boundary you >> instead have a constant offset. >> So if u_i is periodic with u_j you would then have the constraint that u_j = >> u_i + c ... where c is that specified offset. >> >> What's really tricky is that they want a different constant value for each >> variable. >> >> Anyone see a way to make that happen? > > It'd actually be pretty easy now that the heterogenous constraints are > in - we'd just want to add "offset" values to the PeriodicBoundary > class and respect that when constructing the constraint equations. > > The main problem is: isn't the new PBC code still failing some of your > tests? Last I heard, John still had a MOOSE regression test breaking > but hadn't been able to distill it down into a libMesh-only failure > case to send me. > --- > Roy > > > > ------------------------------ > > Message: 8 > Date: Tue, 11 Sep 2012 13:15:47 -0600 > From: Cody Permann <codyperm...@gmail.com> > Subject: Re: [Libmesh-devel] Periodic BCs with Offset > To: Roy Stogner <royst...@ices.utexas.edu> > Cc: Derek Gaston <fried...@gmail.com>, > libmesh-devel@lists.sourceforge.net > Message-ID: > <CAK06EuUHe_Ax-FaZtQAgHVLxUTmwpEBAf3C_Teq5nbaSJ=e...@mail.gmail.com> > Content-Type: text/plain; charset="iso-8859-1" > > On Tue, Sep 11, 2012 at 11:44 AM, Roy Stogner <royst...@ices.utexas.edu>wrote: > >> >> On Tue, 11 Sep 2012, Derek Gaston wrote: >> >>> One of our users is looking for the ability to do Periodic BCs... but >> where instead of have _equality_ on either side of the periodic boundary you >>> instead have a constant offset. >>> So if u_i is periodic with u_j you would then have the constraint that >> u_j = u_i + c ... where c is that specified offset. >>> >>> What's really tricky is that they want a different constant value for >> each variable. >>> >>> Anyone see a way to make that happen? >> >> It'd actually be pretty easy now that the heterogenous constraints are >> in - we'd just want to add "offset" values to the PeriodicBoundary >> class and respect that when constructing the constraint equations. >> >> The main problem is: isn't the new PBC code still failing some of your >> tests? Last I heard, John still had a MOOSE regression test breaking >> but hadn't been able to distill it down into a libMesh-only failure >> case to send me. >> > > So we do still have one test that's failing. John coded up the example in > pure libMesh code and it works so the problem doesn't appear to be on your > end. However there are a few differences in the way MOOSE solves it and > Johns example: for one we solve every problem with a transient nonlinear > system using JFNK which is of course different from the simple example John > has already coded up using a linear system. We were down to looking at > differences in the system matrix to try to figure out why things were > different, but will need more time to narrow down the issue. > > I think we've decided that we are going to put this one problem to the side > for now since it has been a hefty time sink and move forward until we have > some more downtime. The remaining PBCs issues appear to be solved using > your latest (uncommitted?) patch. We are going to work on updating all of > our users to the current head of libMesh barring any other issues. Thanks > for working on this for us! > > Cody > > >> --- >> Roy >> >> >> ------------------------------------------------------------------------------ >> Live Security Virtual Conference >> Exclusive live event will cover all the ways today's security and >> threat landscape has changed and how IT managers can respond. Discussions >> will include endpoint security, mobile security and the latest in malware >> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >> _______________________________________________ >> Libmesh-devel mailing list >> Libmesh-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/libmesh-devel >> > -------------- next part -------------- > An HTML attachment was scrubbed... > > ------------------------------ > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > > ------------------------------ > > _______________________________________________ > Libmesh-devel mailing list > Libmesh-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/libmesh-devel > > > End of Libmesh-devel Digest, Vol 75, Issue 3 > ******************************************** > -- ================================================================ "You will keep in perfect peace him whose mind is steadfast, because he trusts in you." Isaiah 26:3 Tim Tautges Argonne National Laboratory (taut...@mcs.anl.gov) (telecommuting from UW-Madison) phone (gvoice): (608) 354-1459 1500 Engineering Dr. fax: (608) 263-4499 Madison, WI 53706 ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Libmesh-devel mailing list Libmesh-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-devel
