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. Garth > u.parameters["update_on_refine"] = False # default is True > > -- > Anders > > > ------------------------------------------------------------------------ > > _______________________________________________ > DOLFIN-dev mailing list > DOLFIN-dev@fenics.org > http://www.fenics.org/mailman/listinfo/dolfin-dev _______________________________________________ DOLFIN-dev mailing list DOLFIN-dev@fenics.org http://www.fenics.org/mailman/listinfo/dolfin-dev
