Noise Trend Plot

[AndrewEdmonds11]

It would be nice to have a trend plot of the noise in each channel. This should be possible in the picture book macros and would not require a re-run of alcapana.

The plots hDQ_PulseShapes_ProjectionY should be used to determine the noise in each channel and be plotted.

If we are going to re-run alcapana anyway, it would probably be best to include this in MDQ_PulseShapes anyway

[jrquirk]

I don't know if I understand completely how this is going to be done actually. Are we going to take the ProjectionY, but only of the first 4 bins in the x direction?

[AndrewEdmonds11]

Do we not just take the width of the peak? The peak being the pedestal and then the spread around that being noise?

I think we can also take the first four bins in the x direction of the 2D histogram and take the width there. Would that be better?

Any ideas, anyone?

[benkrikler]

Do we know the length of the presampling on each channel? Could we look at the projection of the persistency plot (where we overlay each waveform for a run on one channel) going from the start of the waveform up to the presampling length minus some value in case there's trigger jitter etc. Or you could take 90% of the known presample length perhaps?

Also, as well as the RMS noise (the width of the peak), a similar plot showing the mean of the peak might be interesting to see if the pedestal shifted around and by how much...

[thnam]

For FADCs, the number of presamples are fixed (4*N) in the ODB. The keys look like this: /Equipment/Crate 9/Settings/NFADC 83/Channel 4/Presamples But the actual number of presamples may be different by +/-4 I think.

[jrquirk]

The width of the total projection would have the pulses in it.

[benkrikler]

So don't project the whole x-range, just project 90% or so of the known presample range.

[AndrewEdmonds11]

I'm now confused about everything. I though that we take this:

and projecting onto Y (zoomed in a bit):

Then we take the width of that peak (I guess using ROOT would be the best bet which would mean it can't go in the alcapana module itself but we could do it in the picture book ROOT macros (which is turning into a horrible piece of code...))

Am I missing something about the presamples?

[benkrikler]

Nice to actually have a concrete example.

So that long tail towards lower ADC values in the second plot comes from the fact we're also projecting the actual pulses. If you only project from 0 to around 17 ns in the top plot then you would remove a lot of that tail and get a more reliable peak. The 17ns is a guess from the above plot. It comes from the length of the presampling so thats where that comes in.

Having said that, the peak in that projection is so prominent that I would not be worried about capturing the pulses in the projection. Fitting the peak directly is probably good enough. Would that be true in general for all channels and all runs though?

[AndrewEdmonds11]

Looking through the rest of run 2873, it seems the peak is always prominent but not as clean for the Si channels. Also, a correction to my previous comment, we obviously can use ROOT in alcapana... (I have no idea what I was thinking)

Below are a couple of examples:

and

[jrquirk]

When you take the ProjectionY, it takes as an argument first bin and last bin. The RMS in the stats box can change by quite a bit. A gaussian fit to the muSc projection from run 3275 went from sigma of 2.6 if we only used the first 10 samples to 3.3 if we used the whole pulse. If we just take the RMS from the stats box, which is quicker, we have a similar change. And since we're posting pictures...

[AndrewEdmonds11]

So are you saying we should just take the first 10 samples for the plot that goes in the hist file? Would this also make it easier to get the pedestal in your ODB checker?

[jrquirk]

The same logic applies to both. As for the number of samples, I couldn't say what the best choice is there. I just wanted to illustrate that for at least one detector the noise can be affected by how much of the x-axis you integrate. The position of the peak itself hasn't moved (though the fit value for the peak has).

You included the shapes plot in the LLDQ checks, so the separate projection plot isn't necessary in the alcapana output.

[AndrewEdmonds11]

For the picture books, I think it's easier if the projection plot is in the hist file. This means we can calculate the noise from it and put that value into another histogram, which then makes it easier to turn into a trend plot with the ROOT macros we have now.

[AndrewEdmonds11]

So I went looking in the ODB for the number of presamples for the BU and UH CAEN and it seems that there isn't a setting for them. For the BU CAEN it seems we can probably take a hard-coded number since they look pretty much the same.

But for the UH CAEN (with the Ge channels) it looks a lot messier:

You can see at the start of the x-axis there seems to be quite a wide spread. However, the projection looks OK:

And I have a gut feeling this will disappear when we work out what's happening with the CAEN pulses that are less than they should be (i.e. stitching them together)

[AndrewEdmonds11]

A thought that's just popped into my head. Is there any reason we shouldn't hard-code the number of samples for the FADCs as well? It would make the code easier...

[benkrikler]

If it was kept constant then it's probably not too bad to just 'hard code' it. But by that, at least wrap it in a GetPresampleLength(detector) method and then include an If...else block inside that to check if its an FADC or CAEN.

That UH plot is such a mess though. I don't think stitching will help alter the position of the pedestal. I remember Nam mentioning something about a baseline reset circuit in the Germanium. Is that what we see?

By eye, it looks like the UH trigger has about 100ns of presample. Is that the value you'll use?

[benkrikler]

And to go back a few comments, I don't follow why it's better to have it in alcapan. Can't you get the projections from the persistency plot already in alcapana within the picture book macros? Then, still in the macro, fit the peak on the projection and take the fit values into the noise trend plot? I think that's what John was suggesting. Do you gain much by adding them into the alcapana histogram output (other than file size)?

[AndrewEdmonds11]

I don't think stitching will alter the position of the pedestal but it might affect the noise as John showed.

I was just going to use a certain number of bins. Also, I was planning on using the same number for each channel to make the module a little tidier. If I were to add a function is it best to just have it in the module itself and not in TSetupData? I want to avoid adding stuff to our global ROOT object because I don't know if it will screw everything up.

Also, do we want to have the pedestal stored in a histogram so that we can produce a trend plot of that as well? This seems like it's just repeating what John's doing with the ODB checker though so I'm not sure.

To answer the comment you just asked, the way the trend plots are generated is that the macro goes through all the 1D histograms stored in the hist files and creates 2D histograms from those. I can't think of an easy way to add what we want into this without making the macro even messier (you can take a look at GenerateTrendPlots.C if you want a heart attack ;) )

[benkrikler]

I wouldn't add a new function to TSetupData, that poor class has seen enough abuse I think... Stick it in your module file somewhere. And to be safe, make it static which will avoid future link time conflicts if we implement an identically named function somewhere else.

I think having a histogram that plots the change in the pedestal itself would be quite helpful. I think we need that and the development of the rms noise and the plot of the trigger thresholds in parallel to really be clear about what was going on with triggering. If John already makes plots then could we just use those in the picture books?

So the 2D persistency plot is not stored in the hist files as well? If it is then I don't see why you couldn't go from there for each run and build up a 2D plot of the noise for each channel in each run. But this is way more your domain than mine so if you don't want to grow your macro more thats up to you. I'll pass on the heart attack though :p

[AndrewEdmonds11]

So, I've started implementing this in the MDQ_PusleShapes module. As of commit 074093e84d7a174182a21d88cc17331e02def5e7 I have single plots for pedestal and noise with all channels on (like the IslandRate plot).

Also, at the moment

• the number of presamples for the projection is taken to be 10 for FADC and BU CAEN and 25 for the UH CAEN
• the pedestal and the noise are just the mean and RMS of the projection plot (i.e. no fitting)

The Ge channels do look odd in the projection, with a couple of additional peaks (which will, hopefully, be solved when we sort out what's happening with the lengths of those islands):

[litchfld]

Gosh that's a lot of discussion, I haven't read all of this yet, but i'm gonna answer first (eek!). It's pretty common to find pedestal noise can be recovered without worrying about the signal - unless your detector/readout is actively suppressing noise the signal is normally negligible to first order. That said, the RMS is a poor measure - it's very sensitive to signal because it weights by the square of the variation form median.

In most cases a simple numerical algorithm does the job: find the maximum bin, then step either side until the number of entries drops by a fixed factor (e.g. 0.5 => FWHM), and take the difference between these. It's not 100% reliable but is likely to be more reliable (per unit effort) than trying to verify your pre-sample for every detector over every run.

[jrquirk]

A note on the CAENs, (I think I said this somewhere but responses I plan to write and have already written are getting jumbled up in my head...) the BU CAEN's have a key in their equipment called post_trigger_size. This is a hardware setting in units of percent (although it's an integer) of the total sampling window. As far as I can tell, the UH CAEN doesn't have this key in the ODB (we didn't enable it in the frontend), so it's probably the default.

I say this because it is possible to grab the post_trigger_size for at least one of the CAENs, and for the FADCs. It may not be necessary, especially since the pulse will still somewhat bleed into the presamples. Just the 10/25 sounds good to me.

Phil's idea sounds good, too, though the FWHM is changed in the plots above as well depending on how much of the X axis you integrate over.

[litchfld]

I wouldn't add a new function to TSetupData, that poor class has seen enough abuse I think... Stick it in your module file somewhere. And to be safe, make it static which will avoid future link time conflicts if we implement an identically named function somewhere else.

https://www.google.co.uk/search?q=batman+slapping+robin

sed s/"make it static"/"put it in an anonymous namespace"/

[benkrikler]

I understood them to be almost identical: http://stackoverflow.com/questions/154469/unnamed-anonymous-namespaces-vs-static-functions

[AndrewEdmonds11]

This is done with commit 0c94088a5576394b999338e5e6fe921b38852b86. Closing...

[litchfld]

Yeah, but the namespace approach makes intentions clearer. And experience suggests most people in HEP aren't so interested in compiler guts to spend time getting their heads round the different meanings of static. So better to just avoid learning that one.

static myFunc; // can't be used outside of translation unit (~file)
static myClass::myFunc;  // can be used outside of translation unit.