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? Cheers Stephan
Locally, that appears to fix this problem.
Lawrence
_______________________________________________ firedrake mailing list firedrake@imperial.ac.uk https://mailman.ic.ac.uk/mailman/listinfo/firedrake