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 <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.
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@fenics.org > http://www.fenics.org/mailman/listinfo/dolfin-dev _______________________________________________ DOLFIN-dev mailing list DOLFIN-dev@fenics.org http://www.fenics.org/mailman/listinfo/dolfin-dev