dolfin team mailing list archive

[Johan Hake <hake@xxxxxxxxx>]

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 <logg@xxxxxxxxx>
> > > > date:        Fri Sep 25 23:56:04 2009 +0200
> > > > description:
> > > > merge
> > > >
> > > >
> > > > changeset:   7146:1d18d2b95462
> > > > parent:      7143:98d357740635
> > > > user:        Anders Logg <logg@xxxxxxxxx>
> > > > 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