dolfin team mailing list archive

["Garth N. Wells" <gnw20@xxxxxxxxx>]

Anders Logg wrote:
> On Fri, Oct 30, 2009 at 12:14:53PM +0100, 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.

I prefer two simple abstractions to one complicated one ;).

> > 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)
> >
> > This should avoid any confusion and the transfer of functions from one
> > space to the other is explicit. It's also possiblet to keep the old
> > functions lying around if that's needed.
> >
> > If it's not needed, then one can do
> >
> > V = V.refine()
> > v = project(v, V)
>
> After thinking some more on this, this seems to be the right way to do
> it. Less magic, just as easy to use and more flexible.

Agree.

Garth

> I'll be offline until tomorrow, but if someone wants to have a go
> (including removal of the register stuff) just go ahead.
>
> --
> Anders
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> DOLFIN-dev mailing list
> DOLFIN-dev@xxxxxxxxxx
> http://www.fenics.org/mailman/listinfo/dolfin-dev