← Back to team overview

dolfin team mailing list archive

Re: Interface for variational problems with goal-oriented error control/adaptivity:

 

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.


>
>>>
>>>> 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.

--
Marie



Follow ups

References