Subject: [Fenics] Breaking change in trunk: *dx now means integration over entire domain

From: Martin Sandve Alnæs <[email-masked]>
Date: Wed, 30 Jan 2013 09:32:25 +0100

Hi all,
yesterday I pushed a change to trunk, which fixes a long standing confusing
issue. Unfortunately, the only way to stop this issue from confusing new
users is to change the interpretation of some forms. Hopefully few codes
will break from this change, but I'll explain it here so you can judge for
yourself.

Previously dx, ds and dS were aliases for dx(0), ds(0) and dS(0)
respectively, and the assembler in dolfin interpreted a missing
meshfunction for subdomains as if all cells were labeled with 0. So if you
wrote a form
  u*v*dx      [1a]
or
  u*v*dx(0)   [1b]
and assembled it without specifying subdomains, you got the integral over
the entire mesh in both cases.

However if you wrote
  f*dx + g*dx(1)   [2]
and assembled it with subdomains, then f would only be integrated over the
subdomain labeled 0, just as if you wrote
  f*dx(0) + g*dx(1)   [3]
This has naturally caused some confusion and bugs.

With the development version of ufc,ufl,ffc,dolfin from today, you can
explicitly write
  f*dx() + g*dx(1)   [4]
to integrate f over the entire domain and g over subdomain 1, independent
of subdomain labeling.

The breaking change is that [2] is now equivalent to [4], not [3].

That is, f*dx is now interpreted as f*dx(), and not as f*dx(0). This means
that if you have code that depends on *dx being assembled only over
subdomain 0, that code will break. I do not believe this to be a big
problem, as it would be more natural to write explicitly dx(0) in such a
case. However, if you do have such code, I recommend changing *dx to *dx(0)
to be explicit, even if you are using 1.0 or 1.1 today.

Martin

---

From: Johan Hake <[email-masked]>
Date: Wed, 30 Jan 2013 09:49:28 +0100

Very nice!

So:

  f*dx

will be assembled over all cells also if the mesh contains domain
information for some or all cells?

Johan

On 01/30/2013 09:32 AM, Martin Sandve Alnæs wrote:
> Hi all,
> yesterday I pushed a change to trunk, which fixes a long standing
> confusing issue. Unfortunately, the only way to stop this issue from
> confusing new users is to change the interpretation of some
> forms. Hopefully few codes will break from this change, but I'll explain
> it here so you can judge for yourself.
> 
> meshfunction for subdomains as if all cells were labeled with 0. So if
> you wrote a form
>   u*v*dx      [1a]
> or
>   u*v*dx(0)   [1b]
> and assembled it without specifying subdomains, you got the integral
> over the entire mesh in both cases.
> 
> However if you wrote
>   f*dx + g*dx(1)   [2]
> and assembled it with subdomains, then f would only be integrated over
> the subdomain labeled 0, just as if you wrote
>   f*dx(0) + g*dx(1)   [3]
> to integrate f over the entire domain and g over subdomain 1,
> independent of subdomain labeling.
> 
> That is, f*dx is now interpreted as f*dx(), and not as f*dx(0). This
> means that if you have code that depends on *dx being assembled only
> over subdomain 0, that code will break. I do not believe this to be a
> big problem, as it would be more natural to write explicitly dx(0) in
> such a case. However, if you do have such code, I recommend changing *dx
> to *dx(0) to be explicit, even if you are using 1.0 or 1.1 today.
> 
> Martin
> 
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~fenics
> Post to     : [email-masked]
> Unsubscribe : https://launchpad.net/~fenics
> More help   : https://help.launchpad.net/ListHelp
>

---

From: Martin Sandve Alnæs <[email-masked]>
Date: Wed, 30 Jan 2013 10:28:59 +0100

Exactly.

Martin

---

From: Anders Logg <[email-masked]>
Date: Wed, 30 Jan 2013 12:12:16 +0100

This is great!

--
Anders

On Wed, Jan 30, 2013 at 09:32:25AM +0100, Martin Sandve Alnæs wrote:
>    forms. Hopefully few codes will break from this change, but I'll
>    explain it here so you can judge for yourself.
>    such a case. However, if you do have such code, I recommend changing
>    *dx to *dx(0) to be explicit, even if you are using 1.0 or 1.1 today.
>    Martin