Hi Urs, in your detailed mail I fail to understand what are the plans as far as SP5 and run1-3 data are concerned. I do not think that a mixture of release 12/ CM2 data-MC is a possible data sample for publication, so I believe that the production/publication plan needs to account for the CM2 production of run1-3 and SP5 (with old style ntuples if we agree to). So my suggestion would be to produce the large ntuples in the order: - run4 data - SP6 - run1-3 data - SP5 Among the manpower we also have the QM group, which could take care of the last 2 bullets (besides getting started in the analysis). I would leave running on SP5 R12 as the very last resort if all else fails (but then we are not the only ones in trouble) ciao ric ______________________________________________________ Riccardo Faccini Universita' "La Sapienza" & I.N.F.N. Roma tel +39/06/49914798 Fax.: +39/06/4957697 http://www.slac.stanford.edu/~rfaccini Univ. La Sapienza. 2,Ple Aldo Moro, I-00185 Roma Dipartimento di Fisica "I don't understand what you say, but I believe I disagree" On Tue, 13 Apr 2004, Urs Langenegger wrote: > > [the following is a kind-of consensus between HD/RHUL/SLAC or wishful > thinking that would provide benefits on the short time scale] > > > Hoi, > > after a few phone calls, it seems that a new option is emerging. > Below you find a proposal, please let me know if you disagree. If I > hear nothing from you, I'll send this to vub-recoil after Easter. > > > The situation > ------------- > > o Currently, analysis-20 is being built and close to release. The > executable is expected to be about as fast as an OBJY exe ("a bit > slower"). It should be capable of running on OBJY micro. > > o At the end of next week, a substantial amount of skimmed data is > expected to become available (as of now it's only 60/fb). By then > it might be something like 130/fb. Maybe/hopefully. > > o Clare needs (or would like to use) more than just 80/fb for her > thesis. > > o The same is more or less true for the b2ulnu analysis (and Ed's > thesis) > > o The projection for skimmed MC CM2 availability is slipping. At > the Wednesday physics meeting we heard "June". > > > The idea > -------- > > o Produce new ntuples with minimal (=no) changes with respect to the > old "big" ntuples. Except: Just produce ROOT files. This allows to > use them for analysis immediately and is probably the only way to > use RUN3/4 data for public results before the end of this year. > > This is explicitly NOT a CM2 analysis, just an attempt to get more > data for the short time scale. > > o Run on RUN4 CM2 data as more becomes available > > o Run on MC as soon as possible. We should test whether running on > SP5 OBJY is viable. > > > The plan > -------- > > o Ed will provide a set of tags to build IslBrecoilUserApp, based on > analysis-20. He will do basic validation, i.e. that it is running. > This also includes tcl (steering) files for CM2 and OBJY running. > > o Urs will do a bit more of validation, looking at all variables in > the "h1" tree. > > o Royal Holloway will organize the production. I think this will > involve the following: > > - backup the current HBOOK ntuples of Henning/Oliver to mstore > and/or RAL or somewhere else. > > - Create tcl files for skimmed data. In the following I detail > what issues must be considered in a low-tech approach (based > on "run", the run-script with built-in bookkeeping and > optimized queue saturation :-) Other possibilities exist of > course, I just don't know them. Whoever organizes the > production is free to choose whatever works! > > + The naming scheme for the "basename" should be well > designed. In the last production we had a bit of a mess and > it made life difficult. . A possible solution is something > like the following: > > genbch-run1-..... > genbnu-run1-..... > genccb-run1-..... > genuds-run1-..... > > cktbch-run1-..... > cktbnu-run1-..... > cktb2u-run1-..... > > b2unre-run1-..... > b2ures-run1-..... > b2umix-run1-..... > > > NOTE: The total amount of files will likely exceed 100000. > (We had something like 30k for the previous production.) > > NOTE: We used to have something like 2k events per file. We > have to think whether we want to merge the rootfiles to > reflect the merged CM2 files. Another possibility is to have > in the filename (in the ..... part above) the start and end > events in the merged CM2 files (see next item if this NOTE > is not clear). > > + The size of the tcl files needs to be optimized for the > queue length. (kanga?) > > NOTE: I think this could mean that we cannot run one job per > CM2 merged skim file. This needs to be studied!!! > > + The tool of choice is probably "BbkDatasetTcl". > > + I think that the tcl files should be in a logical directory > structure to avoid too many files per directory > > $BASE/tcl/SemiExclBreco-2004a/data > $BASE/tcl/SemiExclBreco-2004a/data/run1 > $BASE/tcl/SemiExclBreco-2004a/data/run2 > $BASE/tcl/SemiExclBreco-2004a/data/run3 > $BASE/tcl/SemiExclBreco-2004a/data/run4 > > $BASE/tcl/SemiExclBreco-2004a/mc > $BASE/tcl/SemiExclBreco-2004a/mc/run1 > $BASE/tcl/SemiExclBreco-2004a/mc/run1/bch > $BASE/tcl/SemiExclBreco-2004a/mc/run1/bnu > $BASE/tcl/SemiExclBreco-2004a/mc/run1/ccb > $BASE/tcl/SemiExclBreco-2004a/mc/run1/uds > $BASE/tcl/SemiExclBreco-2004a/mc/run1/sig > $BASE/tcl/SemiExclBreco-2004a/mc/run1/ckt > > - The output root files should be stored in a way that reflects > this structure: > > $BASE/output/SemiExclBreco-2004a/data > $BASE/output/SemiExclBreco-2004a/data/run1 > $BASE/output/SemiExclBreco-2004a/data/run2 > > $BASE/output/SemiExclBreco-2004a/mc/run1 > $BASE/output/SemiExclBreco-2004a/mc/run1/bch > > > - A few notes on the directories: > > + It does not really matter what names we choose, but it > should be something that is consistent and extensible to > new productions, which could end up in, e.g. > > $BASE/SemiExclBreco-2004b/ > > + We should avoid too many subdirectories, but should make > sure that not too many files end up in one directory. > (Note: In the old production, 80/fb data and 240/fb MC, we > had 11000 gen B+ files in total.) > > + Not all directories need to be physically below $BASE, they > could be symbolic links to a different disk. But we should > see all from one base location. > > > - Of course, the logfiles should be stored similarly: > > $BASE/log/SemiExclBreco-2004a/data > $BASE/log/SemiExclBreco-2004a/mc > > and the corresponding subdirectories. If we use "run" this is > essential. > > - The jobs will be run by a bunch of people, organized (and > tabulated) by someone. "Volunteers" so far are > > Clare > Ed > Henning > Rolf > Urs > Oliver ('s account, at least) > Other GradStudents > > Given this amount of manpower, we might actually get through > the unskimmed SP5 OBJY (700/fb!) on a relatively(?) short > timescale. > > o Diskspace might be sufficient once we delete the old HBOOK files > (from the previous production) and then ask for some more when > it's critical and we have enough momentum. > > > Cheers, > --U. >