There seem to be 148973 files.
Yang He states that there are:
1430 run numbers with 636M events with trigger Ids: 600001, 600011, 600021,600031

I will use the bht1-vpd30 trigger - 600231, 600221, though my EPD centrality and weighting should probably be done with the minimum bias.  But, there's a lot of ground to cover.

The CME groups bad run lists are at: drupal.star.bnl.gov/STAR/system/files/summary_qa_step2.html

At the moment I'm not so worried about statistics, so I've thrown out anything they've marked as bad - this complete list can be found at: drupal.star.bnl.gov/STAR/system/files/isobarbadrun.txt

Query is:
input URL="catalog:star.bnl.gov?filename~st_physics,filetype=daq_reco_picodst,tpx=1,sanity=1,available=1,collision=zrzr200,storage!=HPSS"

Or if you prefer
get_file_list.pl -keys 'path,filename' -cond 'storage!=HPSS,production=P20ic,trgsetupname=production_isobar_2018,filetype=daq_reco_PicoDst,filename~st_physics' -delim '/' -limit 0

I will use the same cuts as Yang He, who helpfully provided me with this QA: drupal.star.bnl.gov/STAR/system/files/Isobar_Run18_Step2_QA_Oct14_0_0.pdf

I will use the same event quality and track quality cuts. These are:
 -35<|Vz| < 25 cm, |Vr| < 2 cm , |Vz,TPC −Vz,VPD| < 5 cm，
(From:www.star.bnl.gov/protected/bulkcorr/rexwg/flow/Parity/Isobar/QA/AnalysisNote_UCLA.pdf)
Yang He found that after cuts: ~556M events, Central : ~71M,Peripheral: ~102M

Track cuts: DCA < 1 && nHitsFit > 15 && |η|<1
&& 0.2<pT<30 GeV/c && nHitsRatio> 0.52

Step 1:
First I needed to get the pico reader code up and running in a reasonable state.  For the run-by-run QAs, I realize that of course making giant 2D histograms isn't useful, so I saved these as a couple of ntuples.  I realized after the first pass, however, that the trackwise quantities are nonsense since they will be the average of each of these things over a given job, rather than a run.  Whoops.

The other part was turning these ntuples back into histograms.  I found looping over the Ntuple and gathering the run IDs and creating the histograms useful.  Of course, this was useful with the ~13 runs or so of OO data on my laptop.  I may need to rethink this.

Step one involved this code: drupal.star.bnl.gov/STAR/system/files/PicoDstAnalyzerEpdTracks_RR3_QAv1.txt

Then I parsed it using: drupal.star.bnl.gov/STAR/system/files/RunByRunCv1.txt

This makes a pdf (which I will expand upon) and saves the histograms so I don't need to rerun it all the time. Probably I will want a nice drawing QA macro soonish.  But first I am attempting to run over *all* the data so I have an idea of what this actually means!  Unfortunately I always forget how to use the scheduler. (sigh)   Another key aspect is that on RCF I used "cons" to compile, and then RunAnalysis - which compiles the pico reader on the fly. 

The next step (after running over all the data) will be to get the Ep finder working again - Mike has detailed this out in his blog at: drupal.star.bnl.gov/STAR/blog/lisa/using-epd-event-plane-finder

which is slightly out of date with the new pico format, etc.  My first attempt on my laptop failed utterly - I really couldn't get the thing to compile.  I'll try to accomplish that and at least restore reasonable functionality before running over all the data again.

Step 2:
In StRoot/StEpdUtil/StEpdFastSim/RunSimulator.C Mike writes the secret formula.  Let's repeat it:
In StRoot/StEpdUtil/StEpdEpFinder.cxx make sure it points to where the StPicoEpdHit lives.
go to StRoot/StEpdUtil
     root
     > .L StEpdGeom.cxx++
     > .L StEpdEpInfo.cxx++
     > .L StEpdEpFinder.cxx++  <-- this one will give you lots of warnings about possibly-undefined variables.  Ignore them.
     > .q
Then in my Pico Analyzer, I added:
R__LOAD_LIBRARY(StRoot/StEpdUtil/StEpdGeom_cxx.so)
R__LOAD_LIBRARY(StRoot/StEpdUtil/StEpdEpFinder_cxx.so)

At the top (init stage) I added:
StEpdEpFinder* mEpFinder = new StEpdEpFinder();
      mEpFinder->SetnMipThreshold(minNmip);
      mEpFinder->SetMaxTileWeight(maxNmip);
      mEpFinder->SetEpdHitFormat(2);     // 2=pico

Then in my loop I had:
StEpdEpInfo result = mEpFinder->Results(dst->picoArray(8),pVtx,0);
        hEpdRawPsiEastvsWest1->Fill(result.EastRawPsi(1),result.WestRawPsi(1));
        hEpdRawPsiEastvsWest2->Fill(result.EastRawPsi(2),result.WestRawPsi(2));
        hEpdRawPsiEastvsWest3->Fill(result.EastRawPsi(3),result.WestRawPsi(3));

Where I thought the 8th picoArray was the EpdHits TClones Array.  This ran - and produced 2 output root files.  Unfortunately everything was blank.  I may have to put in some weighting regardless or my use of the picoArray was not correct.  We shall see, I guess.

Step 3:
Turns out that the weights *were* needed in order to get a non-zero value.  I used the AuAu 27 GeV eta weights, these will be hugely wrong for v1, but for the jet v2 I don't care as much.  The other key aspect was to add at the very end:
mEpFinder->Finish();
Or else the code won't write out the resolution or output histograms.

Now we can look at a few plots:

Figure 1: Vx vs Vy before cuts on the left, after cuts on the right.  We lose a lot more statistics since we're only selecting the bht1 triggers.

Figure 2: Black is all events, red is after selection.  Vz on the left, refMult on the right.

Figure 3: Vz vs vpd Vz, left is before cuts, right is after.  I'm not entirely sure what the stripes are (perhaps it has something to do with events with only 1 hit in the vpd on each side?) But the main selection seems fine.

Figure 4: Refult vs Tof match - this is using Yang He's pile-up cuts.

Figure 5: Epd multiplicity (using the usual Nmip scheme) vs RefMult, and tof multiplicity vs RefMult on the right.  What is interesting is that there are still some pile-up events.  I'm not sure how an event can match in terms of refMult and tof matches, but then have a tof multiplicity that doesn't make sense.

A quick look at the data indicates that the pile-up events along the low RefMult axis are the same for both. This should be quantified, but in the end will just result in another pile-up cut.

The part that is weird is the second grouping - this will need to be investigated.  (On a side note, this was over 6.8M good events.)

Some things that were useful schedulerwise:

condor_userprio | grep rjreed

star-submit -k all 13F7804FBA09E2B0BD4D2E1E6B6EB11E.session.xml