dolfin team mailing list archive

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

On 2 September 2012 11:10, Anders Logg <logg@xxxxxxxxx> wrote:
> On Sat, Sep 01, 2012 at 03:09:42PM +0100, Garth N. Wells wrote:
>> The logic around how we handle integration over domains is confusing.
>> I'm trying to fix a small problem which is opening a can of worms.
>> Subdomain data can be optionally passed to the assembler, attached to
>> a Form or attached to a Mesh (the latter being particularly confusing
>> because it's mixing concepts). I suggest that we have just one to do
>> things, and I think the most logical and user friendly is to attach
>> subdomain data to Forms. Opinions?
>
> I agree that the logic is complex, but it is there for a reason.
>
> There are three ways to specify subdomains, by order of increasing
> priority.
>
> First, it can be specified as part of the mesh. This is a good thing
> since it allows markers to be stored as part of Mesh XML files. Very
> useful for Mesh generators and tools like VMTK.
>

I think that this is very clumsy and mixes concepts. Say I have one
mesh but want to perform two different simulations with different bcs.
It's opaque. What happens if I have markers in a Mesh and markers
attached to a Form -> ambiguous.

Better would be to store the markers as part of the mesh, but pull
them out and attach them to a form. I was already planning to have
mesh markers in a mesh file that are identified by strings (e.g.
"top", "inner sphere", etc) rather than  integers (which are error
prone because they convey no meaning). A user could query which
markers a mesh has (via a set of identifier strings), and attach the
right ones.

> Second, it can be specified as part of a Form. This is useful for
> assembling several forms on the same mesh but with different domains.
>

This is nice.

> Third, it can be specified explicitly as an argument to the assembler.
>
> If we should cut any of these, I would suggest cutting the third one,
> but I think it is widely used as part of both user code and examples
> so I'm not sure we should cut it.
>

We have a bug that I'm more interested in fixing simply and robustly
than in preserving a clumsy interface, so I'd cut it. Users can update
their code.

Garth

> The logic for extracting which domains could be moved to a special
> function that takes care of extracting the correct MeshFunction from
> either Mesh, Form or explicit arguments. With some extra diagnostics
> and careful error checking, it can be made more robust and
> user-friendly.
>
> --
> Anders