jeffersonlab / hallc_replay Goto Github PK

Hi there,

Use relative instead of absolute paths on cdaqs so scripts can be used on IFarm as well:

$REPORTFILE
$OUTFILE

OR
.cfg file, where we define all these.

This will help in directory management and get rid of symlink.

pstackana.template:

1. For the hodoscope, there is a variable called "pCleanTrack" as well as "1pCleanTrack", "2pCleanTrack", "3pCleanTrack" and "4pCleanTrack". I don't think that 2p,3p,4p are being properly calculated because they're all = 0, but 1pCleanTrack is filled. pCleanTrack is just the sum of 1p,2p,3p,4p so pCleanTrack=1pCleanTrack. pFoundTrack appears to be working correctly.
2. Both the HGC and NGC are in the template, and I basically copied the "preamble" to the original cerenkov from the 6GeV era and edited the variables in order to describe what constitutes as "good tracks". The preamble isn't all that descriptive to me so perhaps we can make it more descriptive.
3. I didn't put in an aerogel "preamble" on what constitutes a good track yet, mostly because I think there might be a small problem with the code. I used the same formatting for the aerogel cerenkov as the previous ceres, but it seems as though only the very first array for fired and matched is getting filled as all subsequent regions are returning 0 except for the first one.
4. I saw that there are two lines pertaining to the calorimeter efficiency now in the report file. The previous generation of the report file actually had efficiency per block (11 blocks) and then an effective efficiency for the entire block (4 blocks). I know that the SHMS calorimeter is handled differently, but are these two lines the only things that we need in this case? Won't it be different for the HMS?
5. In order to get the hodoscope efficiency, you need to add the module to the script. When I do that and replay a run I would see where the module would initiate and it would print out the following
   "Plane 1 counters d
   Plane 2 counters d
   Plane 3 counters e
   Plane 4 counters 15"
   and then soon after it would crash. So I went into the HodoEff code and threw in a few print statements where I assumed that all variables were integers and found a compiler warning where fPlanes[ip] actually has type THcScintillatorPlane instead of an integer which I thought was kind of weird. Maybe it's nothing but I'll do some more poking around to see what I can come up with because for now the module just won't work so I haven't written the actual pos/neg/or/and efficiencies yet.
6. There are several things such as "raw", "good", "real" (etc) that may possibly need more description. I only wrote an efficiency for the "good" DC. It's trivial to add efficiency for the other two if I need to.
7. There are still several compiler errors I get pertaining to T.shms.pFRXA_adcPulseIntRaw etc...

pscalers.template:

1. This wasn't added by me but "Accepted SHMS triggers" reports 0, as does everything under EDTM.
2. Hodoscope planes X1,X2,Y1, all appear normal, but Y2 is extremely weird. Y2 the + PMTs 1-16 report 0 while 17-21 return nonsense because in db_PSScale.vt they don't exist, and for the - PMTs 1-6 return 0, 7-15 return a number, 16 returns 0, 17-21 return nonsense because they're also not in the .vt file.
3. I added the scaler/scalerrate for the aero, hgc, and ngc, but the numbers look a bit wonky.

After we get these issues figured out I'll combine pstackana.template and pscalers.template into pstackana_production.template.

Update the param for the HMS dc to follow the SHMS

Update calibrations to compile against (newer) newest version of CERN ROOT.
The string concat '+' operator fails in hodoscope calibration.
Correct hard coded cuts on TDCs for hodoscope timing.

• Make TDC plots so people select the true hits in the hodo trigger TDC.
  Remove the count on number of planes hit in DC for double peaking in DC during high rate running:
  //Count how many planes were hit by the event
  Make it clear for setting timing windows and reference times which DBASE file and PARAMs are used.
• There is a line added to the plots with no timing window or reftime cuts. These read from the gHcParms list. If the DBASE file is wrong, this will show the user incorrect cuts.
  Remove or archive calibrations that are no longer used.

Git submodules are best used for dependencies (if at all). The UTIL submodules of hallc_replay should rather have hallc_replay as submodules of the UTIL.
If things continue as they are, there will be an ever increasing number of "UTIL" submodules, which is certainly not a good thing.

I propose that the UTILs be shed as submodules and the UTIL adopt hallc_replay as a submodule.

This way the experiments can pull the latest hallc_replay into their own "UTIL" (which should probably just be called something else at this point). If the "UTIL" are not experiment specific then they should be pushed into hallc_replay otherwise they are added to a separate repo with hallc_replay added as a submodule.

What are your thoughts on this?

Update the script and/or readme to focus attention on hard coded cuts.
CALIBRATION/dc_calib/scripts/DC_calib.C, under void
DC_calib::FitCardDriftTime():

    void DC_calib::FitCardDriftTime() {

            cout << "Entering FitCardDriftTime Method . . ." << endl;

             for (Int_t ip = 0; ip < NPLANES; ip++) {
                     cout << "Plane : " << ip << endl;

                     //Loop over DC cards
                     for (card = 0; card < plane_cards[ip]; card++) {

                     cout << "card: " << card << endl;

                     tZero_fit = new TF1("tZero_fit", "[0]*x + [1]",

wireFitRangeLow[ip][card], wireFitRangeHigh[ip][card]);

                    //ENTER CUSTOM FIT PARAMETER (example below)
                    /* if (ip == 0 && card == 0){ tZero_fit = new TF1("tZero_fit", "[0]*x +

[1]", 85, 105); } */

This was determined based on XEM2 analysis by Zoe W

While inspecting the onlineGUI Histograms for SHMS Aerogel, I noticed a wierd pattern in SHMS
AEROGEL Chanels (1-6)+ Pulse Pedestals. (See Figures paero_1_6+.pdf and shms_aero2+.pdf )

I went to the Counting Room to examine these channels, and it happened that the 'problematic channels'
originate from SHMS Crate 2, ADC SLOT10. Eric and I also examined Channels from the QUARTZ that were also from this ADC, and they showed a similar pattern in the pedestals. It seems that there might be
something going on with this FLASH ADC. What is your input on this, Brad?

From nps_replay, Follow SCRIPTS/NPS/replay_production_coin_NPS_HMS.C to accept multiple segments and multiple run ranges.
Treat output rootfiles accordingly.

For the hstackana_production_kpp.template file I made notes about the following:

1. General observation (not necessarily a bug), but when I replayed run 303 with 100000 events H2X10+, H2X12+, H2X13+, H2X14+, H2X16+ all have zero counts.
2. Upon running the kpp version of the production script, I get a few errors:
   2a) "WARNING: requested 20 elements of hcer_region which has length 18"
   2b) Variables that are defined but never used in the template file are: H.cal.stat.stat_trksum2 and H.cal.stat_hitsum2, H.cal.stat.stat_trksum3 and H.cal.stat_hitsum3, H.cal.stat.stat_trksum4 and H.cal.stat_hitsum4. I didn't add it and wasn't sure how the person who did write it wanted it to be presented.
3. hmsShowerArray is something that was not added by me in the templatefile, but does not exist. The previous generation of the report file had efficiency per block (11 blocks) and then an effective efficiency for the entire block (4 blocks). Do we still want to do that?
4. This is related to 2a, but the sum number of counts of HCER PMT1 and PMT2 do not sum to the total as reported by the overall HCER efficiency.
5. I haven't added the "per pmt" efficiency for the hodoscope. THcHodoEff still needs to be looked at.
6. Since the aerogel won't be used (and the PMTs will have to be replaced if we use it) I did not add it to the template.
7. Unlike the SHMS template file, it appears that the pCleanTrack is working correctly

The directory restructuring of #230 requires that all the files in CONFIG be updated to point to the corresponding macro(s) now residing in the utilities (UTIL) directory.

The directories in the onlineGUI are not standard and confusing. This should be re-organized to match the structure of the other directories in hallc_replay