[Rgc_analysis] Run integrated fcup charge reading lower than before in recent runs

[Maurik Holtrop]

Hello Noémie, Sebastian, Nathan, all,

I agree with Sebastian that the scaler data can be looked at on a file by file (or even finer grained) level, so you do not have to use the number of files processed. This is also better because you do not know how much of an individual file had beam trips. 

An other place where you can be more accurate in your charge calculation is the “duration * run current”. The run current is not a constant over the run, actually it can vary significantly with beam trips etc. I don’t think the RCDB has the properly averaged current, and it also does not take into account the live time of the DAQ. The run scalers, if you used the gated FCUp, do take into account the live time, and take into account the fluctuations in the beam current on time scale of the struck scalers. 
If you would like to do a better comparison to the struck scalers, you can take the data from MYA, and use the measurement by measurement beam current and multiply this by the same for the live time. This is done to compute the charge as reported on the graph: https://clasweb.jlab.org/clas12online/timelines/rg-c/RGC2022_progress_charge.html <https://clasweb.jlab.org/clas12online/timelines/rg-c/RGC2022_progress_charge.html>  I attach a spreadsheet with the same data in tabular form for each run. Charge, sum_charge, and sum_charge_target are in mC. The calculation done in this code is found in the file RGC2022.py in https://github.com/mholtrop/RunData <https://github.com/mholtrop/RunData>. This calculation has been verified by Rafo for the RGA data, where he found generally good agreement with the results from offline reconstruction, though there are still some discrepancies were are trying to iron out. The reconstructed data for RGA had some difficulties because not all the information had gone into the data stream quite as it should.

I hope this helps.

Best,
Maurik

 



> On Oct 3, 2022, at 7:59 AM, Sebastian Kuhn <kuhn at jlab.org> wrote:
> 
> Hi Noemie and everyone,
> 
> 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?
> 
> - Sebastian
> 
>> On Oct 3, 2022, at 4:06 AM, pilleux at jlab.org wrote:
>> 
>> Hello Nathan,
>> 
>> I am computing the expected charge as run duration*run current where I
>> read the time and current from RCDB.
>> I am computing the charge from the run::scaler bank by using the last
>> reading in the run (using dst recon files) and normalizing it by the
>> fraction of the run that was cooked : charge = last run::scaler reading *
>> number of evio files in the run / number of cooked files. I am pulling the
>> number of evio files from RCDB.
>> 
>> Here is the code I use to read run::scaler (sorry for the messy code as it
>> was just for checking it quickly) :
>> /work/clas12/pilleux/read_run_scaler.cpp
>> To run it :
>>> clas12root -l
>>> read_run_scaler(int run_min, int run_max)
>> It produces a text file with 3 columns for run number, number of cooked
>> files, and the last run::scaler reading. Depending on the run number the
>> path in line 31 needs to be changed with /TBT/ or /HBT/ (depending on how
>> the file was cooked).
>> 
>> Here is a complete file with the additionnal RCDB info that I am using :
>> /work/clas12/pilleux/compa_run_scaler_expected_charge.csv
>> 
>> Thank you. Best regards, Noémie.
>> 
>> 
>> 
>>> Hi Noémie,
>>> 
>>> Can you explain exactly how you're calculating these numbers for beam
>>> charge?  Both the blue and orange numbers.  What exactly do those numbers
>>> represent?  If you can also provide the corresponding software that would
>>> be great.
>>> 
>>> -Nathan
>>> 
>>> 
>>>> On Sep 30, 2022, at 12:17 PM, pilleux at jlab.org wrote:
>>>> 
>>>> Dear Raffaella, dear Nathan, and dear RGC analysts,
>>>> 
>>>> As discussed in previous analysis meetings, I wanted to compare how our
>>>> number of events changes in elastic and dvcs data between the low
>>>> current
>>>> and high current configurations.
>>>> 
>>>> To that extent, I need to normalize the rates we get, ideally with the
>>>> FCup readings. Using the RUN::scaler bank (which uses different scaler
>>>> information than the HEL::scaler bank for which Greg showed issues), I
>>>> noticed some trend that I don't understand. Please find attached a plot
>>>> that shows that for recent runs, the accumulated charge that is
>>>> registered
>>>> (in blue) is lower than before compared to the expected charge (that I
>>>> compute from current and run time, in orange).
>>>> 
>>>> Some more information to get a headstart on debugging : All these
>>>> numbers
>>>> are DAQ gated so should be independent of beam trips if I understand
>>>> correctly. They take into account the fraction of files that were
>>>> cooked
>>>> compared to the number of files in the whole run. I also crosschecked
>>>> with
>>>> Greg's code (thank you!) that we are reading the same values from the
>>>> banks.
>>>> 
>>>> Am I missing a change that would explain this drop ? Or can this be due
>>>> to
>>>> the calibration of the scaler constants ?
>>>> 
>>>> Thank you. Best regards, Noémie.<run_scaler_comparison.png>
>>> 
>>> 
>> 
>> 
>> _______________________________________________
>> Rgc_analysis mailing list
>> Rgc_analysis at jlab.org
>> https://mailman.jlab.org/mailman/listinfo/rgc_analysis
> 
> 
> _______________________________________________
> Rgc_analysis mailing list
> Rgc_analysis at jlab.org
> https://mailman.jlab.org/mailman/listinfo/rgc_analysis

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.jlab.org/pipermail/rgc_analysis/attachments/20221003/1c2bce28/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: RGC2022_progress.xlsx
Type: application/vnd.openxmlformats-officedocument.spreadsheetml.sheet
Size: 40555 bytes
Desc: not available
URL: <https://mailman.jlab.org/pipermail/rgc_analysis/attachments/20221003/1c2bce28/attachment-0001.xlsx>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.jlab.org/pipermail/rgc_analysis/attachments/20221003/1c2bce28/attachment-0003.html>