search

libMesh / libmesh

libMesh github repository
http://libmesh.github.io
GNU Lesser General Public License v2.1
631 stars 283 forks source link

Expand support for different vector finite elements #1456

Open lindsayad opened 6 years ago

lindsayad commented 6 years ago

@cticenhour Could you talk about what type of vector elements you need to solve your applications? We currently have NEDELEC_ONE elements. Do you need Raviart-Thomas, etc.?

cticenhour commented 6 years ago

My application (edge plasma/heating antenna modeling for fusion plasma systems) is mostly concerned with electric field structures (where my boundary conditions concern themselves with fields tangential to surfaces/interfaces). So, my current weak form would be considered an H(curl) problem. Accordingly, most of the reading that I have done on vector elements in this subject so far leans heavily on first and second order Nedelec elements depending on the accuracy needed. I've even seen third order in practice, but mostly only as part of an error study, so I'm not sure how commonly that is used.

Since Raviart-Thomas elements seem to be used for H(div) problems (where you'd care about the continuity/definition of the normal field component in your boundary conditions), I'm not as concerned with them at the moment. However, any modeling concerned with magnetic fields would benefit. The fusion systems I care about use magnetic confinement, so the ability to use Raviart-Thomas could be useful in future.

roystgnr commented 6 years ago

We do have LAGRANGE_VEC, too! It's the perfect tool for debugging a code that will eventually require NEDELEC, or for if you want to write the same code but you don't want any of that nasty solution projection or hanging node constraint support...

More seriously:

Raviart-Thomas was my first thought, too.

On the other hand, even with the Nedelec elements, we only support the first kind, and we only support first-order! I'm afraid I'm unfamiliar with the pros and cons of the two Nedelec families, but I am familiar enough with p-refinement to suspect that p=1 is suboptimal for many of our users' problems.

pbauman commented 6 years ago

Yeah, I only needed first order when I coded up NEDELEC_ONE what is now forever ago. What would really be nice is to just do hierarchical Nedelec elements (ala Demkowicz's book) and be done with it. Similar statement for R-T.

roystgnr commented 6 years ago

I also strongly support the "hierarchical" suggestion, but didn't want to say so, since my motivation is "I still haven't coded up adaptive p refinement support for non-hierarchical elements and I would like to continue getting away with avoiding that." Presumably Dr. Demkowicz had more mathematical and less self-serving justification for such elements, though, so maybe they're really worth going with.

lindsayad commented 6 years ago

@pbauman @roystgnr Do you guys have a text you would recommend from which to implement RT?