dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

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... :-)

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.

> > 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.

--
Anders

Attachment: signature.asc
Description: Digital signature