dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Tue, Feb 22, 2011 at 11:32:07AM +0000, Garth N. Wells wrote:
>
>
> On 22/02/11 11:07, Anders Logg wrote:
> > On Tue, Feb 22, 2011 at 08:52:55AM +0000, Garth N. Wells wrote:
> >>
> >>
> >> On 22/02/11 07:51, Anders Logg wrote:
> >>> I'd like to implement this blueprint for 0.9.10:
> >>>
> >>> https://blueprints.launchpad.net/dolfin/+spec/attach-subdomains-to-form
> >>>
> >>> In addition, I'd like to remove the cell_domains,
> >>> exterior_facet_domains and interior_facet_domains arguments from the
> >>> assembler. It seems overkill to have three different ways to specify
> >>> the domains and the logic becomes complex for handling which data
> >>> overrides if many are specified. We could also remove these arguments
> >>> from VariationalProblem.
> >>>
> >>> We would then have two ways to specify the subdomains:
> >>>
> >>> 1. As part of the Mesh (MeshData)
> >>>
> >>> 2. As part of the form
> >>>
> >>> The SystemAssembler would then need to rely on (1).
> >>>
> >>> Comments and objections?
> >>>
> >>
> >> What's the advantage of having two methods? Why not just have one?
> >
> > It's natural to specify the subdomains as part of the mesh, but it's
> > also natural to specify them as part of the form if one has say a and
> > L and they should be assembled on the same mesh but partition the
> > domain differently into subdomains.
> >
>
> OK.
>
> >> I'd would be happy to see subdomains as part of MeshData, but I would be
> >> reluctant to use the existing data structures because I find them cryptic.
> >
> > I agree they are cryptic but it's the only way I know how to robustly
> > specify the boundaries. We can't store just a FacetFunction since the
> > facet numbering relies on the particular algorithm we use to compute
> > the facets (in TopologyComputation). If we optimize that computation,
> > the numbering may very well change.
> >
> > What we do now is to specify a certain facet on a certain cell of the
> > mesh. That is robust as long as the cell-vertex number does not change.
> >
>
> I don't quite follow the above. I advocate that the we have something like
>
>   std::vector<MeshFunction<uint> > sub_domains;

It only makes sense to store a MeshFunction over cells and vertices
(not faces or edges). The edge (and face) numbering may change as a result of
optimization in TopologyComputation where the edges are computed.

> in MeshData where the size of sub_domains is equal to the topological
> dimension. By being explicit in MeshData, it's much clearer what needs
> to be updated or reset if a mesh is changed.

The advantages with using named data are:

1. It's more flexible: just create the data without needing to change
the data structures.

2. It's easily visible upon inspection which data is there (using the
info function).

3. It's automatically handled by the XML format. If data is added to
MeshFunction, we otherwise have to modify the XML output + parser.

This issue seems to pop up now and again. Can't we all agree that the
MeshData class and it's named data storage is a wonderful idea/design?
I think it is. :-)

> >> We could have cell domains become part of the mesh .xml files - this
> >> would be helpful because mesh generators can often define domains, and
> >> it would be handy to use this data easily (by supporting it in
> >> dolfin-convert).
> >
> > Isn't it already? Everything stored in MeshData will automatically be
> > stored/retrieved from XML.
> >
>
> It may be, but I don't think that dolfin-convert supports it.

I'm not sure about dolfin-convert, but it's supported from MeshBuilder
and from VMTK.

--
Anders