All,
I've constructed a patch which abstracts the construction of the shape
functions in the physical domain (assuming their initialization in the
reference domain). The patch can be found here:
http://users.ices.utexas.edu/~pbauman/fe_trans.patch
The main idea is an FETransformationBase object gets constructed based on
the FEType. Then, compute_shape_functions calls this object to compute phi,
dphi, etc. All compute methods are pure virtual and have to be implemented
in each derived class. I've only implemented the H1 variety at the moment
(and only the existing functionality, curl and div still need to be done,
but we still need to add the data structures for that); HCurl will be
coming next (inside my nedelec_one patch once I get a working example).
Despite what I said in this thread
http://sourceforge.net/mailarchive/forum.php?thread_name=CC2B38D0.23735%25benjamin.kirk%40nasa.gov&forum_name=libmesh-devel,
this actually didn't require FEMap nor require changing the algorithm
in
reinit (not sure what I was smoking there). However, I'd still prefer to
get an FEMap object to pull out the mapping functions once the FEMap patch
goes in.
At any rate, any objections to this? Comments? Suggestions? I'll wait for
someone to comment before I commit. All tests are passing for me in dbg and
opt modes. The patch was made against r5863.
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
