Executive Summary
The EPD was installed successfully and the dark current looks good in all 744 channels.  There are 6 tiles that show problems in the mapping check, though some of these are due to dead tiles/low values.  There is at least 1 mismatch.

The vped settings were completed.  The timing scan was completed.   The bias scan was completed.  By 12/14/2021 the EPD was set other than for the tac offset and slew corrections.

A more detailed discussion of EPD problems can be found at: drupal.star.bnl.gov/STAR/blog/rjreed/Run-22-EPD-issues

Details
This year the EPD was installed earlier so that it would be available for cosmic testing of the forward upgrade.  It may be useful to look at the write-up I made for the previous run, which can be found at:  drupal.star.bnl.gov/STAR/blog/rjreed/epd-install-calibration-and-commissioning-run-21

The fibers had been taken off of the west side so that they weren't damaged during the installation of the forward upgrade, so we needed to install the fibers into the FEEs on the West Side as well.  There are two changes to the EPD for this year's running - one is that the EPD is half an inch further out (symmetric on both sides) - the other is that there is an active splitter placed after the the FEEs before the diffRx to split the signal to the FCS.

The EPD disks were installed by the STAR Team this year, with Prashanth also installing the 4 hardest to reach fiber bundles on the West side.

Light Leak Checking
We compared the dark currents to what they were near the end of the last run.  This can be seen below.

Figure 1: Dark current comparisons between the end of Run 21 and the beginning of Run 22.

No channel looked different from the end of last year's run - so the dark currents are most likely Ok.  They are  little bit less (mostly) in every channel, my hypothesis is that this is due to the temperature difference in the IR as it is cooler in November than June!  The data files and code used to make this are attached to this blog.  (Note - we record the data using the SaveAs function on the EPD GUI.)

I also have included the output from the beginning of the last run for posterity, and if anyone is interesting in the change of the dark current before and after the run, that can be seen at: drupal.star.bnl.gov/STAR/system/files/Run21DC.pdf

Mapping
The mapping check is important this year due to the installation of the splitters.   Mike has recorded the mapping through the splitters as:

---North------------------------------South---------

---------------------- WALL ---------------------------

01 odd    |    03 odd     |   05 odd

01 even   |   03 even    |   05 even

02 odd    |    04 odd     |   06 odd

02 even   |   04 even    |   06 even

---North------------------------------South---------

---------------------- WALL ---------------------------

07 odd    |    09 odd     |   11 odd

07 even   |   09 even    |   11 even

08 odd    |    10 odd     |   12 odd

08 even   |   10 even    |   12 even

Hopefully we won't have to touch these again.  We learned a few things last run when checking the mapping - that when the magnet is off (as it is) we can get errors when using the AnalyzePedAsPhysRun.C macro (adopted from the bfc by Mike) since it tries to pick up the magnetic field.  This year I also found it odd because I needed to use cons with stardev in order to pick up the right libraries for the newest version of the StTriggerData class.  I found this odd because I thought switching to the library alone would solve the problem.

The runs taken were:
Zero Pedestals 22310006
Pattern1 007
Pattern2 008
Pattern3 009
Pattern4 010
Pattern5 011
Pattern6 012
Pattern7 013

Pedestals to return to default state 014.

The resulting pictures can be found at:  drupal.star.bnl.gov/STAR/system/files/EPDRun22_MapTest1.pdf

I don't believe we have any channels mis-mapped, however there are a few oddities we need to check and think about in the next couple of days.  For those who may want to look at my code directly, it lives at: /star/u/rjreed/EPD2022/MappingCheck01

The tiles that seem to have a problem are:
MISMATCH!!! ew/pp/tt = -1/3/3
MISMATCH!!! ew/pp/tt = -1/7/6
MISMATCH!!! ew/pp/tt = -1/9/23
MISMATCH!!! ew/pp/tt = 1/2/4
MISMATCH!!! ew/pp/tt = 1/6/1
MISMATCH!!! ew/pp/tt = 1/6/5

These tiles correspond to: (crate/board/channel)
2/13/17
2/10/16
2/7/7
1/13/10 ---> From the mapping database, 2019 spreadsheet says 3/13/24!!
3/13/9
1/14/11

Figure 2: ADC values for Pattern1 values for the 6 "bad" tiles and 2 randomly chosen good tiles.  East is red (bad) and purple (good), West is blue (bad) and green (good).

In order to see what was going on, I decided to use the epd reader which runs on the *.dat files and then queries the database directly to get the mapping.  This showed 1 of the bad tiles as not being mapped correctly - basically the crate/board/channel corresponded to an empty tile.  So for Figure 2, I plot the actual crate/board/channel for this tile.  It actually seems that the value was set properly for EW1/PP2/TT4 if I use the right value which is a little disconcerting.

The others all look like they weren't showing a signal.  Zooming in:

Figure 3: Same as Figure 2, zoomed in.  It looks like the west side tiles are exactly 0.  The east side values are just low.  Looking more closely, East PP9 TT23 has no entries.  But it looks ok for the other patterns so maybe something a little weird happened for this one run.

I will try setting the zeros file with vped = -40 rather than 0, on the off chance that the pedestal is right up against the edge. But, looking at the pattern files, we change the values via EW/PP/TT so I can't just try this with a new pattern file (so in fact, the pattern files thus never need to be changed).

11/30/21 - Efforts by Rosi

First I looked at run 22334002 - all 3 of the "dead" tiles showed a signal for this 400k cosmic event.... I guess perhaps the easiest thing will be to try to take the mapping tests again.

First I used the "zeros" where the VPED was set to -40.  Let's see how this goes.  (Maybe it will mess the mapping, I dunno.)

Run 22334029 - Pedestal Rhicclockclean to zero the EPD.
Run 22334030 - Pattern1
Run 22334031 - Pattern2
Run 22334032 - Pattern3
Run 22334033 - Pattern4
Run 22334034 - Pattern5
Run 22334035 - Pattern6
Run 22334036 - Pattern7
Run 22334037 - Pedestal Rhicclockclean to set EPD to nominal

Well, this ended up being total shit.  First - I need to keep the zeros file at vped = 0.  Second, we had several other issues that happened immediately after this!  Things we learned:

EPD QT crates (EQ1, EQ2, EQ3) have their clocks fed by the BBC RCC2 and not the L1/L0 Master RCC.
Normally this is just fine.  However, due to the BBC DSM issue that happened on the 30th, the BBC crate had been removed from the system yesterday afternoon.  This caused all sorts of weird problems with the EQ1, EQ2, and EQ3 crates.  Essentially their ADCs were always very high!

This was eventually resolved.....  And some of the EPD DSM boards were replaced as well.  More on that later.

Vped Scan

The next thing I tried was the vped scan - I do hope that this helps with some of the <0 pedestals that Hank is seeing (though I have suspicion it won't be sufficient).

Run 22336062 -> vped zeros
Run 22336064 - vped -80
Run 22336065 - vped -20
Run 22336066 - vped -10
Run 22336067 - vped 0
Run 22336068 - vped +10
Run 22336069 - vped +20
Run 22336070 - vped +80
Run 22336071 - Return EPD to its nominal state.

There was some comedy of errors with respect to the CAMAC crate off files - these also need to be taken with the zeros file as well, otherwise the pedestal subtraction still happens....

So these runs were:
Run 22342032 - CAMAC off
Run 22342034 - Old values

I updated the code a little, it can be found at: drupal.star.bnl.gov/STAR/system/files/AnalyzeVpedScan_0.txt

An example QT32C and QT32B are found below:

Figure 3: vped settings for a QT32B on the left and a QT32C on the right.

The full set of plots can be found at: drupal.star.bnl.gov/STAR/system/files/Compare_big_12062021.pdf with the calculations at: drupal.star.bnl.gov/STAR/system/files/VpedScan_big_12062021.pdf
This produced the following file: drupal.star.bnl.gov/STAR/system/files/VpedOut_12062021.txt

I then used this code:  drupal.star.bnl.gov/STAR/system/files/MakeVpedVbiasChange_0.txt and the old version of the mapping: drupal.star.bnl.gov/STAR/system/files/EPD_TUFFmap_11302021.txt with the file above to produce the new mapping:

drupal.star.bnl.gov/STAR/system/files/EPD_TUFFmap_12082021.txt

This will last until we get collisions and set the biases.

I wrote a document for the shift crew to take the timing scan, this can be found at: drupal.star.bnl.gov/STAR/system/files/Run22EPDTimingScan.pdf
in case it happens while I'm sleeping (since I am on day shift).

The rest needs to be done by us - but it can take a few hours to take this data.

Pedestal Check
Next I wanted to check the pedestals to see about the issue with the "negative" pedestals that Hank brought up.  This required that I remember how to do that...

ssh -A -Y rjreed@ssh.sdcc.bnl.gov
ssh -A -Y stargw.starp.bnl.gov
ssh -A -Y trg@startrg.starp.bnl.gov
ssh l2ana01.trg.bnl.local
cd online_l2/ped

The files with the mean and sigma of the pedestals live here.  It is actually a 2 step process to get them off, you can't just scp them directly to rcf.  You need to:
scp eq*.mean.runnumber startrg.trg.bnl.local:path
exit
cd path
scp eq*.mean.runnumber rjreed@rftpexp01.rhic.bnl.gov:

Then you can download them to your machine.  I have done so, and then rewrote the scripts to play with them.  the 3 needed are:
Macro drupal.star.bnl.gov/STAR/system/files/Make1Hist.txt
Scripts drupal.star.bnl.gov/STAR/system/files/ReadFile.txt and drupal.star.bnl.gov/STAR/system/files/ListFiles.txt

To run, you merely use ./ListFiles.sh eqcrate first2digits_runnumber
So if you wanted to look at run numbers 19XXXYYY and EQ1, that would be:
./ListFiles.sh 1 19

This produces a root file that has a histogram for each crate/board/ch of the mean and sigma versus run index, where run index is just the number of the run that was used.  I detail the work in the problems blog.  The end result was that we replaced 3 daughter cards, but it is likely we'll want to replace more.

Timing Scan

This was done by Mike - See drupal.star.bnl.gov/STAR/blog/lisa/EPD-Timing-Scan-Dec-2021

Bias Scan

This was also done by Mike.

lrwxrwxrwx. 1 trg trg 43 May 13  2021 eq2_tac.dat -> /home/startrg/staruser/eq2_tac_05132021.dat
lrwxrwxrwx. 1 trg trg 40 May 13  2021 eq1_slew_corr.txt -> /home/startrg/staruser/eq1_slew_rosi.txt
lrwxrwxrwx. 1 trg trg 40 May 13  2021 eq2_slew_corr.txt -> /home/startrg/staruser/eq2_slew_rosi.txt
lrwxrwxrwx. 1 trg trg 40 May 13  2021 eq3_slew_corr.txt -> /home/startrg/staruser/eq3_slew_rosi.txt
lrwxrwxrwx. 1 trg trg 44 May 28  2021 eq1_tac.dat -> /home/startrg/staruser/eq1_tac_05282021C.dat
lrwxrwxrwx. 1 trg trg 44 May 28  2021 eq3_tac.dat -> /home/startrg/staruser/eq3_tac_05282021C.dat