dolfin team mailing list archive

["Garth N. Wells" <gnw20@xxxxxxxxx>]

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;

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

> --
> Anders