[Halld-cal] FCAL instability and LED?

[Shepherd, Matthew]

Colin,

If this is due to the LED pulser, then there are a few hypothesis for the mechanism probably, some of which are more likely than others.

(1) high rate LED pulser somehow increases the gain of the PMTs
(2) high rate LED pulser causes a global upward shift of pedestals
(3) LED events overlap with physics pulses and add extra energy

(1) seems unlikely.  Perhaps (2) or (3) are possible, but naively, I'd think that even at 1 kHz the probability of overlap of LED events is small.

Note that things like (3) are not really recoverable pathologies as there is no way to really know if there is an overlap or not.

Perhaps when the LED fires the time structure of the pulses in the FCAL is rather complex and is not a single pulse.  This could be due to the pulse length of the LED or reflections inside fo the Plexiglas.

I think it might be useful to look at a few characteristic channels on a scope when triggering on the LED pulser.  You may set the rate low and zoom out to see if there is some long time structure, for example, one LED pulse somehow generates a stream of light pulses in a single block.  (Seems like we would have looked at this at one point or another.)

In any case, it will be useful to determine the exact mechanism by which the high rate LED caused the shift in response so we can be sure to avoid these scenarios or smaller scale versions of them.

Matt

---------------------------------------------------------------------
Matthew Shepherd, Professor
Department of Physics, Indiana University, Swain West 265
727 East Third Street, Bloomington, IN 47405

Office Phone:  +1 812 856 5808

> On Sep 11, 2018, at 6:32 PM, Colin Gleason <gleasonc at jlab.org> wrote:
> 
> Hi Matt,
> 
> Good investigative work. To shed some light on LED pulser: it was set to 100x its normal running value (1kHz compared to 10Hz). I don't recall any odd behavior of the bases, but I have seen at times that changing the rate of the LED pulser can cause the HV to fluctuate in the base. When I was trying to figure out what was going on with the large occupancies, I would manually turn the pulser on/off and adjust the rate. I finally realized that it was the script causing this to happen when the pulser kept changing on me. This may be another source of instability. I was then finally able to kill the cron job that controls the pulser. Also, if I recall correctly, there was a lot of accelerator downtime during this period. I could imagine there could be some LED pile up for these runs. For what its worth, the other monitoring plots for these two runs look like what we see
> 
> If it is not possible to use an event-by-event pedestal correction, I may be able to do a gain calibration or nonlinear correction for these runs only. This would "correct" the pi0 mass, but would not fix the underlying issue.
> 
> I wonder if this is seen in other detectors?  Maybe there is something bad about these runs.
> 
> The p pi0 plots tell us something about this. We see a decrease in omegas/trigger in these runs. However, the BCAL pi0 mass looks good, but the 2 gamma in FCAL and 1 in BCAL and 1 in FCAL do not. It looks like the BCAL is ok and the problem is coming from the FCAL. For what its worth, we do see a decrease in the number of rho's/trigger for these two runs (see p 2pi plots). This may be related to the FCAL clogging up the trigger.
>  
> Mark is currently out of town so he may not respond soon.
> 
> -Colin
> 
> 
> On Tue, Sep 11, 2018 at 5:37 PM Shepherd, Matthew <mashephe at indiana.edu> wrote:
> 
> Hi Colin,
> 
> (cc'ed to Mark and the calorimetry group)
> 
> We were discussing instability of pi0 peak that was noticed in the most recent monitoring launch over the 2018 data.
> 
> To be concrete, this can be observed by going here:
> 
> https://halldweb.jlab.org/data_monitoring/Plot_Browser.html
> 
> Selecting:  RunPeriod-2018-01
> Version:  Monitoring Launch ver17
> Plot:  FCAL Clusters 2
> Run Range:  42221 to 42241
> 
> In particular, runs 42234 and 42236 seem to show a pi0 peak that is significantly high.
> 
> If I roll back to the incoming data plots then I see there are other runs (presumably not "production") that were also taken around that time and show similar behavior.
> 
> When I look a little deeper, it seems that the peak shift can be attributed to a pedestal shift.  You can chase this by clicking on the run number to go to the run browser, then clicking on the ROOT file and drilling down the fcal directory to look at the pedestal plots.
> 
> You can see the pedestal shifts high from its nominal value of 100 cts. per sample (400 over 4 samples).
> 
> I wonder if this is seen in other detectors?  Maybe there is something bad about these runs.
> 
> This happened all on/around April 19.  It is interesting that just before the problem run Mark Dalton made a log entry that the LED system was restarted (#3563543).  And Colin was on shift and noted high occupancy in the FCAL, which would happen if the pedestal shifts up.
> 
> The problem cures itself by run 42237.  Colin notes shutting off the LED pulser later that night.
> 
> Perhaps the rate for the LED's was momentarily too high and this resulted in some LED pileup in this particular run?
> 
> Is there any other light you might be able to shed on this? Maybe these runs can be saved if we use an event-by-event pedestal?
> 
> Matt
> 
> ---------------------------------------------------------------------
> Matthew Shepherd, Professor
> Department of Physics, Indiana University, Swain West 265
> 727 East Third Street, Bloomington, IN 47405
> 
> Office Phone:  +1 812 856 5808
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4019 bytes
Desc: not available
URL: <https://mailman.jlab.org/pipermail/halld-cal/attachments/20180912/96b516f8/attachment-0001.p7s>