- pagebs's home page
- Posts
- 2017
- June (1)
- 2016
- 2015
- 2014
- December (2)
- November (1)
- October (2)
- September (4)
- August (1)
- July (2)
- June (2)
- May (3)
- April (2)
- March (2)
- February (2)
- January (1)
- 2013
- November (1)
- October (3)
- September (2)
- August (3)
- July (4)
- June (4)
- May (2)
- April (2)
- March (2)
- February (4)
- January (2)
- 2012
- December (2)
- November (3)
- October (2)
- September (1)
- August (3)
- July (3)
- June (6)
- May (2)
- April (3)
- March (3)
- February (2)
- January (2)
- 2011
- December (2)
- November (1)
- October (7)
- September (3)
- August (2)
- July (5)
- June (2)
- May (2)
- April (4)
- March (2)
- January (1)
- 2010
- December (2)
- October (4)
- September (1)
- August (4)
- July (1)
- June (2)
- May (2)
- March (4)
- February (2)
- January (2)
- 2009
- December (1)
- November (2)
- October (1)
- September (2)
- August (1)
- July (2)
- June (1)
- May (2)
- April (2)
- March (1)
- February (1)
- January (6)
- 2008
- My blog
- Post new blog entry
- All blogs
Missing Statistics in 2009 200GeV Jet Trees
This page details my investigation into why, for a majority of runs, there is a large discrepancy between the number of events of a certain trigger as seen in the 2009 200GeV jet trees as opposed to what we would expect from the run log.
As part of my QA of the 2009 200GeV jet trees I created plots showing the ratio of the number of specific triggers counted from the jet trees vs the number of triggers that were recorded in the cdev database (and displayed on the run log pages) on a run by run basis. I saw that many runs were missing a singnificant number of events.
Figure 1: The bottom panel of this plot shows the ratio of number of JP1 triggers gotten from the jet trees to the number of JP1 triggers expected from cdev for ~110 first priority production2009_200Gev_Single runs.
A file which gives the mapping between Run Index and run number can be found here.
A quick word on how the jet trees are produced. Each run has a number of MuDst files associated with it, can vary from ~20 to ~50 depending on how many events are in the run. The submission script which sends the trees to the farm groups these MuDst files into a series of jobs usually containing 5 or 6 individual MuDst files. These jobs are then submitted to the medium queue, which has a time limit of 5 hours.
When I investigated the log files from the runs with the missing statistics I found that for each run, one or more jobs had failed. Looking closer at the failed jobs, I found that they often accounted for a large fraction of the total number of events in the run. For example, the files for run 10125068 were split into 6 jobs, the one job that failed contained 123565 events and the 5 jobs that completed only contained 80981 events. It seems that the schedular likes to group files with large event numbers into the same jobs, and it is those jobs that fail.
The fact that it was the jobs with a large number of events which were failing led me to believe that these jobs were bumping into the time limit on the short queue. To test this, I ran a small jet tree production and forced all jobs into the long queue.
Figure 2: The bottom panel of this plot shows the ratio of JP1 trigger seen in the jet trees to the number of JP1 triggers we would expect from cdev for the first 20 runs shown in figure 1. This plot was created using the jet trees which were run in the long queue.
As you can see, creating the trees using the long queue eliminates the large discrepencies between seen and expected triggers which were present in the trees created using the medium queue.
- pagebs's blog
- Login or register to post comments