On 2 Oct 2015, at 13:40, Stephan Kramer <s.kramer@imperial.ac.uk> wrote:
On 02/10/15 05:25, Lawrence Mitchell wrote:
On 2 Oct 2015, at 13:10, Stephan Kramer <s.kramer@imperial.ac.uk> wrote:
Hey guys
I've been trying to implement a simple IP viscosity scheme for DG, but was getting weird results, which I think I've tracked down to a bug related to fd_bendy.
If I run the following:
from firedrake import *
mesh2d = UnitSquareMesh(1,1) V = VectorFunctionSpace(mesh2d, "DG", 1) uv = Function(V) U_test = TestFunction(V)
n = FacetNormal(mesh2d) F1 = dot(jump(U_test[0], n), jump(uv[0], n))*dS F2 = -dot(avg(grad(U_test[0])), jump(uv[0], n))*dS F=F1+F2 F0 = dot(jump(U_test[0],n)-avg(grad(U_test[0])), jump(uv[0], n))*dS
M=assemble(derivative(F, uv)).M.values M1=assemble(derivative(F1, uv)).M.values M2=assemble(derivative(F2, uv)).M.values M0=assemble(derivative(F0, uv)).M.values
I really expect M, M1+M2 and M0 to be all the same. On firedrake master (and in fact Dolfin) these are all the same indeed. But in my fd_bendy enviroment (fd_bendy for ffc and ufl, bendy_changes for firedrake) the values for M are different. Final piece of information is that if I use parameters['coffee']={}, everything is fine again. Other than that I'm stuck though, so I'd much appreciate any pointers into what I could check next
So the fact that things work correctly with coffee optimisations off is probably enough of a pointer. Can you try with the current proposed COFFEE pull request branch that Fabio has been working on, enhance-rewriter-mode3-logflops
What's that magic! That fixes things for me indeed! Any idea what this could have caused? Or is this just a case of code refactoring accidentally fixing a bug?
This is a pretty large scale rewrite of coffee's rewrite engine. Adding new features, but also possibly making things more robust. You're welcome to try and find the culprit! But note there are about 75 commits here: https://github.com/coneoproject/COFFEE/pull/61 Lawrence