dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

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

I'll be offline until tomorrow, but if someone wants to have a go
(including removal of the register stuff) just go ahead.

--
Anders

Attachment: signature.asc
Description: Digital signature