Garth N. Wells wrote: > > > 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. >
Yes, that is probably a good thing :) >> 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. > Something like: mesh = ... form = ... something on old mesh ... new_mesh = mesh.refine() new_form = update(form, new_mesh) ? -- Marie > 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