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.

[AndrewEdmonds11]

Hi Ben

I think there's a bug in that insert_calib_si.sh script since I have the same calibration constants in all left channels and all right channels:

3580|SiR1_1-S|2.53||28.33|||
3580|SiL1_1-S|2.61||36.99|||
3580|SiR1_2-S|2.53||28.33|||
3580|SiL1_2-S|2.61||36.99|||
3580|SiR1_3-S|2.53||28.33|||
3580|SiL1_3-S|2.61||36.99|||
3580|SiR1_4-S|2.53||28.33|||
3580|SiL1_4-S|2.61||36.99|||
3580|SiR2-S|2.53||28.33|||
3580|SiL2-S|2.61||36.99|||

I noticed something was amiss because data and MC were not matching (the proton curves were starting at different dEs).

Have you already solved this?

[benkrikler]

Hi Andy,

You're right, there were a few problems, not just that issue, but the way I'd actually declared the arrays. Anyway, here is the fixed version:

#! /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_channel]}, ${RightOffsets[$i_channel]}) ;"
    echo "INSERT into Energy  (run, channel, gain, offset) values ( $run, \"${LeftChannels[$i_channel]}\", ${LeftGains[$i_channel]}, ${LeftOffsets[$i_channel]}) ;"
  done
done

Sorry for the shoddy work everyone. At least this might explain why my results were looking so poor :)

[AndrewEdmonds11]

Well, that's one way to do a blind analysis :p

[benkrikler]

You got me! That was my intention... :p

[AndrewEdmonds11]

Hang on. Now my data plots are making less sense. In MC my proton band starts at a point where E+dE = dE. This makes sense because a low energy proton will lose almost all of its energy in the thin layer and then be stopped (depositing a small amount) in the thick layer.

Now in data, it starts at a point where E+dE > dE. Is there something wrong with the calibration data or am I mistreating the thin silicon because it's in quadrants?

[benkrikler]

By definition, if E is non-zero, E+dE is greater than dE so just that alone doesn't surprise me, but you're reasoning that E would be nearly zero makes sense, so the sum shouldn't be a lot greater than the thin.

My guess though is that we cannot detect E -> 0, since that's below the dynamic range. Our cut-off is actually much higher around 1 MeV I think. Maybe that explains it?

If you wanted to check, I'd compare your plot to what Nam has previously shown. Does it look that different?

[AndrewEdmonds11]

Our cut-off is actually much higher around 1 MeV I think. Maybe that explains it?

No I don't think so. I have a cut-off which I understand I just don't understand why it's skewed so that the lowest energy particles are depositing more energy in the thick than the thin silicon.

I'd compare your plot to what Nam has previously shown. Does it look that different?

If the plot on slide 9 of his main presentation is data then no.

To me, it looks like my thick energies are being calibrated really high (I've seen some go up to 13000 keV) so I guess my questions are:

• what are the units for the gain and offset constants?
• how do we go from the calibration runs done in elog:637 to getting gain and offsets? It looks like we only have a 5.5 MeV peak measured in each channel and I don't know what the other point is to draw the straight line.

[benkrikler]

I've posted the calibration data Nam sent me that I've translated on the elog:238 but it would be great again if @thnam could comment on these questions, and check the above values.

[benkrikler]

Oh god, sorry! My corrected version of the script excluded the thick silicon in the loop since I changed the loop counter to go from 0 to 3 inclusive, but it needs to be 0 to 4 inclusive. I've changed it in the comment above, so you can just copy and paste that again. Sorry!

[AndrewEdmonds11]

I'd already seen that and corrected it. Still no luck...

[AndrewEdmonds11]

Apologies for the weekend e-mail.

I've had a look at that elog and I don't think we're calculating the offset correctly. When I use y = mx + c with y = energy and x = ADC, I get an offset of -111.23 for SiL2-S rather than 14.14. If true, this would only be a small effect.

Anyway, I've found the cause for my problem was the pulse candidate finder... (sorry)

[thnam]

There are two other lines could be used for the calibration:

• pulser peak: should be 1 MeV
• MIPs (electrons) peak: 470 keV for thick Si. In the active target runs, the peak on the target would be $470\times \sqrt(2)$.

The thresholds on thick channels were about 50 keV. In my analysis I use a higher threshold at 100 keV.

[thnam]

Another point: the offset depends on the pedestal subtraction, so you might want to recalculate the amplitudes of calibration peaks using your analysis chain.

[jrquirk]

For the thick Si calibrations, does anyone know for each dataset which calibrations go with which? It seems we switched from a Mesytec based setup to an ORTEC based one sometime between 2200 and 3400, and there are calibrations for the "later" and "earlier" runs. @thnam @benkrikler @AndrewEdmonds11

[AndrewEdmonds11]

In the first attachment of elog:238, it says that the "later" ones are with the ORTEC setup. I'm not sure when this happened. The constants don't look that different though (if I've read it right).

Also, it's worth noting in my last comment on this issue that I noticed the constants may be slightly wrong (only O(100 keV)) so you might want to check them yourself. I can e-mail you the spreadsheet I used for this if you want.

[jrquirk]

I'm specifically calibrating for the SiR2 runs, to try to get a feel for the beam momentum once inside the chamber. And as @thnam suggested I'm running it through the chain.

I would appreciate the spreadsheet if you get a chance. When you calibrated, do you mind giving me the bullets if you remember how?