dolfin team mailing list archive

["Garth N. Wells" <gnw20@xxxxxxxxx>]

Anders Logg wrote:
> On Mon, Feb 15, 2010 at 12:46:58PM +0100, Andre Massing wrote:
>>
>> Garth N. Wells wrote:
>>> Anders Logg wrote:
>>>> On Mon, Feb 15, 2010 at 11:39:26AM +0100, Marie Rognes wrote:
>>>>> Garth N. Wells wrote:
>>>>>> Anders Logg wrote:
>>>>>>> On Fri, Feb 12, 2010 at 05:42:26PM +0000, Garth N. Wells wrote:
>>>>>>>> Anders Logg wrote:
>>>>>>>>> On Fri, Feb 12, 2010 at 04:57:05PM +0100, Anders Logg wrote:
>>>>>>>>>> On Fri, Feb 12, 2010 at 04:23:51PM +0100, Marie Rognes wrote:
>>>>>>>>>>> I'm interesting in accessing the vector of a Function after mesh-refinement.
>>>>>>>>>>> At the moment, I'm getting:
>>>>>>>>>>>
>>>>>>>>>>>  RuntimeError: *** Error: You are attempting to access a non-const
>>>>>>>>>>>  vector from a sub-Function.
>>>>>>>>>>>
>>>>>>>>>>> Is this inevitable, a bug or a trigger-happy error message?
>>>>>>>>>>>
>>>>>>>>>>>  from dolfin import *
>>>>>>>>>>>  mesh = UnitSquare(2,2)
>>>>>>>>>>>  V = FunctionSpace(mesh, "CG", 1)
>>>>>>>>>>>  u = Function(V)
>>>>>>>>>>>  mesh.refine()
>>>>>>>>>>>  u.vector()
>>>>>>>>>> Looks like a bug. The function is not being refined but the mesh, the
>>>>>>>>>> dofmap and the functionspace is refined. Might be related to the
>>>>>>>>>> recent work on refinement.
>>>>>>>>> It should be fixed now. Someone had commented out register_object in
>>>>>>>>> the Function constructor.
>>>>>>>> I'm not too keen on all this magic. Harish I and have an adaptive solver
>>>>>>>> in which the function spaces are declared inside a loop and it's slowly
>>>>>>>> leaking memory, but I can't figure out why. 'Magic' makes it really hard
>>>>>>>> to figure out what's going on.
>>>>>>> That's unfortunate. But the magic is necessary if we should allow
>>>>>>> meshes to be refined. The other option would be to remove
>>>>>>> mesh.refine() and always rely on
>>>>>>>
>>>>>>> new_mesh = refine(mesh)
>>>>>>>
>>>>>>> And then explicitly create the new function spaces and project the
>>>>>>> functions.
>>>>>>>
>>>>>> This is what we're doing.
>>>>>>
>>>>>> Garth
>>>>>>
>>>>>>
>>>>>>> I'm not sure which implications that would have fore Marie's code.
>>>>>>> Marie?
>>>>>>>
>>>>> I'm pretty keen on the magic, but can survive without it.
>>>> I also like the magic, but AdaptiveObjects.cpp is complex and fragile
>>>> so it would be good to remove it.
>>>>
>>> What about a free-function or a like 'adapt', or a class with static
>>> member functions, that takes multiple arguments? It could be passed a
>>> MeshFunction of cells to refine/coarsen, and from the Python side you
>>> could even pass the function with which you want to adapt the mesh.
> 
> Yes, that might be good. It then also needs to handle updating of
> forms. Marie just reminded me of another reason for having
> AdaptiveObjects which is that forms defined on some function space
> will continue to work when the mesh is refined. Otherwise, they need
> to be updated manually or redefined on the new function space.
> 
>>> We could also keep AdaptiveObjects, but have users register functions
>>> manually.
> 
> I don't think that's a good idea. Either we keep mesh.refine() and
> AdaptiveObjects or remove both. 

There no problem if AdaptiveObjects is explicit in what it does. For
example, if it creates a new mesh and associates that with explicitly
provided functions or function spaces.

The important point is that one should
> not be able to refine a mesh if other objects depend on it and will
> break when the mesh is refined.
> 

I agree that Mesh::refine should be removed. The only case for a
function like it is if mesh refinement can be done in-place.

Garth

>>> Garth
>> Just another quick thought. What about using the signal/slot technology
>> provided by boost:
>>
>> http://www.boost.org/doc/libs/1_42_0/doc/html/signals.html
>>
>> At least experience with the corresponding QT signal/slot technology
>> shows that it really facilitates the implementation of observer
>> patterns (which we probably want to use here?) That way we don't
>> have to use the "one class cares for all dependencies" approach,
>> instead a member function refine in the mesh class could send put a
>> signal, and each object, which has a slot coupled to that signal,
>> could react in the class specific manner.
>>
>> That might help to reduce the complexity and the class interactions
>> as minimal as possible. But I had just a quick look in the
>> AdaptiveObjects class and not aware of all the dirty details :)
> 
> The good thing about AdaptiveObjects.cpp is that all the magic is
> isolated to one file. The problem is that it might be a bit fragile.
> 
> --
> Anders
> 
> 
>>>>> If the automagic updating of function spaces etc is removed.
>>>>> then mesh.refine() should definitely be disabled.
>>>> Yes, definitely.
>>>>
>>>> But let's keep AdaptiveObjects until we have ported our code to
>>>>
>>>>  new_mesh = refine(mesh)
>>>>
>>> _______________________________________________
>>> Mailing list: https://launchpad.net/~dolfin
>>> Post to     : dolfin@xxxxxxxxxxxxxxxxxxx
>>> Unsubscribe : https://launchpad.net/~dolfin
>>> More help   : https://help.launchpad.net/ListHelp
>> _______________________________________________
>> Mailing list: https://launchpad.net/~dolfin
>> Post to     : dolfin@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~dolfin
>> More help   : https://help.launchpad.net/ListHelp
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~dolfin
>> Post to     : dolfin@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~dolfin
>> More help   : https://help.launchpad.net/ListHelp