← Back to team overview

dolfin team mailing list archive

  1. dolfin team
  2. Mailing list archive
  3. Message #16417

Re: [HG DOLFIN] First iteration of refinement of function spaces. Refinement of a function

  Thread Previous • Date Previous • • Thread Next 


Marie Rognes wrote:

Anders Logg wrote:

On Fri, Oct 30, 2009 at 10:20:31AM +0000, Garth N. Wells wrote:

Marie Rognes wrote:

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:   7408:f32a6ec49c47
tag:         tip
user:        Anders Logg <logg@xxxxxxxxx>
date:        Thu Oct 29 23:28:47 2009 +0100
files:       dolfin/fem/DofMap.cpp dolfin/fem/DofMap.h
dolfin/function/FunctionSpace.cpp dolfin/function/FunctionSpace.h
dolfin/mesh/Mesh.h
description:
First iteration of refinement of function spaces. Refinement of a
function
space should take care of refining the mesh, rebuilding the dofmap and
interpolating all its member functions to the new function space.

All essential bits should be in place but needs some debugging to
find memory errors/leaks.



This seems to be not working quite optimally yet.

1) The attached script fails with the error:


   python: dolfin/function/Function.cpp:392: virtual void
   dolfin::Function::compute_vertex_values(double*, const
   dolfin::Mesh&) const: Assertion `&mesh == &_function_space->mesh()'
   failed.
   Aborted


2) The original mesh does not seem to be refined. Shouldn't it be?

3) Not much seems to happen if f is an Expression (since not much seems
to happen with the mesh)

4) What happens when there are multiple function spaces associated with
one mesh?


I haven't looked at the code yet, but my first reaction to the commit
log is related to the above two points. I wonder if it's wise to make a
FunctionSpace aware of the Functions that depend on it. It makes
FunctionSpace more complicated and things could get very tricky in
parallel. Also, there is some freedom in how a Function is moved from
one mesh to another.

Would could define a new class, something like FunctionCollection (I
haven't given any thought to an appropriate name) which could collect
FunctionSpaces and GenericFunctions together for modification. It could
provide a default method for transferring a Function from one mesh to
another (say, interpolation), and a virtual interface for the user to
provide the transfer.

That seems like a complication. It would introduce a new abstraction
for what is essentially a function space.

Perhaps the simplest and clearest option is the following:

# Refine function space (W is a new space, not sharing any data)
W = V.refine()

# Transfer function from V to W
w = project(v, W) # or
w = interpolate(v, W)



I don't quite see the advantage of this approach:
There is already existing mesh refinement functionality. A new function space can be pretty easily constructed on a new (refined) mesh. But if a new function space is created, then any form defined on the previous space must probably be updated to the new space.
Isn't this a good thing? One may not wish to update all forms to the refined mesh. 


In particular, all basis functions either have to be
reinitialized (or somehow updated) and all the functions projected.

This can a bit of a pain.
This is why I thought it would be useful to have a structure which holds the forms and functions which one would like to update. It could take care of updating/projecting collections of forms and functions. 

Garth
I don't see the purpose of modifying the mesh-refinement-apparatus unless the 
modification actually alleviates a bit of that pain.

--
Marie





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

Follow ups

References

  Thread Previous • Date Previous • • Thread Next