On Wed, 19 Sep 2012, Paul T. Bauman wrote: > Is there any reason DifferentiableQoI::postprocess() is pure > virtual? For the case where the user relies on DiffSystem as > inherited from DifferentiableQoI, the method gets overridden in > FEMSystem anyway. For the attached DifferentiableQoI case, the > method never actually gets called within the system AFAICT. Am I > missing something? Since I can grab the stored qoi when it's > assembled, I don't see the need for having to implement > postprocess() for the attached DifferentiableQoI case. > Thanks,
I'm actually not sure what I was thinking. I wanted to pull all the QoI-type functions out of DiffSystem... but honestly, postprocess() ought to be deprecated with implementation discouraged, not pure virtual with implementation required. It predates the QoI methods and its intended use can only be described as "calculate QoIs, but don't bother giving the library access to them so you can't do as many interesting things with them". I'd be fine stripping the postprocess() methods out of DifferentiableQoI entirely (restoring them to DiffSystem as necessary for backwards compatibility) then sticking a libmesh_deprecated() default implementation on the postprocess() methods in DiffSystem. --- 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
