Facet markers attached to mesh in file

Markers must be attached to a Form to assemble over subdomains. This was discussed a while back on the mailing list. All assemblers handle this consistently now, which until recently was not the case.

I was under the impression that we would still behave the same way in
python.The assemble function in python attaches the markers from the mesh
to the Form, but it uses the mesh.data() and not the mesh.domains(). Is
that intentional? Is mesh.data() still used? I think I will change or add
fetching from mesh.domains() there if nobody objects. Just a couple of
lines.
Den 5. apr. 2013 17:41 skrev "Garth Wells" <
<email address hidden>> følgende:

> Your question #225977 on DOLFIN changed:
> https://answers.launchpad.net/dolfin/+question/225977
>
> Status: Open => Answered
>
> Garth Wells proposed the following answer:
> Markers must be attached to a Form to assemble over subdomains. This was
> discussed a while back on the mailing list. All assemblers handle this
> consistently now, which until recently was not the case.
>
> --
> If this answers your question, please go to the following page to let us
> know that it is solved:
> https://answers.launchpad.net/dolfin/+question/225977/+confirm?answer_id=0
>
> If you still need help, you can reply to this email or go to the
> following page to enter your feedback:
> https://answers.launchpad.net/dolfin/+question/225977
>
> You received this question notification because you asked the question.
>

That looks like a bug. It should use domains().

Johan
On Apr 5, 2013 5:56 PM, "Martin Sandve Alnæs" <
<email address hidden>> wrote:

> Question #225977 on DOLFIN changed:
> https://answers.launchpad.net/dolfin/+question/225977
>
> Status: Answered => Open
>
> Martin Sandve Alnæs is still having a problem:
> I was under the impression that we would still behave the same way in
> python.The assemble function in python attaches the markers from the mesh
> to the Form, but it uses the mesh.data() and not the mesh.domains(). Is
> that intentional? Is mesh.data() still used? I think I will change or add
> fetching from mesh.domains() there if nobody objects. Just a couple of
> lines.
> Den 5. apr. 2013 17:41 skrev "Garth Wells" <
> <email address hidden>> følgende:
>
> > Your question #225977 on DOLFIN changed:
> > https://answers.launchpad.net/dolfin/+question/225977
> >
> > Status: Open => Answered
> >
> > Garth Wells proposed the following answer:
> > Markers must be attached to a Form to assemble over subdomains. This was
> > discussed a while back on the mailing list. All assemblers handle this
> > consistently now, which until recently was not the case.
> >
> > --
> > If this answers your question, please go to the following page to let us
> > know that it is solved:
> >
> https://answers.launchpad.net/dolfin/+question/225977/+confirm?answer_id=0
> >
> > If you still need help, you can reply to this email or go to the
> > following page to enter your feedback:
> > https://answers.launchpad.net/dolfin/+question/225977
> >
> > You received this question notification because you asked the question.
> >
>
> --
> You received this question notification because you are a member of
> DOLFIN Team, which is an answer contact for DOLFIN.
>

We shouldn't use mesh-attached domains in assemblers because:

1. It is a major inconsistency in behaviour between the C++ and Python interfaces
2. The reasons discussed on the mailing list

The issue is that we cannot necessarily attach data to forms in Python because they are not necessarily dolfin::Form objects. The proper question is how to deal with this point. It is presently supported by the user passing the domains as arguments to the assembler.

On 6 April 2013 01:01, Johan Hake <email address hidden> wrote:
> Question #225977 on DOLFIN changed:
> https://answers.launchpad.net/dolfin/+question/225977
>
> Status: Open => Answered
>
> Johan Hake proposed the following answer:
> That looks like a bug. It should use domains().
>

I don't agree that it's a bug.

Garth

> Johan
> On Apr 5, 2013 5:56 PM, "Martin Sandve Alnæs" <
> <email address hidden>> wrote:
>
>> Question #225977 on DOLFIN changed:
>> https://answers.launchpad.net/dolfin/+question/225977
>>
>> Status: Answered => Open
>>
>> Martin Sandve Alnæs is still having a problem:
>> I was under the impression that we would still behave the same way in
>> python.The assemble function in python attaches the markers from the mesh
>> to the Form, but it uses the mesh.data() and not the mesh.domains(). Is
>> that intentional? Is mesh.data() still used? I think I will change or add
>> fetching from mesh.domains() there if nobody objects. Just a couple of
>> lines.
>> Den 5. apr. 2013 17:41 skrev "Garth Wells" <
>> <email address hidden>> følgende:
>>
>> > Your question #225977 on DOLFIN changed:
>> > https://answers.launchpad.net/dolfin/+question/225977
>> >
>> > Status: Open => Answered
>> >
>> > Garth Wells proposed the following answer:
>> > Markers must be attached to a Form to assemble over subdomains. This was
>> > discussed a while back on the mailing list. All assemblers handle this
>> > consistently now, which until recently was not the case.
>> >
>> > --
>> > If this answers your question, please go to the following page to let us
>> > know that it is solved:
>> >
>> https://answers.launchpad.net/dolfin/+question/225977/+confirm?answer_id=0
>> >
>> > If you still need help, you can reply to this email or go to the
>> > following page to enter your feedback:
>> > https://answers.launchpad.net/dolfin/+question/225977
>> >
>> > You received this question notification because you asked the question.
>> >
>>
>> --
>> You received this question notification because you are a member of
>> DOLFIN Team, which is an answer contact for DOLFIN.
>>
>
> --
> You received this question notification because you are a member of
> DOLFIN Team, which is an answer contact for DOLFIN.

On 04/06/2013 01:21 AM, Garth Wells wrote:
> Question #225977 on DOLFIN changed:
> https://answers.launchpad.net/dolfin/+question/225977
>
> Garth Wells proposed the following answer:
> We shouldn't use mesh-attached domains in assemblers because:
>
> 1. It is a major inconsistency in behaviour between the C++ and Python interfaces
> 2. The reasons discussed on the mailing list
>
> The issue is that we cannot necessarily attach data to forms in Python
> because they are not necessarily dolfin::Form objects. The proper
> question is how to deal with this point. It is presently supported by
> the user passing the domains as arguments to the assembler.

I agree. I answered before I had a look at the code. Then I suggest
removing the part accessing the mesh.data() in assemble, which has not
worked anyhow since 1.0.0. That part is just old deprecated code.

We also need to update the logic of extracting the subdomains in python
assemble reflecting the "new" interface of cpp.assemble. Setting the
subdomains from kwargs in assemble is now done after dolfin.Form
construction rather than during construction.

Johan

1) I need this functionality, i.e. having domains carried with the mesh. Without that a lot of code in my group will break when upgrading from 1.0, which I'm trying to do. If there is any reason to not have this feature, I don't see it. "I don't agree" from Garth is not a reason.

2) I will make the necessary adjustment to assemble() in python to fetch domains from the mesh and attatch them to the Form. This does not complicate anything, it's just two lines of python, and will allow us to upgrade to trunk.

3) I think similar functionality still makes sense in C++, and this can be handled by the generated Form constructor passing the Mesh domains to the Form baseclass constructor. I don't plan to do this, just saying that it could be done fairly easily.

Issues that were before but are irrelevant now:

a) projection results depending on the existence or lack of markers in the mesh: fixed by my global integration implementation.

b) assemblers in C++ handling domains differently: fixed by saying "assemblers take domains from the Form", which is fine and won't be changed when assemble() in python attaches domains from the mesh to the Form, (and would also be fine with the generated Form constructor eventually doing the same attaching).

So I don't see any issues with keeping this feature.

On Wednesday, 10 April 2013, Martin Sandve Alnæs wrote:

> Question #225977 on DOLFIN changed:
> https://answers.launchpad.net/dolfin/+question/225977
>
> Status: Answered => Open
>
> Martin Sandve Alnæs is still having a problem:
> 1) I need this functionality, i.e. having domains carried with the mesh.

It is carried by the mesh, which can be convenient, but it's not used
directly by the assemblers. You can easily access this data from the mesh
and pass it to the assembler each time you assemble. This is better than
the situation in which one might read a mesh which unknowingly may contain
mesh data which is used inside the assembler *without* the user being aware.

Without that a lot of code in my group will break when upgrading from
> 1.0, which I'm trying to do. If there is any reason to not have this
> feature, I don't see it. "I don't agree" from Garth is not a reason.

The burden is on you, not me, to search for the past discussion on the
maling list.

I do note that you're 1.0 code was always broken if you we're to change the
assembler. This is part of what kicked off the original discussion.

I'm happy to restart a discussion from where the orginal discussion left
off, but not from the beginning again.

> 2) I will make the necessary adjustment to assemble() in python to fetch
> domains from the mesh and attatch them to the Form. This does not
> complicate anything, it's just two lines of python, and will allow us to
> upgrade to trunk.
>
>
The changes were made for a reason, not to break your upgrade.

> 3) I think similar functionality still makes sense in C++, and this can
> be handled by the generated Form constructor passing the Mesh domains to
> the Form baseclass constructor. I don't plan to do this, just saying
> that it could be done fairly easily.
>
>
Again, please search first for the past discussion and start form there.

Garth

--
> You received this question notification because you are a member of
> DOLFIN Team, which is an answer contact for DOLFIN.
>