Re: [Libmesh-devel] Vector-valued FE

[Kirk, B. (JSC-EG311) <ben...@na...>]

I always cache a reference to the shape function vectors I need outside the element loop so in this case I can't imagine there is a difference between an inline and virtual function call. 

-Ben


On May 10, 2012, at 5:37 PM, "Roy Stogner" <roy...@ic...> wrote:

> 
> Paul Bauman has an application that's motivating him to put
> vector-valued FE capabilities into libMesh, and I've got a
> shame-this-wasnt-done-years-ago that's motivating me to help, so we're
> hashing out design ideas now.
> 
> Two design decisions that've come up, submitted for general commentary:
> 
> 
> 1.:  For vector-valued data, it would be good to return shape values as
> a vector-of-vector-of-Gradients instead of
> vector-of-vector-of-Numbers, and shape derivatives would be a
> vector-of-vector-of-Tensors.  (we'll probably postpone second
> derivative support and add a Rank3Tensor class or some such for it).
> 
> All agreed?  The alternative (returning
> vector-of-vector-of-vector-of-Numbers, etc) would be much uglier for
> user code.
> 
> 
> The catch with this is that the current FEBase already stores
> vector-of-vector-of-Numbers.  And returns it, directly, via inline
> get_phi().
> 
> 
> So, 2.:  Do we create FEAbstract, which doesn't include *phi* data or
> get_*phi* methods, then derive FEBase and FEVectorBase from it?  Or do
> we just add get_vec_*phi* methods (and vec_*phi data) to FEBase?
> 
> With the latter option, we'd have a bunch of redundant (albeit empty)
> vectors in every FEBase, and trying to access scalar data from a
> vector element type or vice-versa would be a runtime error (or
> possibly only an assert), not very type safe.
> 
> With the former option, we'd end up having to turn get_*phi* from
> inline functions into virtual functions.  This is what we're leaning
> towards.  The cost of a virtual function is relatively trivial when
> amortized.  I benchmark a few percent overhead when compared to even
> dead simple bilinear-fe linear residual-type loops, a few thousandths
> of a percent overhead when compared to biquadratic slightly nonlinear
> jacobian-type loops.
> 
> The cost of preventing crazy optimizations can be huge: in the inlined
> case icpc originally detected that my fakey benchmark couldn't be
> changing phi in-between get_phi calls, reordered my loops to make the
> element loop the inner loop, then vectorized and combined my equations
> to chop out 90% of the FLOPs... but even a slight added code
> complication (a do-nothing but non-const method called on the fake FE
> object) took things back to normal; I can't imagine anything similar
> affecting a real code where we call FE::reinit on every element.
> ---
> 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
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libmesh-devel