dolfin team mailing list archive

[Marie Rognes <meg@xxxxxxxxx>]

On 17. sep. 2010 17:27, Johan Hake wrote:
> On Friday September 17 2010 08:22:56 Marie Rognes wrote:
>   
>> On 17. sep. 2010 17:15, Johan Hake wrote:
>>     
>>> On Friday September 17 2010 08:09:35 Marie Rognes wrote:
>>>       
>>>> On 17. sep. 2010 17:01, Johan Hake wrote:
>>>>         
>>>>> On Friday September 17 2010 00:04:02 Anders Logg wrote:
>>>>>           
>>>>>> Marie is making good progress on porting the automated adaptivity to
>>>>>> C++!
>>>>>>
>>>>>> The experimental branch of FFC is now generating auxiliary code for
>>>>>> error estimation and adaptivity.
>>>>>>             
>>>>> Cool!
>>>>>
>>>>>           
>>>>>>  (1) The ffc code generation is very, very ugly.
>>>>>>  (2) We are not yet computing facet residuals (Marie will fix, should
>>>>>>  be easy)
>>>>>>  (3) We are not  handling boundary conditions (Marie will fix, should
>>>>>>  be easy)
>>>>>>             
>>>>> Is this in place for the Python interface?
>>>>>           
>>>> Everything works for the Python interface (except refinement of mesh
>>>> functions).
>>>>         
>>> Aren't this handle automagically for meshfunctions attached to the
>>> MeshData?
>>>       
>> There is some functionality there -- but I don't think it is complete.
>>     
> Ok.
>
>   
>>>> No changes have been made since 0.9.8 (afair).
>>>>         
>>> Ok
>>>
>>>       
>>>> I'm planning on changing the python interface (into using the cpp
>>>> interface and not being a separate module) when the cpp interface is as
>>>> good as the python interface is now.
>>>>         
>>> Sounds nice!
>>>
>>>       
>>>>>>  (4) We should start discussing TrialFunctions.
>>>>>>  (5) Anders should start thinking about how to update to new meshes,
>>>>>>  so that actual adaptivity can happen.
>>>>>>             
>>>>> What are the problems you are facing here?
>>>>>           
>>>> The issue is the following: take a form 'a' defined on a function space
>>>> 'V' defined on a mesh 'mesh'.
>>>> Refine 'mesh' -> 'new_mesh'. Task: move 'a' to 'new_a' (defined on
>>>> new_mesh).
>>>>
>>>> The AdaptiveObjects design was intended for this some time ago -- but we
>>>> abandoned that (rather implicit and magical) approach. It would be good
>>>> however to add some explicit functionality of the form
>>>>
>>>>     new_a = update(a, new_mesh)
>>>>         
>>> Ok, I recal you guys having this discussion a while a go ;)
>>>       
>> It evidently made an impression ;)
>>     
> Oh yes ;)
>
>   
>> In the current python module, the updating is handled by actually
>> replacing (ufl.algorithms.replace) the old arguments and coefficients
>> with new arguments and coefficients. But that approach does not seem
>> feasible (or meaningful) without direct ufl access.
>>     
> , which isn't possible from the C++ interface (of course)?
>
>   

Exactly.

--
Marie