2011/3/4 Anders Logg <l...@simula.no>: > 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 _______________________________________________ Mailing list: https://launchpad.net/~dolfin Post to : dolfin@lists.launchpad.net Unsubscribe : https://launchpad.net/~dolfin More help : https://help.launchpad.net/ListHelp
