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 Libmesh-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-devel
