dolfin team mailing list archive

[Johan Hake <hake.dev@xxxxxxxxx>]

On 09/03/2012 10:24 AM, Garth N. Wells wrote:
> On 3 September 2012 09:06, Marie E. Rognes <meg@xxxxxxxxx> wrote:
>> 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.
>>
> 
> Yes, I was getting confused. Also, I was trying convert a common 3rd
> party format the uses names for sub-domains.
> 
>>
>>>> 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.
>>
> 
> Should be easy via shared pointers.
> 

Not sure how to do this robustly in the context of a ufl.Form, which is
what a user is exposed to in the Python interface. Now one is not
allowed to alter:

  ufl.Form.cell_domains

We could require the user to instantiate a dolfin.Form, then it is
straightforward. But that solution introduces another abstraction, which
is not intuitive.

Johan

>>
>>> 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.
>>
> 
> Could be tricky because the interface is the bug, due to ambiguities
> with all the default arguments.
> 
> Garth
> 
>> --
>> 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
>>
>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~dolfin
>> Post to     : dolfin@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~dolfin
>> More help   : https://help.launchpad.net/ListHelp
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~dolfin
> Post to     : dolfin@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~dolfin
> More help   : https://help.launchpad.net/ListHelp
>