Icetray a software framework for icecube
This presentation is the property of its rightful owner.
Sponsored Links
1 / 22

IceTray A Software Framework for IceCube PowerPoint PPT Presentation

  • Uploaded on
  • Presentation posted in: General

IceTray A Software Framework for IceCube. Computing in High Energy Physics Interlaken, Switzerland. The IceCube Collaboration. University of Alabama University of California, Berkeley Clark – Atlanta University University of Delaware Institute for Advanced Study, Princeton

Download Presentation

IceTray A Software Framework for IceCube

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript

Icetray a software framework for icecube

IceTrayA Software Framework for IceCube

Computing in High Energy Physics

Interlaken, Switzerland

The icecube collaboration

The IceCube Collaboration

University of Alabama

University of California, Berkeley

Clark – Atlanta University

University of Delaware

Institute for Advanced Study, Princeton

University of Kansas

Lawrence Berkeley National Laboratory

University of Maryland

Pennsylvania State University

Southern University and A&M

University of Wisconsin, Madison

University of Wisconsin, River Falls

DESY, Zeuthen

Johannes Gutenberg-Universität Mainz

BUGH Wuppertal

Vrije Universiteit Brussel

Université Libre de Bruxelles

Université de Mons – Hainaut

Stockholms Universitet

Uppsala Universitet

Imperial College, London

University of Oxford

Chiba University

University of Canterbury, Christchurch

Universiteit Utrecht

Universidad Simón Bolívar,


Amundsen-Scott Station,

South Pole

CHEP 2004

Atmospheric muons neutrinos

Atmospheric Muons & Neutrinos

  • “Atmospheric muons” from cosmic ray showers, penetrating to the detector from above

  • “Atmospheric neutrinos” from the same air showers, forming a diffuse background and calibration beam

  • Astrophysical neutrinos: interesting signal

Astrophysical n

cosmic ray

Atm. n

Atm. m

cosmic ray

CHEP 2004

Icetray a software framework for icecube



  • A neutrino interacts with a nucleus in the ice

  • A relativistic lepton is produced in the collision

  • Optical sensors map the lepton’s Cherenkov light

  • Timing, photon counting give direction & energy



light cone

The icecube detector

The IceCube Detector


1 km3 instrumented volume: 1 Gton of ice

4800 digital optical modules (DOMs) in the ice on 80 strings

AMANDA will be enclosed within the array

IceTop air shower array on the surface above the detector (80 stations, 320 DOMs)

Geometry optimized for TeV—EeV neutrinos





1400 m

2400 m

CHEP 2004

Muon tracks

Muon Tracks

CHEP 2004

Electron and tau events

Electron and Tau Events

Electron: All energy deposited in a short cascade

  • Spherical diffusion

    Tau: “Double Bang”

  • nN interaction

  • t lepton decay

  • Separated at very high energies

CHEP 2004

Software framework

Software Framework

  • Want advantages of a modern framework

    • Modularity (better maintainability!)

    • Easy to reuse code, extend applications

    • Allows user/developers to focus on specific task

    • Reliability (core functions in common, well-exercised code)

    • Common style, shorter learning curve

  • What framework?

    • Some specific requirements similar to colliders, some different

    • Detector Operations begin in February, 2005!

CHEP 2004

Reconstruction requirements

Reconstruction Requirements

  • Very sparse event information

    • Five sensors per megaton of detector

CHEP 2004

Reconstruction requirements1

Reconstruction Requirements

  • Reconstruction requires complicated techniques

    • Algorithms evolving rapidly, development distributed throughout collaboration

    • Software must be deployed at remote location, limited intervention possible

    • Desktop-to-online conversion must be easy, very robust

CHEP 2004

Reconstruction requirements2

Reconstruction Requirements

Many hypotheses, hierarchical filtering

Variable event flow, determined at run time

CHEP 2004

Monte carlo requirements

Monte Carlo Requirements

  • Events occur at random times

    • No ‘heartbeat’ analogous to beam crossing

    • Event duration ~5 µs, rate 1700 Hz

      → Frequently overlapping

CHEP 2004

Monte carlo requirements1

Monte Carlo Requirements

  • Need to overlay events from different generators, preprocessing chains

    → Multiple input streams, irregular heartbeat

CHEP 2004

Monte carlo requirements2

Monte Carlo Requirements

  • Difficult Monte Carlo problem

    • Can’t track every photon from a kilometer-long PeV muon track through a km3 active volume

    • Run special-purpose photon tracker before Monte Carlo production, use tabulated results

    • Full photon tables hard to fit in memory (would use ~200 GB tables if possible)

      → Need to hold events in a buffer, sort for more efficient batchwise access

CHEP 2004

How to drive execution

How to Drive Execution?

  • Standard “push” (declarative) execution model not well suited

    • Individual modules need some control over the flow of the overall process

    • But want to avoid coupling independent code or requiring complex signalling mechanisms

  • “Pull” (on demand) model also problematic

    • Places responsibility on framework, modules to match requests, resources: developers, not users!

    • Enumeration of types of information that can be passed: less flexibility for developers

  • Either can work, but want something simple

CHEP 2004

The icetray approach

The IceTray Approach

  • Pushmipullyu Rube Goldberg Queue-based

    • Each module has one or more input, output queues (‘Inboxes’ and ‘Outboxes’)

    • Module receives events in an Inbox, processes them and places them in an Outbox

    • One Inbox is ‘active’ → drives execution

    • Events can be requested from the ‘passive’ Inboxes

    • User sets event flow topologically at configure time, arbitrary† complexity based on module logic

    • Order of execution determined by data flow

      †Required to be a Directed Acyclic Graph

CHEP 2004

Inboxes and outboxes

Inboxes and Outboxes

  • Context of inboxes, outboxes is created by user at configure time, not by developer

CHEP 2004

Module lifecycle

Module Lifecycle

  • Module is a relatively flexible state machine

  • Default implementations are provided transparently in an inherited base class

CHEP 2004

Analysis containers

Analysis Containers

  • Each IceTray module isolated from larger environment, in own “container”

  • Interactions limited to requests for services, events, configuration, logging and errors

  • All services, etc. provided by Framework through a context object – switchable

  • Module appears to have own flow of control

  • Lends itself to threads, distributed processing

CHEP 2004

Division of responsibilities

Division of Responsibilities

  • Framework handles only low-level tasks

    • Logging, configuration, event flow, execution flow, connection of services, etc.

    • Does not need to understand modules, data

  • Modules focus exclusively on their task

    • No need to understand their role in the larger scheme of things

  • User supplies context at configure time

CHEP 2004

Icetray status

IceTray Status

  • Basic implementation complete (linear functionality)

  • In use within IceCube for simulation, online reconstruction/data monitoring (starting this winter), offline analysis

  • Implementation of more advanced features in progress

  • Code available by request

    • Uses IceCube distribution, build system

CHEP 2004

Old and new south pole stations

Old and New South Pole Stations


CHEP 2004

  • Login