← Back to team overview

ffc team mailing list archive

Re: Arbitraryness in code generated by quadrature representation?

 

On 01/21/2011 10:34 AM, Kristian Ølgaard wrote:
On 21 January 2011 01:14, Marie E. Rognes<meg@xxxxxxxxx>  wrote:
On 01/20/2011 03:47 PM, Kristian Ølgaard wrote:

On 20 January 2011 15:23, Marie E. Rognes<meg@xxxxxxxxx>  wrote:

On 01/20/2011 03:20 PM, Kristian Ølgaard wrote:

On 20 January 2011 14:59, Marie E. Rognes<meg@xxxxxxxxx>  wrote:

On 01/20/2011 02:55 PM, Kristian Ølgaard wrote:

On 20 January 2011 14:32, Marie E. Rognes<meg@xxxxxxxxx>  wrote:

Repeated runs of the dolfin generate-form-files scripts seems to generate
different code. For instance for the forms defined in

     /demo/undocumented/dg-advection-diffusion/cpp/AdvectionDiffusion.ufl

I get differences of the type

-    G[1] = 0.500000000000000*det*n1;
-    G[2] = 0.500000000000000*det;
+    G[1] = 0.500000000000000*det;
+    G[2] = 0.500000000000000*det*n1;

in tabulate_tensor and corresponding differences for the tensor terms. The
code seems equivalent, but this behaviour makes it tedious to check for
changes in the generated code. Has anyone else experienced this?

Not lately, but I haven't been looking for it either. The quadrature
generator uses dicts heavily, so somewhere we need to throw in a
sorted(.keys()) to get rid of this behaviour but I don't know where
exactly.

Do you have any guesses (other than in quadrature/*)? I can fix if you point
me in the right direction.

Yes, in quadraturegenerator.py the dictionary geo_consts from the ir
is already created, and since the randomness only appears when
optimisations are on, the 'random' geo_consts dictionary must be
generated in quadratureoptimization.py. Expressions are added to the
dictionary by the function optimise_code from quadrature.symbolics but
the problem might have something to do with the order by which this
function is called (the loops in the _*() functions in
quadratureoptimization.py).


Ok, thanks! I'll take a look a little later.

OK, fine by me. If you don't get around to fixing it in the near
future you should file a bug report so we don't forget about it.

After some digging: do you think that replacing line 208 in symbolics.py

      for ip in ip_expressions:

with

      for ip in sorted(ip_expressions):

will create disaster?
There's only one way to find out :)
I think it should be OK. 'ip' is a tuple so as long as Python will
sort these consistently it might fix the problem.

Ok. Will add then. The ffc regression tests succeed, but there will be some changes in the generated code for some of the dolfin-demos. Looks ok after superficial scrutiny though, so will regenerate those.

--
Marie


--
Marie


Follow ups

References