JetWeb on the Grid Ben Waugh (UCL), GridPP6, 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/ , also submitted to Comput. Phys. Commun. Based on HzTool (J. Bromley et al., Future Physics at HERA, vol 1, ) Database of data, MC and comparisons Web interface allows access to DB and submission of jobs to generate more MC plots

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.

JetWeb home page

JetWeb Search Form

JetWeb Search Results

A JetWeb Fit

JetWeb Plots

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

The JetWeb Server

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.