It just occurred to me that any future discussion on this topic would
be more appropriate on libmesh-devel than in private email. Probably
nobody other than Vikram and I will care right now, but there's no
need to actively *enforce* that.
The context is that, for some algorithms (Vikram's trying to improve a
goal-oriented error indicator via a physics-based error functional),
user code may want to specify a function which is dependent not only
on space and time but also on solution variables. Our current idea
for handing such a function to generic code is a "FEMFunctionBase" -
an abstract base class functor like FunctionBase, but one which takes
an initialized FEMContext as input as well as a Point and a time.
---
Roy
---------- Forwarded message ----------
Date: Wed, 4 Apr 2012 11:35:38 -0500 (CDT)
From: Roy Stogner <royst...@ices.utexas.edu>
To: Vikram Garg <vikram.v.g...@gmail.com>
Subject: Re: Questions about FEMFunctionBase
On Wed, 4 Apr 2012, Vikram Garg wrote:
So here's my step by step procedure to get the weighted adjoint residual
estimator implemented.
1) Create an FEMFunctionBase class that contains only the constructor,
destructor and an operator function. The user will define a derived
UserFEMFunctionBase class that will overload the operator function, which
will compute the weights for a specific var index, FEMContext and Point.
UserFEMFunction (it's no longer Base, it's derived), but yes.
I would suggest having the var index be a member variable rather than
an input parameter to operator().
2) Create a WeightedPatchRecoveryErrorEstimator Class that derives from
PatchRecoveryErrorEstimator. Add a new variable, a vector of function
pointers. This vector will be filled by the user with pointers to functions
that compute the weights for each variable.
Right. We might instead consider moving this vector to SystemNorm;
it's kind of inelegant either way.
Also declare an object of type FEMFunctionBase in the EstimateError
function of WPREE which will be able to call on these function
pointers when the weights need to be calculated.
Probably no need. PREE::EE has a PREE& reference; WPREE::EE will have
a WPREE& reference and can get at the FEMFunctionBase vector from
that.
3) The user will create a set of function pointers and pass these to
the vector of function pointers of WPREE.
Functor pointers, but yes. The user code creates a bunch of functors,
then fills the vector with pointers to them.
I dont know much about function pointers, so will probably need help
with those.
Can do. You might grep through the library for FunctionBase to see
how we're currently using functors... except that might be overly
complicated because of the vector output in most of those cases. In
the scalar operator() output case, the only tricky bit of syntax is
the actual call through a pointer, which ends up looking like
"(*f)(p,time)".
Also, can I declare an object of class FEMFunctionBase ?
It does have a constructor, so it should be fine. But I read
somewhere that one cant declare objects of an abstract class type.
What you read is correct. You'll declare objects of class
MicrofluidicFEMFunction (or whatever), and then their pointers will be
implicitly cast from MicrofluidicFEMFunction* to FEMFunctionBase*.
---
Roy
------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________
Libmesh-devel mailing list
Libmesh-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-devel
