On Dec 7, 2014 9:24 PM, "Sho Uemura" <[log in to unmask]> wrote:

The systematic shift could be done by running MC normally (with the uniform ideal gain of 1.0), and running recon using the <gain>shiftedGain</gain> option of EcalRawConverterDriver, which will run the hit reconstruction with a uniform gain of shiftedGain (!=1.0). This option was added for this exact purpose, when Pelle was doing a similar study.

There's nothing built in that would do the random shift. Pelle and I talked about doing this by making a copy of the text conditions with randomly smeared gains, and running the MC with the unsmeared gains and the recon with the smeared gains. This is harder to do with the database conditions.

You could write a driver that makes new hits, as you suggest. If you want your random per-crystal shifts to be consistent between runs of your analysis, you should either store them somewhere or generate them deterministically (e.g. seed Random() with the crystal number). Maybe you've already thought about this.

On Sun, 7 Dec 2014, Kyle McCarty wrote:

Hello hps-software,

I want to perform a study on how variations in beam energy calibrations
affect trigger performance. I was going to do this by applying (for two
different studies) a systematic shift to all hit energies and a Gaussian
shift that is constant throughout the run, but random for each crystal.

What is the best way to do this within the software? Is there a way to set
the energy in the hits as they are processed? Should I create new hits and
apply change the energy? Is there already a way to do this?

Thanks,

Kyle

########################################################################
Use REPLY-ALL to reply to list

To unsubscribe from the HPS-SOFTWARE list, click the following link:
https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=HPS-SOFTWARE&A=1