I've been talking about this with John for a while... it's something that
really needed to be done. Thanks for taking a first swipe at it!
We'll look it over this week and get back to you with any feedback.
Derek
On Sat, Jul 14, 2012 at 2:23 AM, Paul T. Bauman <ptbau...@gmail.com> wrote:
> 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
>
>
------------------------------------------------------------------------------
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
