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
