BeamCalReco is back !

[rete]

BEGINRELEASENOTES

• New BeamCal background files for new L* (L. Strahinja) at 500 GeV
  • Realistic field map of 3.5 T and no AntiDID (default)
  • Realistic field map of 3.5 T and with AntiDID
• Re-activated BeamCalClusterReco processor
  • Copy all default processor parameters to steering file
  • Re-adjusted reconstruction cuts: ETPad, ETCluster and StartingRing
  • Re-calibrated energy constant
• BeamCal digitizer processor
  • Re-adjusted threshold cut and energy calibration constant
• eepair Overlay processor
  • Exclude BeamCalCollection from overlay as it is treated by the BeamCal reconstruction

ENDRELEASENOTES

TODO:

• [x] Add BeamCalCollection to list of collections to avoid in eepair overlay settings
• [ ] Adjust calibration constant in BeamCal processor
• [x] Adjust collection names in processors after the BeamCal reco

[rete]

I still need to provide the background map for B=4.0T for the small models (waiting for maps from Uwe Schneekloth).

@andresailer I have dramatically changed the ETPad and ETCluster cuts. I studied electrons of 50 GeV randomly distributed in theta in the BeamCal. I saw that by using the old cuts

• ETPad = 0.01 and 0.3
• ETCluster = 0.5 and 0.5

I get no reconstructed electrons in my output file. I went through the BeamCalClusterReco processor and I found that the cluster energy is estimated from the SimCalorimeter energy and not from the calibrated CalorimeterHits collection.

See here the energy distrubution of the BeamCalCollection out of the simulation :

If I cut at 0.01 almost all the hits are removed from the BeamCal reconstruction. I played a bit with this cut ETPad and ETCluster to get a reconstruction running but I have finally no idea of the consistency of these parameters.

[andresailer]

Yes, ETPad and ETCluster are based on the raw energy of the hits. The default values are also somewhat aimed at 1.5 TeV electrons with a lot of background, where there is not a lot of hope for finding 50 GeV electrons.

[rete]

Wait also for iLCSoft/Overlay#16 to be merged. We need to remove the BeamCalCollection from the eepair background overlay processor as it is already taken into account by the BeamCal background map

[rete]

The calibration constant for the energy will be adjusted in another pull request. @gaede : This can be merged.