dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

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

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

Attachment: signature.asc
Description: Digital signature