From CV
This is still an outstanding issue. Oksana and I resumed its investigation on December but then I left to Greece for three weeks (until this Monday) and the DB overload problem burst out, so effectively nothing has been done on this matter in the last month.
We have tried to evaluate the significance of the problem with large size fully simulated samples. The biggest (and I think most exhaustive) test of this type was based on a Pythia di-photon sample I generated some months ago both on namgrid (SL3/4) and kisti (SL5) under identical conditions. The results of that comparison are posted in http://www-cdf.fnal.gov/internal/mcProduction/SL5MCvalidation/gqcdu1/sl5val.html Of course they depend strongly on what you look at, but going through the plots in that page is useful.
It is remarkable that the KS level of agreement between namgrid and kisti results ranges from 0 to 99%. I interpret this variability as a sensitivity of each quantity to the random numbers used to evaluate it per event. A striking example is the trk_1 block: The z0 (primary vertex z-coordinate) distribution is very different for SL4 and SL5. In the same block lam0 (the cotangent of the track polar angle theta) distribution is hardly distinguishable with the eye between SL4 and SL5. My understanding of this is that z0 depends directly on the generated vertex coordinate (in fact it is the vertex coordinate after the simulation-reconstruction loop which introduces this funny 4-peak shape through conversions in the silicon card board material) which is randomly sampled using the GendLdz module in simulationMods, whereas lam0 depends only indirectly on the generated vertex coordinate through the radial geometry of the tracks. However, it looks like the problem is not restricted to the event generators built in cdfSim, like Pythia and Herwig, as we thought it was the case in the past.
I'm not sure if all the above is helpful for you. I was planning to investigate the problem with the debugger in parallel runs on SL4 and SL5, searching for the points where the two runs deviate. I would appreciate any suggestions. The problem is related with SL5 migration: It may go away if we both build and run on SL5, but if we don't have backward compatibility it will create a very serious issue of discontinuity in MC generated before and after the migration; we'll then need different scale factors to match MC before and after SL5 migration. We may discuss this further offline when you have the chance to come here or today after the offline meeting.
Modified 13-January-2010 at 09:52
http://hep.physics.wisc.edu/~jnb/cdfcode/13Jan2010
| Previous notes | Next notes | Main slide directory |