All,
I got a little carried away and put together a patch to create an FEMap
class in order to encapsulate (to some degree... more on that later) the
reference->physical and physical->reference element maps. The primary
impetus for this is to more easily facilitate a (forthcoming...)
ElementTransformation class to properly map shape functions for H1, HCurl,
HDiv, and L2 conforming elements. I'm soliciting feedback. The patch is a
bit large so I'll try and summarize. You can find the patch here:
http://users.ices.utexas.edu/~pbauman/fe_map.patch
1. There is a now an FEMap class. phi_map and it's brethren have been moved
to this class. FEAbstract contains an AutoPtr to the FEMap object. The
FEMap object is made available outside FEAbstract only through a const
FEMap& accessor. The FEMap object has a static build() method that gets
called in the FEAbstract constructor.
2. All FEMap related methods have been moved to the FEMap class, with the
exception of inverse_map, map, map_dxi, etc. Those methods were static and
I wanted to discuss them before they get made non-static and possibly
virtual (InfFE has an alternate version of inverse_map for example). Only
one of the methods in FEMap got made virtual that was not already
(compute_face_map - there is a derived FEXYZMap class that reimplements
this).
3. The FE level interface has been entirely preserved so backwards
compatibility is maintained.
4. The initialization of the mapping functions has been separated from the
initialization of the shape functions. This is, again, preparing for the
needs of a forth coming ElementTransformation class. This new method
is init_reference_to_physical_map. Adding this call to reinit is the only
change to reinit at this point. The order of the map computation will
change in a subsequent patch, once we sort this one out.
I think this is a half-decent start on what this should look like. I
haven't tried very hard to be general and anticipate what Roy wants for
NURBS based representations of the reference to physical map. However, I
could at least be talked into writing an abstract base class from which the
current FEMap class would derive (I would propose to rename it LagrangeMap)
to facilitate such an interface. I didn't want to go down that road without
some discussion of what we can let go virtual and what not.
There is at least an example of subclassing the Lagrange map (FEXYZMap),
but there really should another - InfFE. This is the one thing that really
irks me about the current state of this patch, but I don't have time to
study InfFE in depth and do something about it. In summary, there are
"radial" functions in addition to the phi_map functions, so there should be
an InfFEMap class that encapsulates that bit and handles initializing them,
etc. However, I haven't done that here. What's currently done is breaking
encapsulation of FEMap and letting InfFE do what it needs to do. I've put
comments in the FEMap header to indicate the functions that need non-const
references to phi_map and its cousins. Although I'm not happy about that,
we at least don't break encapsulation outside of the FE objects because the
user will only have access to a const reference.
Along those lines, there's also a non-const accessor for JxW needed by the
side reinit functions. Again, I didn't pursue looking into the algorithm to
see if it could be avoided, but I've at least put comments in the code
explaining where the accessor is needed.
On the whole, despite some of the encapsulation issues for FEMap, I think
this will make the code for ElementTransformation (or whatever...) much
cleaner and reduces the bloat (and future bloat...) of the FE objects. What
do y'all think?
Thanks for the time.
Best,
Paul
------------------------------------------------------------------------------
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
