dolfin team mailing list archive

[Johan Hake <johan.hake@xxxxxxxxx>]

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)?

Johan