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
_______________________________________________ Mailing list: https://launchpad.net/~fenics Post to : [email protected] Unsubscribe : https://launchpad.net/~fenics More help : https://help.launchpad.net/ListHelp
