dolfin team mailing list archive

[Johan Hake <johan.hake@xxxxxxxxx>]

On Thursday October 21 2010 01:43:44 Marie Rognes wrote:
> On 21. okt. 2010 00:28, Johan Hake wrote:
> > On Wednesday October 20 2010 14:27:55 Marie Rognes wrote:
> >> On 20. okt. 2010 23:14, Johan Hake wrote:
> >>>>>> FFC will then generate "DOLFIN code" for the forms and finite
> >>>>>> elements involved in a, L and M, additional forms/finite element
> >>>>>> spaces, and a (sub-)class
> >>>>>> 
> >>>>>>     Ex1::ErrorControl : dolfin::ErrorControl
> >>>>>> 
> >>>>>> where dolfin::ErrorControl supplies the methods
> >>>>>> 
> >>>>>>     estimate_error(u)
> >>>>>>     compute_error_indicators(u)
> >>>>>> 
> >>>>>> The functionality of this class will take care of steps 2 and 3.
> >>>>>> 
> >>>>>> The main file can then look as follows:
> >>>>>> 
> >>>>>> main1.cpp:
> >>>>>>  #include "Ex1.h"
> >>>>>>  
> >>>>>>   ...
> >>>>>>   
> >>>>>>   Ex1::FunctionSpace V(mesh)
> >>>>>>   Ex1::BilinearForm a(V, V)
> >>>>>>   Ex1::LinearForm L(V);
> >>>>>>   
> >>>>>>   VariationalProblem(a, L, ...);
> >>>>>>   
> >>>>>>   Function u(V);
> >>>>>>   Ex1::GoalFunctional M(V);
> >>>>>>   pde.solve(u, tol, M);
> >>>>>> 
> >>>>>> Marie thinks this looks pretty clean and knows that it is doable
> >>>>>> (there is a (more or less) working prototype in the launchpad
> >>>>>> branches dolfin-error-control/ffc-error-control). (The error
> >>>>>> control class/object can attached to the GoalFunctional and hence
> >>>>>> available for the VariationalProblem.)
> >>> 
> >>> Is this guy
> >>> generated for you by UFL and FFC, or is the one in
> >>> 
> >>>   dolfin/adaptivity/ErrorControl .h
> >>> 
> >>> always used in your prefered example.
> >> 
> >> FFC will generate (and the ffc/error-control branch does) a sub-class of
> >> this guy adapted to a given VariationalProblem F (or a/L) and a given
> >> goal M. (Same design as for Forms and FunctionSpaces.)
> > 
> > Ok, but in your prefered example you just instantiate the GoalFunctional.
> > Where is the subclassed ErrorControl guy, or is the GoalFunctional him in
> > disguise?
> 
> The GoalFunctional has a member
> 
>      boost::scoped_ptr<ErrorControl> ec;
> 
> cf.
> 
>     /dolfin/adaptivity/GoalFunctional.h
> 
> The sub-classed GoalFunctional (Ex1::GoalFunctional) is be responsible
> for instantiating (and updating) the "right" sub-classed ErrorControl.
> At least, this is the current setup.

From a user perspective I think this is good. The user provides the 
GoalFunctional, which is what she should care about.

  1) What if a user does not provide any goal functional, will a default be
     provided?

  2) Will it be possible to declare several goal functionals in one form?

> >>>> Anders and I have been through (but rejected) a couple of other ideas,
> >>>> including
> >>>> 
> >>>> (1) Making TrialFunction a special sub-class of Function instead of of
> >>>> Argument
> >>>> 
> >>>>     (Very sensible, consistentifies linear and nonlinear, but way
> >>>>     radical)
> >>> 
> >>> What would a functional of u then be?
> >>> 
> >>>   u = TrialFunction(V)
> >>>   f = assemble(u*dx) ?
> >> 
> >> Maybe.
> > 
> > Which means?
> 
> Means that I haven't thought it fully through and do not really plan to ;)

:)

> >>>> (2) Introducing an additional sub-class Unknown of Function, thus
> >>>> identifying the unknown
> >>>> 
> >>>>     (Looks a bit weird, does not increase consistency with linear
> >>>> 
> >>>> problems.)
> >>> 
> >>> I think this could work. The point with a linear problem is that the
> >>> problem can be described without the Unknown (=> Linear). Which means
> >>> that a linear problem wont have an Unknown.
> >> 
> >> Yes, but linear problems have a TrialFunction which plays the same role.
> > 
> > But isn't a TrialFunction only meaningfull in a bilinear form?
> 
> No.

Ok.

Johan