[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.