From: Paul T. B. <ptb...@gm...> - 2012-09-05 20:16:25
|
All, I've created a patch against r5998 that implements first order Nedelec elements of the first type for triangles and quads, including a new vector_fe_ex3 which solves curl curl u + u = f for both the triangle and quads. The patch also includes updates to ExactSolution to compute HCurl and HDiv errors, with HCurl being computed in the example. I verified the correct order of convergence (note for the Nedelec elements of the first type, you don't get optimal L2 convergence). The patch can be found here: http://users.ices.utexas.edu/~pbauman/nedelec_one.patch Comments: 1. I've put in place holders for 3D, but they aren't there yet (libmesh_implemented() is sprinkled in the right places). I'm going to open another thread about handling edge/face orientation in a more encapsulated way (for 2D I've just put the checks in the shape function calculations). Face orientation (for higher order) is going to be a bit messy, I think. Otherwise, all that remains is to derive the shape functions and implement them. 2. AFAICT, there's no hang ups on going to higher order 2D elements other than deriving the shape functions, implementing them, and making sure the edge orientation is handled correctly for multiple edge dofs (again, another thread coming on encapsulating the orientation business). 3. I've left the constraint code, but commented out, in fe_nedelec_one.C as a place holder. HCURL continutity constraints need to be implemented, but I'm still working it out because the curl operator makes 2-D vs. 3-D a bit of a pain. Thus, no adaptivity yet. 4. The example is using penalty boundary conditions because HCURL DirichletConstraints still need to be implemented. Again, a pain for 2-D vs. 3-D. 5. Just to be clear, the (excellent) report I cite in the code comes from the deal.ii website, but I came across it through a Google search. All the code is my own, or copied from existing libMesh code, and nothing came from deal.ii. 6. For higher-order tet elements, we'll need a tet14 for the face dofs. I compiled and ran all the examples in devel mode for real and complex (w/o slepc) with --enable-everything. Comments? OK for trunk? Best, Paul |
From: John P. <jwp...@gm...> - 2012-09-05 20:46:08
|
On Wed, Sep 5, 2012 at 2:16 PM, Paul T. Bauman <ptb...@gm...> wrote: > > 5. Just to be clear, the (excellent) report I cite in the code comes from > the deal.ii website, but I came across it through a Google search. All the > code is my own, or copied from existing libMesh code, and nothing came from > deal.ii. Hmm... if it was me, I definitely would have copied deal.ii ;-) > 6. For higher-order tet elements, we'll need a tet14 for the face dofs. Interesting. 4 vertex + 6 midedge + 4 midface nodes? If you're looking for suggestions, I'd number the midface nodes last, in the same order as the faces. And get Ben to generate the ASCII art for the documentation! -- John |
From: Roy S. <roy...@ic...> - 2012-09-05 20:50:17
|
On Wed, 5 Sep 2012, John Peterson wrote: > On Wed, Sep 5, 2012 at 2:16 PM, Paul T. Bauman <ptb...@gm...> wrote: > >> 6. For higher-order tet elements, we'll need a tet14 for the face dofs. > > Interesting. 4 vertex + 6 midedge + 4 midface nodes? Right. We've needed a TET14 for a while; it would let us implement things like p>2 hierarchic tets too. > If you're looking for suggestions, I'd number the midface nodes last, > in the same order as the faces. Definitely. > And get Ben to generate the ASCII art for the documentation! Heheheh! --- Roy |
From: Roy S. <roy...@ic...> - 2012-09-05 20:48:39
|
On Wed, 5 Sep 2012, Paul T. Bauman wrote: > The patch can be found here: 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 |
From: Paul T. B. <ptb...@gm...> - 2012-09-10 20:34:15
|
On Wed, Sep 5, 2012 at 3:48 PM, Roy Stogner <roy...@ic...>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! |
From: Paul T. B. <ptb...@gm...> - 2012-09-05 20:49:42
|
On Wed, Sep 5, 2012 at 3:45 PM, John Peterson <jwp...@gm...> wrote: > On Wed, Sep 5, 2012 at 2:16 PM, Paul T. Bauman <ptb...@gm...> wrote: > > > > 5. Just to be clear, the (excellent) report I cite in the code comes from > > the deal.ii website, but I came across it through a Google search. All > the > > code is my own, or copied from existing libMesh code, and nothing came > from > > deal.ii. > > Hmm... if it was me, I definitely would have copied deal.ii ;-) > Hahaha. :P > > > 6. For higher-order tet elements, we'll need a tet14 for the face dofs. > > Interesting. 4 vertex + 6 midedge + 4 midface nodes? > For Nedelec, you don't have any vertex dofs, just edges (first order), edge and faces (second order), and edges, faces, and interior (third+). > > If you're looking for suggestions, I'd number the midface nodes last, > in the same order as the faces. > Thanks, that would be my plan. But, at the moment, it's low on the list. I was just trying to point out the caveats that I were at the front of my mind. > > And get Ben to generate the ASCII art for the documentation! > Of course! :P |
From: Paul T. B. <ptb...@gm...> - 2012-09-06 15:29:41
|
On Wed, Sep 5, 2012 at 3:49 PM, Paul T. Bauman <ptb...@gm...> wrote: > Thanks, that would be my plan. But, at the moment, it's low on the list. I > was just trying to point out the caveats that I were at the front of my > mind. > I knew I was forgetting something... 7. The 2-D case is currently only valid for elements in the X-Y plane (i.e. no 2-D manifolds in 3-D space). Basically, we're assuming that the curl is always the z-component. Will need to do some math to generalize. This is really a pain for cylindrical coordinates, but I'm going to start another thread about that because we need to do something better for cylindrical coordinates anyway. |