All,
I've attached a small patch that makes the init_*_shape_functions protected
in fe.h (it also makes init_base_shape_functions protected in the derived
class instead of protected in base and public in the derived - should I be
surprised the compiler didn't warn about that?). It seems to me that the
intent is for the user to use reinit anyway, so I don't think this should
be a big deal, but I could be wrong. I want to test the waters with the
simple change because bigger changes need to happen. The patch built and
ran the examples fine for me on a fresh co at r5748.
In order to implement H(div) and H(curl) conforming shape functions, I need
to have access to the physical->reference element map at the time of shape
function calculation. Currently, the shape functions are computed *before*
the physical->reference map is built. However, the shape functions and the
reference->physical map are both built in init_shape_functions. Thus, I
need to change the behavior of init_shape_functions (and the corresponding
boundary variants); in particular, among several other changes, move the
element map calculation into separate functions. That will be a much bigger
patch (and reinit will behave the same to the user), but this simple one
will make anyone who's directly using init_shape_functions scream as you'll
get a compiler error as opposed to a silent change in behavior of the
function.
If that plan can't work, then we need to start discussing alternatives.
Thanks,
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-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/libmesh-users
