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 <l...@simula.no> >>>> 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. 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. 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@fenics.org http://www.fenics.org/mailman/listinfo/dolfin-dev
