Anders Logg wrote: > On Mon, Nov 02, 2009 at 04:31:10PM +0100, Jed Brown wrote: >> Anders Logg wrote: >> >>> The default update procedure would be interpolation. >> Which interpolation? Perhaps the user needs it to be conservative or >> preserve some other structure. What if they want to use different >> schemes for different functions on that mesh? > > The standard interpolation defined by the finite element space. So for > example nodal evaluation for Lagrange elements.
This is the natural choice, but it wasn't really a serious question; I think it is important that the granularity be finer (so you can apply different schemes to different functions defined on a mesh). >> You can't implement refinement in-place anyway. Providing an interface >> that looks in-place just means that users have to rewrite larger pieces >> of their code when they need more control. I would suggest that >> refinement produces a new mesh and then provide methods to transfer >> functions and solver objects to the new mesh. > > Perhaps, but it could require quite a bit of work (from the user) to > keep track of which objects should be transferred: function spaces, > functions, forms. It is important that the interface allows the user to be involved. Transfering a high-level object like a nonlinear solver would transfer everything it has a reference to, which means most users would have something more like new_mesh = mesh.refine new_V = FunctionSpace(new_mesh, V.spec()) new_solver = transfer(solver, new_V, interpolation='Conservative') new_f = transfer(other_function, new_V, interpolation='Galerkin') A further issue with in-place updates is that linear algebra objects need to be destroyed and recreated because they can't be changed in-place. This is troublesome when the user holds a reference to any of these. Jed
signature.asc
Description: OpenPGP digital signature
_______________________________________________ DOLFIN-dev mailing list DOLFIN-dev@fenics.org http://www.fenics.org/mailman/listinfo/dolfin-dev
