fenics team mailing list archive

[Martin Sandve Alnæs <martinal@xxxxxxxxx>]

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