On Saturday 26 September 2009 23:19:23 Anders Logg wrote: > On Sat, Sep 26, 2009 at 04:16:49PM +0200, Johan Hake wrote: > > On Saturday 26 September 2009 00:07:46 Anders Logg wrote: > > > On Fri, Sep 25, 2009 at 11:56:03PM +0200, DOLFIN wrote: > > > > One or more new changesets pushed to the primary dolfin repository. > > > > A short summary of the last three changesets is included below. > > > > > > > > changeset: 7147:2f99c8fb3a96 > > > > tag: tip > > > > parent: 7146:1d18d2b95462 > > > > parent: 7145:3f905e727c11 > > > > user: Anders Logg <[email protected]> > > > > date: Fri Sep 25 23:56:04 2009 +0200 > > > > description: > > > > merge > > > > > > > > > > > > changeset: 7146:1d18d2b95462 > > > > parent: 7143:98d357740635 > > > > user: Anders Logg <[email protected]> > > > > date: Fri Sep 25 23:55:55 2009 +0200 > > > > files: dolfin/fem/DofMap.cpp dolfin/fem/DofMap.h > > > > dolfin/function/FunctionSpace.cpp dolfin/function/FunctionSpace.h > > > > description: > > > > Add update() function to FunctionSpace and DofMap for use in adaptive > > > > mesh refinement. > > > > > > I've added a first iteration of a functionality we need to do > > > adaptivity. When a mesh is refined, we can't reassemble the forms > > > since the FunctionSpace does not know the mesh has changed. > > > > > > It is now possible to update the FunctionSpace (actually the DofMap) > > > by calling FunctionSpace::update. > > > > > > Example: > > > >>> from dolfin import * > > > >>> mesh = UnitSquare(3, 3) > > > >>> V = FunctionSpace(mesh, "CG", 3) > > > >>> print V.dim() > > > > > > 100 > > > > > > >>> mesh.refine() > > > > > > No cells marked for refinement, assuming uniform mesh refinement. > > > > > > >>> print V.dim() > > > > > > 100 > > > > > > >>> V.update() > > > >>> print V.dim() > > > > > > 361 > > > > > > I'm not sure what the right way to handle this is. Perhaps we should > > > have FunctionSpace::refine which calls refine on the mesh and then > > > calls update. > > > > This will then only work for one FunctionSpace. Other FunctionSpaces > > defined on the same Mesh would not be updated. > > > > Would it be possible to store all FunctionSpaces associated with a Mesh > > in a > > > > vector<FunctionSpace*> > > > > in the Mesh? Then let Mesh::refine iterate over the FunctionSpaces and > > call the FunctionSpace::update. > > > > This could be handle by adding something like: > > > > mesh->register(*this); > > > > in the constructor of FunctionSpace and > > > > mesh->deregister(*this); > > > > in the destructor of FunctionSpace. > > That could be an option. There might be some issues with constness etc > and we've made mistakes before when trying to be clever, but we could > try... :-)
What is the policy of constness for the Mesh class. I see that there exists a const and a non-const constructor in for example the FunctionSpace and DofMap. It is not explicit for me when I construct a FunctionSpace using a const Mesh and when I am not. > We would then need to have > > mesh::refine > --> FunctionSpace::update > --> DofMap::update > --> Function::interpolate etc for all functions > > So a FunctionSpace would also need to have some functionality for > registering Functions. Yes. We also have the problem of updating MeshFunctions. I understand that there is a mechanism for updating MeshFunctions that resides in the MeshData? I guess it would just create a lot of spaghetti code to add some automatic update for any arbitrary MeshFunction over a particular Mesh. > > > Then there's also the question about what to do with all the Functions > > > on the space that we update/refine. They no longer make any sense on > > > the new mesh. An option would be for a FunctionSpace to store a list > > > of all Functions in the space and automatically project/interpolate > > > them to the refined space when we call FunctionSpace::refine. > > > > This would be nice. But is it possible? Do we not need both meshes to > > interpolate between them? > > Yes, we would so the above would need to be more complicated. We could > have the mesh store a copy of itself before refining. Or we could > store the whole hierarchy of meshes when refining. We have had this > before. If I remember correctly, a Mesh used to store a pointer to a > MeshHierarchy so that one could do mesh.parent(), mesh.child() etc. > We could also have MeshFunctions in the data section of a Mesh that > stored parents of vertices etc to speed up interpolation between > meshes. Ok. Johan _______________________________________________ DOLFIN-dev mailing list [email protected] http://www.fenics.org/mailman/listinfo/dolfin-dev
