AnitaAnalysis Framework

Introduction

One thing that came out of the December 2015 ANITA analysis workshop at UChicago was a desire for some tools to facilitate interchange between different analyses. This framework attempts to solve some of the problems.

Right now it consists of three main parts:

• a standardized filtering framework
  - a common output format
• a utility class for efficiently working with waveforms

Installation and Configuration

AnitaAnalysis depends on ROOT, libRootFftwWrapper, eventReaderRoot, and eventCorrelator. It is assumed that those are compiled and availabile in ANITA_UTIL_INSTALL_DIR or elsewhere within the paths searched for by your compiler. You probably installed using the build tool so it doesn't matter.

Some options meant to be set by end users may be set using ccmake or cmake -D

In particular, one may:

• enable OpenMP support. OpenMP is a #pragma-based multithreading system, which the filter framework can use. This is useful in the case where one has more cores than ANITA runs.

Filter Framework

The filter framework is intended to provide a common, yet flexible, way of filtering ANITA waveforms. The basic building blocks are

FilteredAnitaEvent

A FilteredAnitaEvent stores the waveforms as well as everything necessary (we hope) to make decisions about what to do with it. It holds both the raw waveforms as well as the final filtered one. It can also be instructed to hold intermediate steps, if that is desired.

FilterOperation

A FilterOperation is a transformation on the waveforms in a FilteredAnitaEvent. It may do the same thing to each waveform (in which case you can use UniformFilterOperation), only do things conditionally (in which case you can use ConditionalFilterOperation) or do whatever you want (in which case you have to do a bit more work). It has access to everything the FilteredAnitaEvent knows.

Each FilterOperation has a tag and description, which are supposed to be meaningful.

Additionally, each FilterOperation may define output quantities (doubles or arrays of doubles) which may be saved to an output tree. This could be useful for diagnostics and eventually cuts.

FilterStrategy

A FilterStrategy is a series of FilterOperations, and handles the creation of output trees.

Usage

The intended mode of usage is to that some FilterOperations are implemented, then added to a strategy. For each event to be processed, a FilteredAnitaEvent is created from the raw data and the strategy.

   TFile out("out.root","RECREATE"); ; 
   FilterStrategy strategy(&out); 

   MyAwesomeFilterOperation filter1(foo,bar,42); 
   MyEvenMoreAwesomeFilterOperation filter2(foo,bar,42); 
   strategy.addOperation(&filter1); 
   strategy.addOperation(&filter2); 

   FilteredAnitaEvent event(usefulAnitaEvent, &strategy,adu5pat, rawAnitaHeader); 

Output Format

The framework defines AnitaEventSummary, which is intended as a common output format for different analyses. It is meant to contain all the information necessary to make cuts and then run through a clustering algorithm.

AnalysisWaveform

An AnalysisWaveform is what is actually stored within a FilteredAnitaEvent. It is a multi-representation view of a waveform, where coupled versions of the unevenly-sampled waveform, the evenly-sampled waveform and the Fourier Transform of the waveform are kept and calculated on the fly when necessary. By abstracting away the multiple representations, it is possible to elide unnecessary transforms in some cases. For example, multiple filters operating in the Fourier domain can avoid transforming the waveform and back and forth if they are applied one after another.

Responses

Responses are in the data directory.

Each response type will have a name, which is used in the enum allowing selection, the directory where data is stored and the name of the option in the config file.

e.g. enum value ResponseSingleBRotter -> /data/SingleBRotter  -> "SingleBRotter" in UCorrelator config file 

The files will be plain text files, but of different types. The type is encoded by the suffix. Not all are implemented yet.

Suffix:          Meaning and Format: 

  .imp           Impulse response, in mV andns, in a format that can be read in the TGraph constructor (e.g. whitespcae separated ns mV values) 
  .freq          Frequency response, in GHz, dB and radians (whitespace separated) 
  .iir           IIR transfer function. The b coefficients on one line and the a coefficients on the next. 

The prefix denotes what the impulse applies to. It could be: 

  all - This response will be used for everything
  allHpol   - this response will be used for all HPol 
  allVpol   - this response will be used for all VPol 
  [01..16]{B,M,T}{H,V} - This response will be used for this channel e.g. 13BV 

In addition there is in theory support for off-axis responses. These are denoted with an underscore after the prefix followed by the angle in degrees. If no underscore is used, it is equivalent to _0.