On Thu, Jun 21, 2012 at 10:06 PM, Paul T. Bauman <ptbau...@gmail.com> wrote:
> > For interior_value, etc., the plan is to add (replace? If we're breaking > compatibility anyway, why have duplicate code sitting around?) templated > versions, e.g. > > template<typename FieldType> > void FEMContext::interior_value( unsigned int var, unsigned int qp, > FieldType& value ) > > If we're going to be going down the road of breaking backward > compatibility and adding accessor methods, what about protecting > elem_solution, elem_residual, etc.? > > I'd like to start on this right away, so my plan is to add the necessary > protected element_fe data structures and populate it with FEAbstract* and > still populate the public data structures (for the time being) to shake > things out while we hash out plans here. > Attached is a patch that has started along this road. There are now FE accessor methods, protected FEAbstract* data structures for FE types, a couple of template methods, and a working vector_fe_ex2 using FEMSystem on the uncoupled Laplace example from vector_fe_ex1. Roy mentioned briefly today that he would be in favor of me going accessor happy. What's the plan for backward compatiblity then? Or rather how long do we want to hold on to it? Any comments/thoughts? Thanks, Paul
femcontext.patch
Description: Binary data
------------------------------------------------------------------------------ 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
