1 / 10

MC sign-off and running plans

MC sign-off and running plans. M. Moulson, 1 March 2004 Offline discussion. Outline: Results of tests on new MC files Sign-off on production version What to run next? CPU allocation between MC & users. MC upgrades: Response simulation. geanfi 1.7-2  1.7-3.

breena
Download Presentation

MC sign-off and running plans

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. MC sign-off and running plans M. Moulson, 1 March 2004 Offline discussion • Outline: • Results of tests on new MC files • Sign-off on production version • What to run next? • CPU allocation between MC & users

  2. MC upgrades: Response simulation geanfi 1.7-2  1.7-3 • EmC response to m, p, and KL: • Scaling of average response to ionization energy loss for m, p • Modifications to GHESHIA: • p+, p- interaction cross sections modified • Nuclear-evaporation and charge-exchange cross sections modified • Logical modifications • Artificial time delay for KL interactions eliminated • Probability of K0n interactions increased relative to K0p • Probability of K0n  S0p0 increased relative to K0n  L0p0 • Simulation of d rays in DC

  3. MC upgrades: Reconstruction datarec DBV-17  DBV-18 • Modifications to DCDELETE: • Order of hot/dead fixed • HW efficiencies simulated • Error in s-t relations used for DC reconstruction • Spurious timing offset removed

  4. MC upgrades: Kaon-decay generators geanfi 1.7-2  1.7-3 • KS  pen(g) generator fixed p and n reversed Zero-test affecting radiative tail • Decay mode for KS, KL, K+, K- resampled at moment of decay • Fixes regeneration problem • New generators for radiative K decays (IR-finite treatment of IB) • K0pmng • K+p+p0g • K+mng, eng • K+p0mng, p0eng

  5. MC upgrades: Other generators geanfi 1.7-2  1.7-3 • a0 BR fixed (was 10 too high) • wp0 cross section decoupled from f cross section • constant 8.3 nb cross section used (vs 3.1 mb for f at peak) • bug in h  p+p-g generator fixed (kinematics) • KLOE values for Dalitz plot slopes used for h  p+p-p0 generator

  6. MC production for diagnostic work • all_phys • 26300-26800: 27.6M (44.5 pb-1 at 1:5 scale) • 1st trial, old wp0 generator, E(KL crash) not adjusted • 23542-23900: 10.2M (16.5 pb-1 at 1:5 scale) • 2nd trial, new wp0 generator, E(KL crash) not adjusted • 24000-24500: 20.0M (32.3 pb-1 at 1:5 scale) • 3rd trial, new wp0 generator, adjustment of E(KL crash) • ppgphok3 • 19057-23020: 36.8M (140 pb-1 at 6:1 scale)

  7. Problems?

  8. Plans & priorities Run plan as of 29 Jan—have priorities changed? Test running with all_phys completed ppg running a new entry • Re-run ppgisr3 production (37M evts) 2½ days • New MC production: radiative f decays, 110M evts 6 days • New MC production: e+e-g, Eg > 100 MeV, 32M evts 3 days • New MC production: all_phys off peak, ~60M evts 7 days • Re-run all_phys production (260M evts, 20M done) 20 days • Re-run neu_kaon production (410M evts) 30 days

  9. How are we doing on time? • Expect data by Easter (11 April, 42 days) • ~70 days of planned MC production • This (70 days) assumes: • Running time same as in ’03 production • CPU time has increased! (10-20%) • CPU resources same as for ’03 production (60 “B80” CPUs) • New IBM machines will be available soon (fibm35-44) • 10 IBM p630 servers, 4x 1.45-GHz POWER4+ • Adds at least 80 “B80” CPUs to offline farm

  10. CPUs for MC and users Current queue configuration: kmc 52 (fibm22-34) ktest 30 (fibm 13-21) kmed 8 • MC resources needed • 60  (72/42)  1.2 = 120 CPUs • Assumes: • We start now on all nodes • 20% more CPU for job • Proposal: • All new CPUs for MC (~80 “B80” equiv.) • Keep using 40 “old” CPUs for MC • Leaves: • 12 additional CPUs for users (+33% on ktest)

More Related