<div dir="ltr">I have updated the beam charges and luminosity, and have submitted updated versions of the beam charge and golden run selection HPS-NOTES.  (they are awaiting approval, but they can be viewed in github; links below)<div><br></div><div><a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_JeffersonLab_HPS-2DNOTES_blob_master_ANALYSIS_goldenRunSelection2016_Golden-2DRun-2DSelection.pdf&d=DwMFaQ&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=hGEVsUzUB5ml8iDt6EuOdg&m=qPifY77nMpIhhn6VZvNVpuosVUrao87qy2Nwc49tgIc&s=xb_4yr6HgtES06o_cZlRWRfu9SAfJq2Jd43M_PEBkzs&e=">https://github.com/JeffersonLab/HPS-NOTES/blob/master/ANALYSIS/goldenRunSelection2016/Golden-Run-Selection.pdf</a></div><div><a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_JeffersonLab_HPS-2DNOTES_blob_master_TECHNICAL_myaCharge2016_Beam-2520Charge.pdf&d=DwMFaQ&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=hGEVsUzUB5ml8iDt6EuOdg&m=qPifY77nMpIhhn6VZvNVpuosVUrao87qy2Nwc49tgIc&s=UKvubCie4cOiGi5lTvOpvZ7H2Y4gzkHb3QxsI5ZuwCM&e=">https://github.com/JeffersonLab/HPS-NOTES/blob/master/TECHNICAL/myaCharge2016/Beam%20Charge.pdf</a><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, May 15, 2017 at 2:08 AM, Sebouh Paul <span dir="ltr"><<a href="mailto:sebouh.paul@gmail.com" target="_blank">sebouh.paul@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">It looks like I messed up the calculation of the beam charge for 2016 data; the values in the spreadsheet "goodQ" columns are off by a factor of 2/3.  I used Sho's SvtChargeIntegrator program, which takes information from the database and a mya dump file to calculate per-run beam charge.  The "goodQ" takes into account (among other things) the efficiency loss from latency effects: in 2015 we had the wrong latency value, and didn't fix it until partway through the run period.  This effected 1/3 of the 2015 data we took prior to fixing it.   <div><br></div><div>The reason why this affects the calculation in 2016 is that Sho's program takes in the latency values from the database to determine whether or not to scale down for latency-related efficiency loss, and the latency values for 2016 were not in the database when I ran the program.  Thus, the program assumed that all of the 2016 data was effected by the latency bug and thus applied a 2/3 efficiency correction to the data.  </div><div><br></div><div>I will modify the 2016 spreadsheet this week and correct this.  Stay tuned.  </div></div>
</blockquote></div><br></div>