dolfin team mailing list archive

["Marie E. Rognes" <meg@xxxxxxxxx>]

On 09/02/2012 12:23 PM, Garth N. Wells wrote:
> 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?

Agree!

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

Yes, I would find this less confusing and more useful.

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

I think in order to cut the third one, there needs to be a reliable and
flexible way of replacing subdomains in a given form cf Johan's comment.
This might exist today, but I'm not entirely sure.


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

Cutting this interface is a significant change, so I would suggest
adding a deprecation warning and making a release before doing so.

--
Marie
> 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
> _______________________________________________
> Mailing list: https://launchpad.net/~dolfin
> Post to     : dolfin@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~dolfin
> More help   : https://help.launchpad.net/ListHelp