Si energy calibration

[benkrikler]

Before we can get the proton spectrums on any dataset within rootana, we need to calibrate the silicon detectors. I think we agreed to just use a single set of constants for this until January, but I think we're safe to coordinate on this wihout breaking the 'blindness' of the current excercise, right?

If people are happy with that I'll make changes on Develop to calibrate the Silicon channels to convert MaxBin amplitude to Energies within the TAPs.

Does that sound ok?

[benkrikler]

Discussion on ticket #60 might be relavant to this at some point.

[AndrewEdmonds11]

Sounds good to me. I've already branched off develop (with no commits though) so should be able to merge the updates in, right?

[benkrikler]

I'm implementing the mechanism, for handling this, but I'm going to need the actual constants pretty soon. For the slow silicon, I have the calibration constants sent to me by Nam and based on elog:RunPSI2013/637.

@thnam, could we try to get the fast silicon calibration? I gather from your last emails that we don't have enough data or it wasn't of a good quality. If not, one thing we could do would be to look at the paired pulse plots and take the calibration of the slow channels and scale it by the amplitude scaling factors in those plots.

[benkrikler]

This is merged onto develop.

You need to add the calibration constants into the database for your runs. I've taken the constants for the slow silicon given to me previously by Nam and put them into the following script, which will prepare the sql statements:

[EDIT: DO NOT USE THE FOLLOWING SCRIPT WHICH HAS SEVERAL BUGS. THE FIXED VERSION IS POSTED IN ANOTHER COMMENT BELOW]

#! /bin/bash

RightChannels=( SiR{1_{1..4},2}-S )
RightGains=(    2.53 ,  2.62 , 2.49 ,  2.53 ,  7.96 )
RightOffsets=( 28.33 , 46.76 , 5.95 , 34.46 , 22.98 )

LeftChannels=( SiL{1_{1..4},2}-S )
LeftGains=(    2.61 ,  2.54 , 2.65 ,  2.54 ,  7.86 )
LeftOffsets=( 36.99 ,-21.13 ,67.41 ,-18.80 , 14.14 )

for run in $@;do
  for i_channel in {0..4};do
    echo "INSERT into Energy  (run, channel, gain, offset) values ( $run, \"${RightChannels[$i_channel]}\", ${RightGains[i]}, ${RightOffsets[i]}) ;"
    echo "INSERT into Energy  (run, channel, gain, offset) values ( $run, \"${LeftChannels[$i_channel]}\", ${LeftGains[i]}, ${LeftOffsets[i]}) ;"
  done
done

You can use the above script by saving it in a file (insert_calib_si.sh) and using the following command from the directory of the calibration.db:

sqlite3 -init <(./insert_calib_si.sh {2140..2170}) calibration.db

Replace {2140..2170} with your own run range. You can use .q or ctrl-D to quit sqlite.

Some comments:

• I still have no constants for the fast silicon and I would really apreciate help to get them made.
• I'm not sure how the calibration will handle moving pedestals. On the one hand, a higher pedestal will raise the baseline that the pulse sits on and so should be removed ok. On the other hand, since we shifted thresholds around a bit and the pedestals are all being calculated on the peak minimum value for each run, this will include any threshold shifts. I think we will need to do something smarter with the offset values then which we fill the database with, but if this is a small effect we might be able to continue without it for now.

[AndrewEdmonds11]

Thanks, Ben.

The only problem I had was that I needed to make insert_calib_si.sh executable. Also, it's probably worth noting that it takes a while.

From looking at the commits, it seems that we don't have to do anything to add the calibration since there is a default one. Can we get the energy from the TDP or do we have to get it from the TAP?

To answer your comments:

• do we have calibration data for the fast silicon or is it not good enough?
• I don't think we should worry about moving pedestals and thresholds too much for the time being. Although, maybe we should check our LLDQ picture books to make sure the Si values were not changing loads

[benkrikler]

The only problem I had was that I needed to make insert_calib_si.sh executable.

That's not a problem, that's just how bash works. Sorry if I didn't make that clear though.

Also, it's probably worth noting that it takes a while.

How do you mean it took a while?

From looking at the commits, it seems that we don't have to do anything to add the calibration since there is a default one.

Which commits and where? John implemented the part to access the database, which I've left untouched for now so I don't break his Ge stuff which will be important for us all soon. We'll need to add a generator column at some point, but since we all plan on running with the FirstComplete (I think) this should be fine.

The main thing I've added is that MakeAnalysedPulses now asks the generator to calibrate it's pulses once it's finished finding them. There's a default implementation in the TVAnalysedPulseGenerator class that will use linear calibration whose offset and gain it takes from the database. So we only need to work out the constants for this channel, stick them in the database and we get calibrated pulses. If no calibration exists in the database, the TAPs are left uncalibrated.

What default values are you seeing as well?

Can we get the energy from the TDP or do we have to get it from the TAP?

You can get the original TAPs from the TDP so you can get anything at all that they contain. But I'm guessing you're asking for a TDP method to get them directly like GetTime and GetAmplitiude? I've just added this in on develop.

Do we have calibration data for the fast silicon or is it not good enough?

I'm not very sure. If @thnam could comment that would be great. You said before, Nam, that the calibration data wasn't very good for the fast which could be an issue. But like I said above, perhaps we could calibrate the fast against the slow and using what little data we do have?

Although, maybe we should check our LLDQ picture books to make sure the Si values were not changing loads

Good idea. I just did a quick scan and:

• For the Al100 dataset, there is a change around 2880 in the thresholds on many of the silicon channels.
• For Al50a_with_NDet: No changes
• For Al50a_without_NDet: No changes
• For Al50b: No changes
• Si16P: No changes
• SiR2-1Pct, SiR2-3Pct, SiR: No changes

So the only dataset to look out for is Al100, ie. Nam's dataset.

[AndrewEdmonds11]

How do you mean it took a while?

I thought it had frozen so I cancelled it but it had been filling in the values. I just thought it worth mentioning.

Which commits and where?

Just the recent commits on develop. It looked like there's a CalibratePulse method which we don't need to implement because it already is.

But I'm guessing you're asking for a TDP method to get them directly like GetTime and GetAmplitiude? I've just added this in on develop.

Yeh. that's what I meant. Cheers.

[benkrikler]

Just the recent commits on develop. It looked like there's a CalibratePulse method which we don't need to implement because it already is.

Oh ok, I see what you're saying. That's right, I've added a default implementation. It's virtual so it could be overloaded for each generator, but I expect that almost no-one will need to do this. The only thing we need to do is make sure the calibration constants are correct in the DB, but since we have so little data, the best we can do for now is to assume the same constants for each run.

@jrquirk, this will probably work directly on your Ge TAPs as well, so you should have meaningful energy values in the TAPs since you already had the constants in the DB.

We should check the constants though by doing a similar scan as John did for the Ge detector. If we see the energy distributions drifting around in the trend-plot but the amplitudes looking fixed then we must have a calibration issue.

[AndrewEdmonds11]

We should check the constants though by doing a similar scan as John did for the Ge detector.

I think this might be a bit tough because of the low statistics and with no peak to compare to. Maybe there's another way....

Also, these values aren't in the "canonical" calibration DB (I've been using the one in John's directory) so I made a copy and added the values for my runs myself. I guess this needs solving at some point.

[benkrikler]

I think this might be a bit tough because of the low statistics and with no peak to compare to. Maybe there's another way....

It's true there's no peak, but the end points of the spectrum and the overall shape should align still and I think on a trend plot of the 1D energy spectrum for each detector that should show up quite well.

[AndrewEdmonds11]

As a slight aside, is there a summary of the calibration runs we are using somewhere? I'm looking into adding the energy resolution to the MC so that we can generate EvdE plots in MC so we can determine the efficiency of our proton cuts.

[benkrikler]

The constants I've added were sent to me in a pdf by Nam a month or two ago. I can put that on the elog if you want, though maybe Nam ought to do it since he produced them. He said at the time that the constants were based on elog:RunPSI2013/637.

@thnam, I'm sorry if you're very busy now, but it would be really great if you could help us more with this. Especially if you could point me in the right direction for the fast channels.

[thnam]

Sorry, I muted the notification.
I'm not sure what to do with the fast channels on thin silicons. But for the thick it is possible. I made a timing cut to get the muon peak and electron peak. The energies of those peaks are from the calibrated slow channel.