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 will implement this then.

--
Anders


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