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