dolfin team mailing list archive

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

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.

--
Martin