dolfin team mailing list archive

["Martin Sandve Alnæs" <martinal@xxxxxxxxx>]

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.

>> The current time doesn't vary during assembly, we can leave that to the user.
>> Same with subdomain and meshfunction data: the function can look up this
>> itself if it knows which cell it is currently being evaluated in.
>
> That would be good (if the only extra argument we ever need to send to
> eval is the cell).

Johan did this today, with compiled C++-functions from python,
simply adding a member "dolfin::Function * f;" to the C++ class code,
setting it from python like "myfunc.f = g", and using it in eval (C++)
by looking up cell().

--
Martin