dolfin team mailing list archive

[Johan Hake <hake.dev@xxxxxxxxx>]

On 09/02/2012 12:49 PM, Anders Logg wrote:
> On Sun, Sep 02, 2012 at 11:23:11AM +0100, 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?
>>>
>>> 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.

Here form should take precedence, but I can see the potential ambiguity.
I agree with Anders that keeping domains in the Mesh file is important
for external mesh generators. Associating domains to a mesh is also a
very natural concept, which many other mesh formats make use of.

>> 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.
> 
> Sounds like a good solution. We could add a simple function call for
> transferring the markers "as is" to the Form, if the mesh is already
> marked with the correct integers to be used in the Form. A potential
> problem with this approach is the duplication of data (markers in both
> Mesh and Form). Possibly, this could be handled with shared pointers.

I think it is important to be able to change the domain markers after
creation of a Form, facilitating changing domains for different
assemble, while keeping the form constant.

Not sure what is best wrt sharing data. If we share data, changes to the
Form domain, will also change the domains stored in the Mesh. Not sure
this is what we want.

Named domains would be very useful! However, each domain need to be
mapped to a number in a consistent way.

>>> 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.
> 
> We should wait for comments on this one. I can manage without those
> extra arguments, but I believe others use it.

As long as we can change integration domains easily for a form before it
gets assemble I am all for simplifying the interface.

Johan

> --
> Anders
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~dolfin
> Post to     : dolfin@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~dolfin
> More help   : https://help.launchpad.net/ListHelp
>