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.
signature.asc
Description: Digital signature
_______________________________________________ DOLFIN-dev mailing list [email protected] http://www.fenics.org/mailman/listinfo/dolfin-dev
