1) High readout occupancy in EE+3 CCU 29 and CCU 17:

This issue has been appearing and disappearing since the beginning of LHC Run I, as reported in this ELOG message. It is especially observed when the lights are on in the cavern. In this case, 5 channels (one VFE) have high pedestals (RMS ~4.5-5), and can cause anomalously high trigger rates, with sizeable fluctuations. In CCU 29 it triggers the readout of a 3-by-3 CCU matrix.

2) Trigger primitives mismatch in EE+2:

At times this feature triggers an error flag in the ECAL summary plot in the DQM. It has been observed since the beginning of LHC Run II. Quoting Alexander Zabi, ECAL trigger expert, on 15 July 2015: "the mismatch in the EE+2 region is due to the adjustment of the timing between the front end and the TCC. We have adjusted the timing with Evgueni but even after cleaning the fibers I could not get the phase right on these links. The TCC itself is ok but further adjustment can be tried later on". For the time being It is not a matter of concern.

3) noisy crystal (199,–75) in TT 64 in EB-10 gives "red" TT in RMS Map ("Noise" layout)

4) ES_KChip error

Integrity errors (KChip) appears in ES when it is not protected by the usage of a tracker FED, for example when the tracker is excluded. If this happens during a collision run it has to be immediately reported to ECAL DoC.

Quoting D.Barney: "I just checked these runs and find that 251886 did not have the TK included, but indeed all of the other runs did. Looking at the central elogs it looks as if the Tracker was reconfigured after run 251886 to be in “peak” mode - this means that they store 1 time sample per trigger, instead of the normal 3 samples (in “deconvolution” mode). Thus in principle they can store 3x more triggers in their front-ends than normal. The APVe (APV=TK front-end chip; APVe is the emulator of the APV in the TCDS iPi firmware) should, I believe, be set to only allow 7 or 8 triggers independent of the TK running mode, but perhaps this was not the case yesterday - which would explain why the ES showed these yellow parts."

5) Noisy crystal in EE-4, CCU18

This feature appears in all runs from 254833, taken on August 22 2015, and probably gives rise to multi-TeV MET events. A dedicated offline filter takes care of rejecting such events, so the issue has no consequences on the data quality.

6) Very noisy crystal in EB+6, TT62

This crystal is very noisy, giving 16-30 GeV rechits, which most likely is a sign of imminent death. The feature appears in the higher-granularity maps only, while it is no visible in the higher-level summary plots which show values averaged over many crystals. All runs taken from Friday August 21 2015 seem to be affected.

7) Missing timing plots in offline DQM

This is not a problem, and should not be reported. The timing task is very CPU consuming and it's disabled in the offline instance of the DQM. The readout timing should be checked prior to the certification, using the online DQM plots.

8) FE errors in EB+14

9) Readout timing shift in EE+6 (OBSOLETE)

As well as the previous feature, this triggers a red flag in the ECAL summary plot in the DQM, and is therefore frequently reported. Such shift is a leftover from Run I: a few CCUs were excluded, being affected by a LV problem, so the appropriate time intercalibration constants are not available. The components were were fixed during LS1 and included in Run II. The issue will be solved as soon as the new constants are deployed.

EETMT_timing_map_EEp_in_EEp9.png

10) Shifted timing in EE+9 (OBSOLETE)

11) Timing shift between EB+ and EB- (OBSOLETE)

There is a relative shift of the readout timing between EB+ and EB-, of about 0.5ns. The feature is present since the restart after LS1, after the switch from TTC to TCDS, and is most probably due to a 10cm difference in the lengths of the fibers for the two partitions.

12) Bad emulation quality in EE-05 and +08

TCC15 / TT12 in EE-05 and TCC21/TT6 in EE+08 show recurrently bad TP emulation quality. This is known, actually due to the automasking.

13) Very high cluster energy in EE+05, TT17

TT17 in EE+05 shows sometimes a very high cluster energy in online DQM:

this information is actually wrong, since in reality this CCU has rechits with very low energy (consistent with the pedestal) and no basic cluster is produced:

It is known from 2012 that this CCU has intermittant HV problems, but it is not masked in the channel status. It will be mask in the tag for the re-reco.

-- DmitriKonstantinov - 2015-07-15