dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Mon, Nov 02, 2009 at 06:17:41PM +0000, Garth N. Wells wrote:
>
>
> Anders Logg wrote:
> > On Mon, Nov 02, 2009 at 03:06:04PM +0000, Garth N. Wells wrote:
> >>
> >> Marie Rognes wrote:
> >>> 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.
> >>>>
> >>>>
> >>> I think that I would appreciate both:
> >>>
> >>> (a) Automated updating if mesh.refine()
> >>>
> >>> and
> >>>
> >>> (b) Functionality provided for updating functions to a new mesh if mesh
> >>> = refine(mesh)
> >>>
> >> Agree.
> >>
> >>>> 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.
> >>>>
> >>>>
> >>> I can imagine that one would like to keep a copy of a function on the
> >>> old mesh if
> >>> one compares solutions from different meshes. Then automated updating could
> >>> be somewhat suboptimal.
> >>>
> >> It's essential that one can allow some functions to remain defined on
> >> one mesh while others are updated to the new mesh.
> >
> > What about if we add some kind of functionality for marking what
> > should happen to a function when a mesh is refined?
> >
> > It can either be interpolated to the new function space, or remain on
> > the old function space.
> >
> > Then one can safely do mesh.refine() and some functions will be
> > updated and some will safely remain on the old mesh. Note that when a
> > function remains on the old mesh, that function will itself keep a
> > shared pointer to a copy of the old mesh (which needs to be shared
> > with other functions remaining on the old mesh).
> >
> > What should the mechanism be for marking which functions should be
> > updated and which should not? Should it just be a parameter?
> >
>
> This sounds like it's along the lines of my original suggestion to
> create an object with which Functions can be registered and which then
> takes care of the update. An advantage of this is that it could also do
> some reference counting via the smart pointers to figure out whether or
> not an object needs to be copied and whether or not other things may go
> wrong.

Yes, it might be a good idea to have a separate class take care of
this, but I also figure that I can make it happen automatically as
part of mesh.refine(), using that separate class.

I'll try some things out and see what I come up with.

Attachment: signature.asc
Description: Digital signature