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