I have been asked by Francesco to help with the needed work on partially refactoring the SVAC ntuple so that it matches the beam test needs. Please consider this page as a work in progress and an area for interaction.

The SVAC ntuple is described in detailed here. I can see two main topics of discussion :

  1. What entries do we want to add/remove/modify in the ntuple
  2. Do we create the ROOT file in the same way (separate executable etc...? If not, what other solution would best match our needs?

Besides, we might decide to steer the creation of this tuple via a gaudi alg rather than by a standalone execution.

Run and Event variables

Needs discussion 

MC variables

All this block seems worth keeping. Main question, I guess, concerns the parimary particle entry (from McTotalEnergy to McZDir) : Do we need to make that an array, because of the existence of several primaries susceptible to hit the CU? If yes, of which size (can't be defined event by event)?

Richard put up a table of MC variables specific to the beamtest here. These variables are currently computed and added to the merit tuple in here.

 After discussion at SLAC, it was agreed tha   these would stay in the merit tuple, and that there is no need to duplicate them in the BeamTestTuple.

Vertex variables

Hiro asked that the VtxThetaErr and VtxPhiErr be added to the BT tuple. There are equivalent avariable for Tkr1 in the merit tuple, but not for Vtx. Investigating....

TKR variables

All to be kept as is. Needs to redefine the tower array index size from 16 to 4. Given the fact that the towers will be in bay 3 and 4, it would be confusing to use an array of size 2. It seems wiser to live with 2 columns filled with default values.

CAL variables

 All to be kept as is. Needs to redefine the tower array index size from 16 to 4.

In addition, Jan proposed to add a few variables (see below).

Together with David we discussed putting the  calTuple entries into the beamtestTuple: as follows --

currently the SVAC tuple contains the array   CalXtalEne[tower][layer][col][end]  where end=0,1,2 contains the same value three times (sic).

The proposal for the beamtuple is to have end=0,1,2,3,4 where

0 would be the "best energy estimation for the log, using the info from both crystal ends", that is, what is currently in the SVAC tuple

1,2 would be MevPerAdc*(ADC-PED) that is, MeV-like values for the single ends. This is what is currently in the CalTuple, in CalXtalFaceSignal[16][8][12][2].

3,4 would be ADC-PED for the  single ends. This is what is currently in the CalTuple, in CalXtalAdcPed[16][8][12][2].

If we make these additions to CalXtalEne in the beamtuple then we will no longer have any need for the CalTuple.     Signed, David Smith, 18 May 2006. 

 

This is actually a complex case, and we decided that we would keep the CAL tuple together with the BeamTestTuple. 

- CalTuple should have a way to set itself for 4 or 16 towers. It seems easy to do so : This still needs implementation.

- BeamTestTuple v0r0p3 added the CalClusterLayerData variable, as per Jan's request. 

ACD variables

The ACD needs an array of size [10][2], the first index for tile number, and the second for PMT. Note that only 5 tiles will be used, but we need the complete mapping of the FREE board, as we dont know yet which channels will be used. Note also have ID X between 0 and 9
and 2 of them will only have a single PMT. Again, it seems wiser to avoid creating a mapping to decrease the size of the array.

 See Alex's proposal in the comment below. This still needs implementation. Eric agreed to put an implementation in the recon ROOT file, so that BTTuple can have access to it.

Ancillary Detectors (AD) variables

The following is the INFN proposal for the set of ancillary detectors data variables, for all setups; variable names have a prefix specifying the detector they belong to (AD for general ancillary detector system info, TAG for gamma-tagger, TRD for Transition Radiation Detector, CRNKV for cerenkov counters, SCINT for plastic scintillators for trigger/veto)

 

Variable 

Description

 AD_TIMESTAMP

 Trigger Time-stamp measured in the AD system

 AD_PID

 particle ID code from AD data (use same as G4 particle code?)

 TAG_PHI_IN

 electron incoming angle before magnet measured by silicon chambers 1 and 2 in the bending plane

 TAG_THETA_IN

 electron incoming angle before magnet measured by silicon chambers 1 and 2 in the bending plane

 TAG_XYZ[3,4]

 X,Y,Z coordinates of highest cluster in each of the four silicon tagger station

 TAG_XYZ_IN_CU[3]

 X,Y,Z coordinates of photon impact point on CU (assuming photon collinear with e beam)

 TAG_DPHI

 electron deflection angle after magnet in the bending plane

 TAG_EGAMMA

 photon energy (Ebeam - Edeflected_electron)

 TAG_EGAMMA_ERR

 error on photon energy measurement

 CRNKV_PHA[2]

 pulse height amplitude in the 2 cerenkov

 SCINT_PHA[8]

 array of floats - PHA for scintillators in the setup (8 is a placeholder for a reasonable number, might change)

 TRD_NUM[16]

 array of floats - nb of straw tubes above threshold in each of the 16 TRD station

 

Waiting implementation of the LDF to TDS to ROOT persistency (place holders in the ntuple are implemented).

  • No labels

3 Comments

  1. Unknown User (conrad)

    Two suggestions for new cal variables:

      - The light yield on the left and right diode (which could help to check the assymetry/position relation)

     -  The layerwise energy centroid: this would allow a more detailed check of the moment analysis, since we can prope different positions in the shower

     

     

      
     

  2. Unknown User (eduardo)

    The GEM variables in the SVAC ntuple should be kept. Note that the arrays need not be from 0 to 15 but from 0-3 , People should be aware that the array index corresponds to the TEM connector ID in to the GASU. Therefore, indices 3 ,2 and 1 will be filled, but index 0 is the one that corresponds to the dummy mass (no CAL present). We can choose to drop index 0 with the understanding that is empty or remove it.

  3. Johann Cohen-Tanugi

    Alex's email May 17 :

    Hi Johann,

    I am very  happy with SVAC ACD ntuples, many thanks to Eric Charles, but I think that we can eliminate many of them for the beam test  since it is not a task for a beam test to determine ACD efficiency.  Let me think a bit which ones to keep.  We are not going to have a tile on the path of the beam, so all ACD hits will be caused only by a backsplash.

    The main ACD task is a backsplash effect, and for this would be great to have some new variables:

    for each  tile with the hit to calculate three numbers:
    1. angle between the reconstructed track and the line connecting the tile center and track entry point in the calorimeter

    2. angle between that line and tile plane

    3. distance between tile center and track entry point in the calorimeter

    It is probably be sufficient to calculate them for first two tracks only, and only for tiles which have a hit. Philippe may want to add something else.

    the idea is that backsplash in given tile depends on the distance from the calorimeter and the angle.

    thanks a lot