dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Mon, Nov 02, 2009 at 10:06:14AM -0500, Shawn Walker wrote:
>
> So, when you do
>
> mesh.refine()
>
> that automatically replaces the old mesh with the new one?  This
> seems ok. As long as the user still has the option of storing the
> old unrefined mesh and associated functions.
>
> How will functions be updated?  Just interpolation?  Is that easy to
> do if you use some non-standard elements, i.e. H(div), etc...  I
> guess the question is this:   Is there a unique way to update the
> functions?  If so, then this should be safe.  If not, then there
> might be headaches with this...

The default update procedure would be interpolation.

--
Anders


> - Shawn
>
> On Mon, 2 Nov 2009, Anders Logg wrote:
>
> >I've thought some more on the problem of mesh refinement and updating
> >of Functions.
> >
> >The main problem seems to be the following:
> >
> > mesh.refine()
> >
> >If we want to allow this, then we need to provide some kind of
> >automated updating of functions and function spaces to the new mesh,
> >since this call will otherwise destroy all function spaces and
> >functions that refer to that mesh:
> >
> > V = FunctionSpace(mesh, "CG", 1)
> > v = Function(V)
> > mesh.refine() # V and v no longer make any sense
> >
> >This gives us two options. Either we disallow refinement of a mesh
> >without making a copy. Or we provide automated updating. I think we
> >should do the latter.
> >
> >What is needed compared to what we have now is to let a call to
> >Mesh::refine trigger a call to FunctionSpace::update for all function
> >spaces defined on the mesh, which in turn will trigger calls to
> >Function::update for all functions defined on the function spaces.
> >
> >We can make the update functions private.
> >
> >Comments or objections? I think I can make this work.
> >

Attachment: signature.asc
Description: Digital signature