← Back to team overview

dolfin team mailing list archive

Re: [noreply@xxxxxxxxxxxxx: [Branch ~dolfin-core/dolfin/rognes] Rev 5741: Add adaption of cell functions after mesh refinement.]

 

On Sat, Mar 12, 2011 at 05:56:38PM +0000, Garth N. Wells wrote:
>
>
> On 12/03/11 17:20, Marie E. Rognes wrote:
> > On 03/12/2011 06:02 PM, Garth N. Wells wrote:
> >>
> >>
> >> On 12/03/11 09:41, Marie E. Rognes wrote:
> >>> On 03/12/2011 10:03 AM, Anders Logg wrote:
> >>>> Nice! Is it working?
> >>>
> >>> Yes.
> >>>
> >>> As in, the logic is in place. The technicalities are not. Same for facet
> >>> functions.
> >>>
> >>> Is it ok to make MeshFunction Hierarchical, or are there some template
> >>> issues that one should be aware of?
> >>>
> >>
> >> Sounds a bit complicated to me - would it be better to associate
> >> relevant MeshFunctions with a Mesh, and take care of the hierarchy that
> >> way (since there is a hierarchy of meshes)?
> >
> > I was aiming for consistency. The other classes that depend on a mesh
> > and need updating after mesh refinement are dealt with using Hierarchical.
> >
>
> Consistency in complication? ;)
>
> Along the lines a simplicity, and I don't like the circular nature of
> making MeshFunctions hierarchical. A mesh is hierarchical, and
> hierarchical a MeshFunction stores a pointer to a  hierarchical mesh.

It's not more circular than it already is (without a hierarchy). All
objects on one level of a hierarchy (or when no hierarchy is present)
are connected somehow (function space has a mesh, which may have mesh
functions which have a mesh etc).

Adding a hierarchy to MeshFunctions sounds like a natural extension to
me. It's not really a big complication. The only thing it does is that
a MeshFunction knows its child and parent.

--
Anders


> > But following up on your suggestion: So, say we get a couple of forms
> > with attached mesh functions. Instead of transferring the refined mesh
> > functions to the refined forms, one could associate the refined mesh
> > functions with the refined mesh, and by the "override" order specified
> > by the Assembler, these would be applied to the refined forms. However,
> > there can be different mesh functions (for instance different
> > exterior_facet_domains) attached to the different forms, and so storing
> > these with the mesh using single named mesh functions would not be
> > sufficient. Bottomline, I don't quite see how that would work without
> > getting "creative".
> >
>
> I only plead for simplicity, and avoiding a viral design. The details
> are up to you ;).
>
> Garth
>
> >>
> >> Garth
> >>
> >>> I'll merge with main _later_ today, sort out changes wrt
> >>> shared_ptrs/MeshFunctions and any other issues, and then continue.
> >>>
> >>>
> >>> _______________________________________________
> >>> 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
>
> _______________________________________________
> Mailing list: https://launchpad.net/~dolfin
> Post to     : dolfin@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~dolfin
> More help   : https://help.launchpad.net/ListHelp



References