dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Thu, Jun 12, 2008 at 10:55:20PM +0200, Martin Sandve Alnæs wrote:
> 2008/6/12 Anders Logg <logg@xxxxxxxxx>:
> > On Thu, Jun 12, 2008 at 09:38:43PM +0200, Martin Sandve Alnæs wrote:
> >> 2008/6/12 Anders Logg <logg@xxxxxxxxx>:
> >> > On Tue, Jun 10, 2008 at 05:08:57PM +0200, Martin Sandve Alnæs wrote:
> >> >> 2008/6/10 Anders Logg <logg@xxxxxxxxx>:
> >> >> > On Tue, Jun 10, 2008 at 04:41:25PM +0200, Martin Sandve Alnæs wrote:
> >> >> >> Maybe this design works?
> >> >> >>
> >> >> >> x is coordinates, c is cell info
> >> >> >>
> >> >> >> class Function
> >> >> >> {
> >> >> >>   virtual void eval(v, x, c) { eval(v, x); }
> >> >> >>   virtual void eval(v, x) { dolfin_error("Missing implementation of eval."); }
> >> >> >> };
> >> >> >>
> >> >> >> class A: Function
> >> >> >> {
> >> >> >>   void eval(v, x) { do_my_thing; }
> >> >> >> };
> >> >> >>
> >> >> >> class B: Function
> >> >> >> {
> >> >> >>   void eval(v, x, c) { do_my_thing; }
> >> >> >> };
> >> >> >>
> >> >> >> The assembler always call eval(v,x,c), the user overloads the one
> >> >> >> he wants. There are already lots of redirecting back and forth in
> >> >> >> the Function hierarchy, so the overhead shouldn't become larger.
> >> >> >> If a user-function that depends on cell info is called in a context
> >> >> >> without cell info, i.e. eval(v,x) is called, this triggers an error.
> >> >> >>
> >> >> >> Inheritance in Python is probably a problem here (SWIG issues).
> >> >> >> Alternatively, name them eval(v,x) and eval_cell(v,x,c) or something
> >> >> >> to solve that problem.
> >> >> >
> >> >> > Good, but it becomes a bit messy if we also want to include the other
> >> >> > hidden arguments (see protected section of Function):
> >> >> >
> >> >> >  /// Access current facet normal (available during assembly for user-defined function)
> >> >> >  Point normal() const;
> >> >> >
> >> >> >  /// Access current facet (available during assembly for user-defined functions)
> >> >> >  int facet() const;
> >> >>
> >> >> We could pack all geometry data in one argument.
> >> >> Or have a separate eval_facet which takes these arguments.
> >> >
> >> > I think we should have eval_facet. But how do we pack geometry in one
> >> > argument in C++? We might want the cell, the subdomain, the current
> >> > time, and possibly other things.
> >>
> >> How? A class/struct. Which basically amounts to the same thing as
> >> having multiple arguments.
> >>
> >> Maybe a FacetCell which holds its parent cell, the normal, and facet number?
> >
> > If we add eval_facet, then it should be ok to add the additional
> > arguments. The function is different from eval_facet so it's ok
> > to have different arguments.
> 
> Ok.

Let's fix this when we review the Function classes, which I guess we
should do soon.

-- 
Anders

Attachment: signature.asc
Description: Digital signature