<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""></div><div class=""><br class=""></div><div class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Oct 3, 2022, at 7:59 AM, Sebastian Kuhn <<a href="mailto:kuhn@jlab.org" class="">kuhn@jlab.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">Hi Noemie and everyone,<br class=""><br class="">I may be wrong, but isn’t the integration over time for run::scaler done in hardware, i.e., inside the scaler itself? In that case, you wouldn’t have to normalize to the number of cooked files; the only relevant information is which file you are reading the LAST scaler reading from (if it is not the last file of the run, then you would have to prorate for the full run length). But maybe I am misunderstanding something?<br class=""><br class="">- Sebastian<br class=""><br class=""><blockquote type="cite" class="">On Oct 3, 2022, at 4:06 AM, <a href="mailto:pilleux@jlab.org" class="">pilleux@jlab.org</a> wrote:<br class=""><br class="">Hello Nathan,<br class=""><br class="">I am computing the expected charge as run duration*run current where I<br class="">read the time and current from RCDB.<br class="">I am computing the charge from the run::scaler bank by using the last<br class="">reading in the run (using dst recon files) and normalizing it by the<br class="">fraction of the run that was cooked : charge = last run::scaler reading *<br class="">number of evio files in the run / number of cooked files. I am pulling the<br class="">number of evio files from RCDB.<br class=""><br class="">Here is the code I use to read run::scaler (sorry for the messy code as it<br class="">was just for checking it quickly) :<br class="">/work/clas12/pilleux/read_run_scaler.cpp<br class="">To run it :<br class=""><blockquote type="cite" class="">clas12root -l<br class="">read_run_scaler(int run_min, int run_max)<br class=""></blockquote>It produces a text file with 3 columns for run number, number of cooked<br class="">files, and the last run::scaler reading. Depending on the run number the<br class="">path in line 31 needs to be changed with /TBT/ or /HBT/ (depending on how<br class="">the file was cooked).<br class=""><br class="">Here is a complete file with the additionnal RCDB info that I am using :<br class="">/work/clas12/pilleux/compa_run_scaler_expected_charge.csv<br class=""><br class="">Thank you. Best regards, Noémie.<br class=""><br class=""><br class=""><br class=""><blockquote type="cite" class="">Hi Noémie,<br class=""><br class="">Can you explain exactly how you're calculating these numbers for beam<br class="">charge? Both the blue and orange numbers. What exactly do those numbers<br class="">represent? If you can also provide the corresponding software that would<br class="">be great.<br class=""><br class="">-Nathan<br class=""><br class=""><br class=""><blockquote type="cite" class="">On Sep 30, 2022, at 12:17 PM, <a href="mailto:pilleux@jlab.org" class="">pilleux@jlab.org</a> wrote:<br class=""><br class="">Dear Raffaella, dear Nathan, and dear RGC analysts,<br class=""><br class="">As discussed in previous analysis meetings, I wanted to compare how our<br class="">number of events changes in elastic and dvcs data between the low<br class="">current<br class="">and high current configurations.<br class=""><br class="">To that extent, I need to normalize the rates we get, ideally with the<br class="">FCup readings. Using the RUN::scaler bank (which uses different scaler<br class="">information than the HEL::scaler bank for which Greg showed issues), I<br class="">noticed some trend that I don't understand. Please find attached a plot<br class="">that shows that for recent runs, the accumulated charge that is<br class="">registered<br class="">(in blue) is lower than before compared to the expected charge (that I<br class="">compute from current and run time, in orange).<br class=""><br class="">Some more information to get a headstart on debugging : All these<br class="">numbers<br class="">are DAQ gated so should be independent of beam trips if I understand<br class="">correctly. They take into account the fraction of files that were<br class="">cooked<br class="">compared to the number of files in the whole run. I also crosschecked<br class="">with<br class="">Greg's code (thank you!) that we are reading the same values from the<br class="">banks.<br class=""><br class="">Am I missing a change that would explain this drop ? Or can this be due<br class="">to<br class="">the calibration of the scaler constants ?<br class=""><br class="">Thank you. Best regards, Noémie.<run_scaler_comparison.png><br class=""></blockquote><br class=""><br class=""></blockquote><br class=""><br class="">_______________________________________________<br class="">Rgc_analysis mailing list<br class=""><a href="mailto:Rgc_analysis@jlab.org" class="">Rgc_analysis@jlab.org</a><br class="">https://mailman.jlab.org/mailman/listinfo/rgc_analysis<br class=""></blockquote><br class=""><br class="">_______________________________________________<br class="">Rgc_analysis mailing list<br class=""><a href="mailto:Rgc_analysis@jlab.org" class="">Rgc_analysis@jlab.org</a><br class="">https://mailman.jlab.org/mailman/listinfo/rgc_analysis<br class=""></div></div></blockquote></div><br class=""></div></body></html>