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