← Back to team overview

dolfin team mailing list archive

Re: Mesh refinement and Functions

 



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?

No.

If so,
then this should be safe. If not, then there might be headaches with this...


We could provide a default, but make the relevant functions virtual so that a user can provide their own update method.

Garth

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

--
Anders

_______________________________________________
DOLFIN-dev mailing list
DOLFIN-dev@xxxxxxxxxx
http://www.fenics.org/mailman/listinfo/dolfin-dev



References