ufl team mailing list archive

[Martin Sandve Alnæs <martin.alnes@xxxxxxxxx>]

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.

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.

--
Martin