160 likes | 236 Views
JetWeb on the Grid Ben Waugh (UCL), GridPP6, 2003-01-30. What is JetWeb? How can JetWeb use the Grid? Progress report The Future Conclusions. JetWeb. A WWW Interface and Database for Monte Carlo Tuning and Validation
E N D
JetWeb on the GridBen Waugh (UCL), GridPP6, 2003-01-30 • What is JetWeb? • How can JetWeb use the Grid? • Progress report • The Future • Conclusions
JetWeb • A WWW Interface and Database for Monte Carlo Tuning and Validation • See J. M. Butterworth and S. Butterworth,hep-ph/0210404, also submitted to Comput. Phys. Commun. • Based on HzTool (J. Bromley et al., Future Physics at HERA, vol 1, 611-612) • Database of data, MC and comparisons • Web interface allows access to DB and submission of jobs to generate more MC plots • http://jetweb.hep.ucl.ac.uk
What is JetWeb for? • Final state in (esp. hadron-hadron) collisions poorly understood. • Hadronization not calculable in perturbative QCD. • Monte Carlo generators (e.g. Pythia, Herwig) are valuable, but have many free parameters. • How do we know which predictions to trust when planning for future colliders? • Tune to existing data, but which data?Different models (fail to) describe different measurements. • Automate procedure: allow comparison of new MC (or set of parameters) with experimental results stored in a database.
HzTool • Developed in HERA Workshop to enable comparison of data with existing and future MC generators. • Routine written in Fortran for each analysis: fills HBOOK histograms from generated events to compare with measurements. • Range of data already included: H1, ZEUS, UA5, OPAL, CDF, D0. Contributing authors also from ATLAS and Linear Collider. • Still need more analyses from more experiments to be included. • Longer-term: move to OO framework?
What does JetWeb add to HZTOOL? • Easier access via WWW interface. • Expanding database of existing data, predictions and comparisons. • Reduces duplication of effort and computing resources. • Scalable design to keep up with new data and models.
The JetWeb Server • Java object model • Java servlets running in Tomcat container • Data underlying model stored in MySQL database. • MC: Model, Logparms, Logfile • Data: Paper, Plot, DataPoint • Comparison: Fit
JetWeb on the Grid • Processing power: • Currently submit jobs to separate batch farms at Manchester and UCL. • CPU intensive: as use increases, need more power. • Grid should enable transparent access to a wider range of resources. • Small(ish) self-contained executable: run almost anywhere. • Users could submit jobs, using their own certificates, to any resource they are entitled to use. • Storage • Make database accessible as a resource in its own right. • Use Grid mechanisms to mirror data for faster and more reliable access.
The Story so Far • Writes out Grid scripts as well as PBS/NQS. • “Semi-automatic” procedure: • shell script submits jobs (sometimes) • output retrieved by hand • Limited success • teething troubles with scripts • frequent failures of Grid components (RB, LB, VO server) • difficult to configure Grid node (CE, SE) correctly • Four jobs run so far on GridPP testbed via IC and CERN RBs. (At UCL, Manchester, Oxford – thanks!) Many more to come.
The Future • More automated job submission and output retrieval • Running jobs with user-provided proxy certificates • Something similar done in “GUIDO”? • Grid storage and database access • Spitfire? • OGSA-DAI? • Combine JetWeb DB with more general DB of results (Durham)
Conclusions • Gathering useful experience, but progress is slow. • Hard work getting anything to run • lack of documentation → hard for non-expert to use • failure of Grid components (but more stable now) • Need more (wo)manpower, more powerful web and DB servers, more expertise! • Well, it is a TESTbed, and things should become easier as we move towards a production Grid.