ufl team mailing list archive

[Johan Hake <johan.hake@xxxxxxxxx>]

On Friday March 4 2011 06:32:29 Martin Sandve Alnæs wrote:
> 2011/3/4 Anders Logg <logg@xxxxxxxxx>:
> > On Thu, Mar 03, 2011 at 04:12:37PM -0800, Johan Hake wrote:
> >> On Thursday March 3 2011 15:37:11 Anders Logg wrote:
> >> > On Thu, Mar 03, 2011 at 03:02:10PM -0800, Johan Hake wrote:
> >> > > Hello!
> >> > > 
> >> > > I have some large forms, including some 40 exterior facet integrals.
> >> > > I am starting to get annoyed by a constant recompilation of these
> >> > > forms. I have made pretty clear that each one does not contain any
> >> > > numbers that changes from simulation to simulation (Using Constant
> >> > > or Expression for changing coefficients). But at arbitrary times,
> >> > > reompilations are triggered and with many integrals per form this
> >> > > take times ~5-20min each... The generated code is not large, no
> >> > > complex forms, just many integrals. I also use MixedSpaces with
> >> > > Real, see other email, with some 10 Real spaces.
> >> > > 
> >> > > I have tried to eliminate any possible triggers for recompilations
> >> > > within my own code, change all dicts to ordered dicts and so on.
> >> > > Becuase the forms are so big it is almost impossible to debug any
> >> > > signature string from the form. They are hundreds of konsole lines
> >> > > long...
> >> > 
> >> > Does the hash sum change?
> >> 
> >> I suspect that, because otherwise it would not trigger a recompile.
> > 
> > Could you check? Try storing the values returned by __hash__ and
> > signature in JITObject in FFC to a file, and print some messages like
> > "not in cache, need to generated code", "found in cache" etc, together
> > with some numbers:
> > 
> > 1. sfdirwe2349sf9wr98sdf9wer987wer97wer98we7wer9wef: not in cache
> > 2. f09fs09wr09s8fd09s8df09we09sd8s0d9f8s0df98sdf98s: found in cache
> > 3. ...
> > 
> > Then do the same thing with the full signatures in a separate
> > file. Then locate the form that triggers recompilation, confirm that
> > the hash is changed, and then compare the full signatures.
> > 
> > --
> > Anders
> > 
> >> But the hash sum is dependent on the repr of the form. I suspect that
> >> there might be some randomness built into this.
> >> 
> >> Eventhough a simple case:
> >> 
> >>   a = u*v*dx
> >>   a += u*v*ds(1)
> >>   a += u*v*ds(2)
> >> 
> >> should create the same form each time, (This particular simple example
> >> probably does), I have much more complicated forms building up which I
> >> suspect don't create the same repr all the time. I haven't been able to
> >> debug it further as the repr of the forms are hundreds of konsole
> >> line...
> >> 
> >> Johan
> 
> Are you using UFL files or PyDOLFIN? If the latter I would start
> looking at the UFL subclasses classes that PyDOLFIN implement.

Good point! Will do!

> No randomness was a fundamental design criteria in UFL after all the
> problems I had with the randomness in GiNaC... Any randomness should
> be considered a critical bug.

He, he, remember discussing this issue before!

Johan