Offline Group Report on Run 1B Preparations

The Offline group has responsibility for:

1. Offline Software Development

2. Production Processing of Data

3. Dataset Management and Distribution

4. Code Distribution (VAX and UNIX)

5. Central Computing Resources

6. Analysis, Display and MC software tools

This report summarises the status of these activities. Details can be found in minutes of:

• Offline Librarian Meetings

• Software Coordination and Management Board

CDF Collaboration Meeting January 14, 1994

Software Development and Management

Offline code development has involved a number of dedicated physicists and programmers:

• Liz Sexton and Flavia Donno (utilities and maintenance)

• Peter Berge and Aseet Mukherjee (tracking)

• Kevin Einsweiler (calorimetry and electrons)

• Bob Blair and Steve Kuhlmann (CES and CPR)

• Dave Stuart and Paul Derwent (SVX and SVX’)

• Phil Schlabach, Tom Westhusing and Jim Bellinger (CMU and FMU)

• Eddie Kuns and Guillaume Unal (taus and top tagging)

• Tom Phillips and Anwar Bhatti (Met and jets)

• George Sganos and Marjorie Shapiro (CDFSIM, QFL and DIC)

• Eve Kovacs, Andreas Warburton and GP Yeh (DF / display)

• Ken Ragan (geometry and CDFSIM)

• Steve Vejcik, Carla Grosso-Pilcher, Kevin Burkett and Bill Badgett (trigger)

• Rick Wilkinson and Don Benton (E L and UIPACK) ...and many others

Software Development (cont.)

The development work has focused on:

• Upgrade algorithms for Run 1B detector

• Keep code backward compatible with Run 1A

• Reorganise and clean-up to ease maintenance/portability • Compatibility with CERNLIB, new platforms (eg. Alphas’s)

Code is now in reasonable shape

• Major reorganisation are complete

• Production algorithms installed and being validated

• Virtually ALL code is UNIX/VMS/Alpha compatible

• Code is fairly tidy (helps distribution and management)

Being released as “frozen” versions

• VERSION 7.09 last release specific to 1A (“6.15 tacking”)

• VERSION 7.10 has all known Alpha fixes

• VERSION 7.11 being validated as first Run 1B production release

New versions released on a timescale of 2-3 months

Production System and Data Processing

Liz Buckley and Stephan Lammel lead Production Group

• Responsible for Stream A, B and C processing

• Creating the split PAD files for the specified datasets

• Providing split DST tapes for specific samples

Bringing up two I/O servers that will “feed” a farm of worker nodes

• SGI server is now configured and being tested

• IBM server is still being actively configured

• Splitting stages are now being defined as capability of sys-

tems is better understood

Production processing and Splitting is a large job! • Have 3 grad students involved

• Getting utilities support from CD programmers

– Mark Leininger and Randy Herber (S I, cdfcp, CDFSGA)

– Marilyn Schweitzer (tape handling-OCS)

– Bob Yeager

Production System (cont.)

Performance Goals are:

• Process Stream A data within 24 hours of data-taking

• Have Stream A PAD/DST files available within few days • Keep Stream B processing take place as soon as possible • Have Stream B PAD/DST tapes available within a week

Working with Dataset Task Force to optimize system design

• Are working on a detailed dataflow plan

• Will match physics groups requirements with system capabilities.

Dataset Management and Distribution

Dataset Task Force is responsible for

• Dataset definitions for Stream A, B and C

• Management of SILO and FATMEN

• Allocation of disk resources

• Coordination of data splitting and tape copying

Duke group has taken responsibility for the whole effort

• Wolfgang Kowald (tape copying “czar”)

• Tom Phillips (dataset definitions)

• Bill Robertson (SILO management)

A “STRAWMAN” dataset proposal has been circulated for over a month

• Describes the datasets

• Outlines the unsplit DST and PAD tapestreams

• Currently being fine-tuned with production group and physics conveners.

Production Validation and Monitoring

Validation Task Force responsible for validating production code and developing monitoring software and procedures

• Doug Benjamin, PKS responsible for executable

• Aesook Byon managing validation data areas

• Fumi Ukegawa doing cross-platform validation

• Hans Wenzel and Brian Harral working on monitoring code

Working with PHYSMON group to implement realtime data and production monitoring

• Running PHYSMON / VALPLOTS on Stream A production o/p

• Offline CO on shift will be checking monitor job o/p’s

• Goal is to get 24-hour turn-around on Stream A results • Reporting to SciCO and PHYSMON pager

• VALPLOTS also run on Stream B o/p – Offline CO will also be checking this

Validation (cont.)

Current Status of executable

• Runs on > 103 events without crashes

• Cross-platform validation shows almost everything is working exactly the same on VMS and UNIX (same bugs, etc.)

• Only apparent difference in SVX reconstruction

• Hope to freeze executable in two weeks

• Start testing on production system next week

Working on definition of Offline CO’s tasks

• Will be of order two weeks before first-order system in place • PHYSMON group actively getting some monitoring under-

way

Code Distribution

Have “unified” the VAX and UNIX code distribution system

• Petar Maksmovic has developed the VAX based code distribution system

• Stephan Lammel been responsible for UNIX-based system • Much of this is based on work by Flavia Donno (boy, do we

miss her help!)

• Koralie Hill put in alot of effort over summer

• Helped by many people who tested distribution to Alpha’s

Systems seem to be working quite well:

• Requires constant care to ensure everything works

• Advantage is that we now know what code is running where • Have alot of subscribers to both “flavours” of service

Central Computing Resources

JJ and Eric Wicklund have taken lead role in managing central computing resources FNALD provides enormous resources

• Significant CPU power, Disk and I/O peripherals

• Software development platform for virtually all code

• Challenge is how to maximise its utilisation

Reorganising disk on the cluster and satellite nodes

• Provide dedicated FATMEN server and documents fileserver • “LOOK” area for > 48 hours of Stream A raw / processed

data

• Provide splitting hardware resources for physics groups

• Increase SILO staging space on FNALD to ∼ 65 Gbytes • Provide data area for Stream A pads

Have to use satellite nodes in most efficient way

• Make their disk more accessible (export to rest of cluster)

• Allocate to physics groups for splitting and analysis work • Keep CPU as close as possible to datasets

Have to make most effective use of trailer VAX clusters

Central Computing (cont.)

CDFSGA also provides significant analysis resources

• STK SILO interface being commissioned – have ∼ 65 Gbytes of staging

• each physics group has ∼ 4 Gbytes of disk space

• access to 8500 tape drives

System reliability looks like it is improving

• Resolved earlier hardware problems (bad CPU board)

• Fix system problem with disk mounts

Encourage people to migrate analyses to this platform

• Bottom group has successfully utilised resources

• Support is now much more coherent

• Presents challenge of how to integrate with UNIX workstation cluster

Analysis Tools

MC tools are actively being developed

• Priority is on getting latest versions of generators available • Ongoing maintenance on QFL and CDFSIM simulations • Have to work on better coordinating MC dataset generation

DF/Display code being continuously developed

• Move increasingly to X environment

• Working to provide more enhanced features (eg. SVX’ display)

Group working on Computers for Analysis Project (CAP)

• Lab priority to push on parallel I/O systems

• CDF and D0 mandated to learn how to use prototype systems provided by IBM

• Effort is being spearheaded by Penn group – Roque Olivera modifying CDF utilities

– Working out ways to integrate hardware into CDF soft-

ware environment

• This may be useful for Run 1B but no promises...

Outlook and Conclusions

Offline effort still is severly personnel limited

• CDF will start seeing impact of this now as people who are over-committed start causing schedule slippage

• Existing effort sufficient to handle highest priority tasks – Optimisation of system resources will suffer

– Handling lower-priority problems will take longer

– Data accessibility will be place where one will see the impact!

What can collaboration do?

• Physics groups have to organise their dataset priorities

• Provide manpower for dataset management

• Institutions provide more personnel to critical tasks such as: – production group

– code distribution

– data monitoring and validation