Silicon TPulseIsland Amplitudes below threshold

[jrquirk]

In the pulse amplitude plot for Al50a-without-NDet2 and a couple other data sets we noticed some detectors had the following behavior

We can look at the pulse amplitude distribution for, say, run 3200 and we see the same problem, just in 1D

Amplitudes to the left are okay because the trigger is the red line and the polarity is negative. To the right doesn't make sense. How can the amplitude of a pulse not be at least the trigger? So I used Ben's export pulse module to look at pulses that returned an amplitude greater than 2700; this, again, should not be possible, because the trigger threshold according to the ODB is

[/Equipment/Crate 9/Settings/NFADC 82/Channel 2]
LED Mode = INT : 4
**Lower threshold = INT : 2645**
Upper threshold = INT : 4095
Pulser period = INT : 500000
Trigger mask = INT : 1
Presamples = INT : 5
Stretch samples = INT : 30
DCM phase = INT : 10

Here's an example of such a pulse

So we can squash any ideas that maybe pulse stitching or crazy triggering is happening; clearly this (and all the other pulses) at least reached the trigger threshold. The amplitude should be equal to the trigger then, since that's exactly as high it got. But in fact, the amplitude returned has been, for all of the huindreds of pulses I've examined from run 3200, equal to the first bin. And this is because the corrected pedestal is set to above the trigger threshold; the reason why is evident from the shapes plot

Because of the hotspot right at the trigger (we're triggering on noise I assume), that's where odb_check assumes the pedestal is because the projection just is sky-high there.

The amplitude is got in the MDQ_Amplitude module

const std::vector<int>& theSamples = (*pulseIter)->GetSamples();
int peak_sample = (*pulseIter)->GetPeakSample();
hDQ_Amplitude->Fill(theSamples.at(peak_sample));

And TPI::GetPeakSample()

double pedestal = GetPedestal(10);
int trigger_polarity=GetTriggerPolarity();
int peak_sample_value = 0;
int peak_sample_pos = 0;

for (std::vector<int>::const_iterator sampleIter = fSamples.begin(); sampleIter != fSamples.end(); sampleIter++) {
  int this_height = trigger_polarity*(*(sampleIter) - pedestal);
  if ( this_height > peak_sample_value ) {
    peak_sample_value = this_height;
    peak_sample_pos = sampleIter - fSamples.begin();
  }

Because no pedestal-subtracted bin is ever higher than zero, as the "corrected" pedestal is above them all, sample 0, the default, is assumed to be the sample of the maximum.

If I change the third line of TPI::GetPeakSample() to peak_sample_value = -9999 I get no problems, and this issue goes away.

Plan

Today I'm doing two things:

1. Changing the ODB checker to only look at the first few samples
2. Fixing TPI::GetPeakSample()
3. Edit: Check MaxBinAPGenerator for similar issue

[AndrewEdmonds11]

Good sleuthing, John. Does this mean we have to stop production and restart?

(Also, I put an issue (#63) for this on the day we had the meeting but it's poorly titles so I'll close that one and we can keep discussing here)

[benkrikler]

Looks great John!

Would you also be up for looking into the MaxBinAPGenerator in rootana then? It uses the same algorithm as GetPeakSample, and so it could well suffer the same problem.

[jrquirk]

@AndrewEdmonds11

Does this mean we have to stop production and restart?

I don't know. I think so, I would say do production this weekend. But we should also look into some of the other issues so that this doesn't happen again.

(Also, I put an issue (#63) for this on the day we had the meeting...

I'm not going to lie, I was so excited when I finally found out what the problems were that I was tunnel visioned when I posted the issue.

@benkrikler

Would you also be up for looking into the MaxBinAPGenerator in rootana then? It uses the same algorithm as GetPeakSample, and so it could well suffer the same problem.

I edited the original post to have that included in my plans.

[benkrikler]

I just remembered Andy and I looking at this in the run.

If I change the third line of TPI::GetPeakSample() to peak_sample_value = -9999 I get no problems, and this issue goes away.

You need to consider the trigger polarity as well so you flip the sign of that number accordingly. We did that to begin with, but i think the trigger polarity was a bit dodgy so it gave us some sort of headache.

[benkrikler]

Sorry to keep posting (yay, hogging the thread! ). I remember finding the std::maximum_element algorithm. You could use that or the minimum_element equivalent depending on the trigger polarity. It might be slightly faster as well I suppose.

[jrquirk]

The trigger polarity is wrong in some of the original ODBs, which is what prompted me to try and correct it in odb_check.

Currently TPI::GetPeakSample does take into account trigger polarity, which is why 0 was used as the default I imagine. But if the trigger polarity is wrong, there's no way to know in this method. Another problem will just crop up until it's fixed.

And I'll try to use those max/min methods.

[benkrikler]

There's also a minmax_element method in that case. We could make plots of both values and only use the correct trigger polarity one.

[jrquirk]

@AndrewEdmonds11 @litchfld

This goes back to the ever popular issue of how to determine the pedestal; from the total projection or first few bins. To fix this in the odb checker I can't use the projections histogram on file; I'll have to take the shapes histogram and make my own projection.

[jrquirk]

The odb_check program has been changed so that the pulse heights distribution imaged in the OP is now corrected

There is still the TPI change and MaxBinAPGenerator to do.

[AndrewEdmonds11]

Ok. This looks like we'll need to redo our alcapana production to get the new corrections. So let us know when everything's ready and we'll go back and do that.

[litchfld]

The push shape plot is concerning, if that's what the majority of the pulses look like it becomes pretty meaningless to even speak about a pedestal with an accuracy of better than 100 counts. The first bin must of course be 'below' threshold because it's in the pre-trigger window, but how do we know it is the actual pedestal (i.e. the rest value of the channel when there is no noise)?

The existence of a trigger guarantees we see a large number of samples just above it because every pulse must contain at least one sample above trigger threshold, at an average value of _binwidth x gradient / 2, and probably another as the channel returns to the zero point. But the sample window should be wide enough that---except in cases of unusually high pile up---the wave form will have clearly returned to the zero point. Therefore each pulse should contain several 10s of samples at the pedestal value, more or less by definition. If it doesn't then there are a few possible causes

1. The threshold is too low, in which case the real pulses will not correlate with the start of readout because the system is normally already reading out when a pulse arrives.
2. The window is too short, so the waveform has not returned to neutral by the time digitisation stops.
3. There are other kinds of noise pulse, that are at as long as the signal window or longer, these must be common, but not so common that they just average out and become a component of the pedestal.
4. The threshold is far to high, such that only huge pulses are recorded, which are too big for the sampling window

Of these the pulse shape plot suggests it is case 3 or possibly case 1. (If it were case 1 it is likely to exceed the DAQ bandwidth, so we would probably throw out the data anyway.) If it is case 3, the the first bin is likely a better estimate of the pedestal, but not necessarily the right one, because you can't be sure the detector was quiet before the pulse began... If such long noise spikes are a possibility we probably need to examine pulses with large amplitude (thus hopefully no noise spikes) and fit them to determine the true pedestal. Which is fine, but maybe too slow for an automated DQ check.

[jrquirk]

Yeah, pretty much we're getting the value of the pedestal when the noise existed to trigger it like this. It'd be nice to just have like 10000 samples in a row or something.

...we probably need to examine pulses with large amplitude...

Could we put a software threshold in that's larger, make a new shapes histogram, and then get the pedestal? I don't plan on working on this now, but cutting out the noise sounds like a good idea. And we could compare it to what we get from before.

[jrquirk]

I think MaxBinAPGenerator needs more work still, but I modified it in accordance with the list in the OP. I plan on merging this Sunday night barring any vetos based on #96.

[jrquirk]

Done.

[litchfld]

Could we put a software threshold in that's larger, make a new shapes histogram, and then get the pedestal? I don't plan on working on this now, but cutting out the noise sounds like a good idea. And we could compare it to what we get from before.

Yeah, I think that may be the way to go for analysis. But it's not so necessary for the DQ stuff; we just want to have an idea whether channels are misbehaving. Crude and fast is good for now, but better algorithms for the corner cases when we come to do real analysis.

[AndrewEdmonds11]

I'm just looking through the new IslandAmplitude plots from production run 3 and there are still a few negative amplitude pulses. Adding the new version of John's plot in the first post, you can see there is a massive reduction. I don't think this is enough to reopen the issue but thought it best to mention it.