dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Fri, Oct 03, 2008 at 11:06:46PM +0100, Garth N. Wells wrote:
> 
> 
> Anders Logg wrote:
> > User-defined functions are currently defined by overloading eval().
> > The eval() function is available in two different versions, for vectors
> > (tensors) and scalars:
> > 
> >   void eval(double* values, const double* x) const;
> > 
> >   double eval(const double* x) const;
> > 
> > This might be ok, but functions may also depend on the current cell,
> > the current facet, and perhaps on the current time and other data.
> > These are accessible by this->cell, this->facet.
> > 
> > So, a function depends on x and other things and it's not obvious what
> > additional data a function does depend on. Are there any suggestions
> > for what the interface should look like for user-defined functions?
> > 
> > One option could be to let functions be defined by expressions
> > (function pointers) given to the constructor of Function. That way,
> > one could define a function by
> > 
> >   void source(const double* x) { sin(x[0]); }
> > 
> >   f = Function(mesh, source);
> > 
> > This way, there could be many different types of function pointers,
> > all taking a different number of arguments, and we could differentiate
> > between the different types.
> >
> 
> I'm not a fan of function pointers, and I don't see how the above 
> solution would help if a Function depends on other data.

It would help to do things like

  double foo(const double* x) { return sin(x[0]); }
  double bar(const double* x, real t) { return t*sin(x[0]); }

  f = Function(foo);
  g = Function(bar);  

I'm not saying I want to do this, just wondering if it's a good
option.

> Constructing a class for a user-defined function is more verbose, but 
> for complicated problems we've found it quite useful to create classes 
> which are sub-classes of both Function and SubDomains so the boundary 
> and the boundary condition are defined in the same class. For 
> time-dependent problems, we let the class own a reference to the current 
> time.
> 
> Garth

Isn't it enough to inherit also from TimeDependent?

-- 
Anders

Attachment: signature.asc
Description: Digital signature