Kristian Oelgaard wrote: > Quoting "Garth N. Wells" <[email protected]>: > >> I've run into a problem with zero coefficients. The code: >> >> mesh = UnitSquare(32, 32) >> >> V = FunctionSpace(mesh, "CG", 1) >> v = TestFunction(V) >> >> # Source term >> f = 0.0 >> >> # Linear form >> L = v*f*dx >> >> # Assemble and apply boundary conditions >> b = assemble(L) >> >> >> gives an error since f = 0 which means that UFL eliminates it. I can get >> around it by doing >> >> f = Function(V, "0.0") >> >> but that's not very satisfactory. It would work if I had some other term >> in the linear form which is non-zero. UFL should generate a >> representation for f = 0 if there are no other terms in the form. > > Currently in UFL whenever a zero is encountered in a product, the product is > replaced by Zero. It is therefore not straightforward to 'reconstruct' the > term > which resulted in the Zero since you want: > > L = (0*v)*dx --> (0)*dx --> (0*v)*dx > > As I see it, it can be done if we don't handle the Zeros when constructing the > products but wait until creating the integrand and then strip any Zeros in > Sums > etc. (this will be less efficient) such that: > > L = g*v*dx + 0*v*dx -> g*v*dx > L = 0*v*dx + 0*g*v*dx -> 0*dx > > also note that we probably want: > > L = 0*v*very_long_ufl_expression*dx -> 0*v*dx > > for run-time efficiency. >
UFL should return a message that it is zero, but still enough information for the form compiler to generate code. The behaviour which I described in PyDOLFIN is not good. Garth > Kristian > >> Garth >> _______________________________________________ >> UFL-dev mailing list >> [email protected] >> http://fenics.org/mailman/listinfo/ufl-dev >> > > _______________________________________________ DOLFIN-dev mailing list [email protected] http://www.fenics.org/mailman/listinfo/dolfin-dev
