[Halld-cal] [EXTERNAL] Re: BCAL timing in 2017 and 2018
Mark-Macrae Dalton
dalton at jlab.org
Fri Jan 24 14:27:18 EST 2020
Hi,
I think that the BCAL/tdiff_u_d table was used to calibrate DBCALHits so that the "time difference" is right. This is somewhat natural since there are two ends, there should be 2 constants and we calibrate the "time sum" by comparing the time of the DBCALPoint corrected by the flight time to the target time. After we've calibrate the "time difference" we can get the position by just multiplying by a constant. However, at some point we changed to a quadratic relationship between position and time difference and we implemented this in the DBCALPoint factory. At that point it didn't matter whether the the difference was calibrated or not since the quadratic fit parameters would cover that. The code for using the BCAL/tdiff_u_d table is still used in creating the DBCALHits.
Here is a page on the BCAL calibration where I noted that we should not be using this table. (In fact I now suspect that it doesn't matter whether it is used or not, as long as the quadratic position calibration is done afterwards and for the same run range.)
https://halldweb.jlab.org/wiki/index.php/BCAL_Calibration
However, for MC it might be that we're mixing incompatible BCAL/tdiff_u_d and BCAL/z_track_parms tables and this could cause a problem. I have made an sqlite file which makes an empty BCAL/tdiff_u_d table for all run numbers. You can find it at the this location, please go ahead and test it.
/home/dalton/work/ccdb_2017-06-28.sqlite
Best,
Mark
________________________________
From: Sean Dobbs <sdobbs at fsu.edu>
Sent: Friday, January 24, 2020 12:23 PM
To: Elton Smith <elton at jlab.org>
Cc: halld-cal at jlab.org <halld-cal at jlab.org>; Jonathan Zarling <jzarling at jlab.org>; Mark-Macrae Dalton <dalton at jlab.org>
Subject: Re: [EXTERNAL] Re: BCAL timing in 2017 and 2018
Yes, mc_generic is a variation that derives from mc, so since we
usually run on the mc variation, we can ignore this most recent entry.
Cheers,
Sean
On Fri, Jan 24, 2020 at 12:20 PM Elton Smith <elton at jlab.org> wrote:
>
> Hi Sean,
>
> Indeed, tdiff_u_d looks very suspicious. There is a specific mc entry
> for only 30000-40000. The latest entry is for mc_generic, but it may be
> that the MC defaults to the previous entry that specifies the
> 30000-40000 range
>
>
> ifarm1802:gen_2pi_primakoff>ccdb vers BCAL/tdiff_u_d | grep mc
> 79812 2017-06-13 14-08-53 2017-06-13 14-08-53 mc_generic 0L-inf
> 79803 2017-06-12 14-03-25 2017-06-12 14-03-25 mc
> 30000L-40000L
> 7685 2015-11-19 16-38-14 2015-11-19 16-38-14 mc 0L-inf
>
> Cheers, Elton.
>
> Elton Smith
> Jefferson Lab MS 12H3
> 12000 Jefferson Ave STE 4
> Newport News, VA 23606
> (757)269-7625
> (757)269-6331 fax
>
> On 1/24/20 11:09 AM, Sean Dobbs wrote:
> > Hi Elton,
> >
> > Thanks for looking into this. I don't think that any TDC constants
> > would affect things since I believe we still aren't using TDC times in
> > the higher levels of reconstruction.
> >
> > I wonder if /BCAL/tdiff_u_d is being used in the reconstruction.
> >
> > See: halld_recon:src/libraries/BCAL/DBCALHit_factory.cc, lines 287-290
> >
> > gxproj3 at ifarm1901 scripts> ccdb vers /BCAL/tdiff_u_d | grep mc
> > 79812 2017-06-13 14-08-53 2017-06-13 14-08-53 mc_generic
> > 0L-inf
> > 79803 2017-06-12 14-03-25 2017-06-12 14-03-25 mc
> > 30000L-40000L
> > 7685 2015-11-19 16-38-14 2015-11-19 16-38-14 mc
> > 0L-inf
> >
> > Cheers,
> > Sean
> >
> > On Fri, Jan 24, 2020 at 10:54 AM Elton Smith <elton at jlab.org> wrote:
> >> Hi Sean and Mark,
> >>
> >> I have taken a quick look at BCAL timing constants that might be
> >> changing for the MC. See below. From what I can tell all constants have
> >> mc data sets covering from 0L-inf, except for timewalk_tdc and
> >> timewalk_tdc_c4. Could these be causing the problem?
> >>
> >>
> >>
> >> ifarm1802:gen_2pi_primakoff>printenv | grep -i connection
> >> SSH_CONNECTION=129.57.82.214 64865 129.57.70.23 22
> >> CCDB_CONNECTION=mysql://ccdb_user@hallddb.jlab.org/ccdb
> >> RCDB_CONNECTION=mysql://rcdb@hallddb.jlab.org/rcdb
> >>
> >>
> >>
> >> ifarm1802:gen_2pi_primakoff>ccdb vers BCAL/ADC_timing_offsets | grep mc
> >> 349 2014-09-17 22-25-24 2014-09-17 22-25-24 mc 0L-inf
> >> 269 2014-07-28 14-48-52 2014-07-28 14-48-52 mc 0L-inf
> >> 179 2014-06-17 15-19-20 2014-06-17 15-19-20 mc 0L-inf
> >> ifarm1802:gen_2pi_primakoff>ccdb vers BCAL/base_time_offset | grep mc
> >> 21638 2017-01-17 13-47-45 2017-01-17 13-47-45 mc 0L-inf
> >> 21637 2017-01-17 13-43-49 2017-01-17 13-43-49 mc 0L-inf
> >> 7553 2015-08-19 13-11-04 2015-08-19 13-11-04 mc 0L-inf
> >> 7543 2015-07-30 14-45-39 2015-07-30 14-45-39 mc 0L-inf
> >> 7532 2015-07-23 14-38-06 2015-07-23 14-38-06 mc_evio 0L-inf
> >> 7531 2015-07-23 08-49-26 2015-07-23 08-49-26 mc_6gev 0L-inf
> >> 7530 2015-07-23 08-49-12 2015-07-23 08-49-12 mc 0L-inf
> >> 336 2014-09-17 22-23-27 2014-09-17 22-23-27 mc 0L-inf
> >> ifarm1802:gen_2pi_primakoff>ccdb vers BCAL/timewalk_tdc | grep mc
> >> ifarm1802:gen_2pi_primakoff>ccdb vers BCAL/timewalk_tdc_c4 | grep mc
> >> ifarm1802:gen_2pi_primakoff>ccdb vers BCAL/channel_global_offset | grep mc
> >> 7684 2015-11-19 16-38-14 2015-11-19 16-38-14 mc 0L-inf
> >> ifarm1802:gen_2pi_primakoff>ccdb vers BCAL/TDC_offsets | grep mc
> >> 348 2014-09-17 22-25-21 2014-09-17 22-25-21 mc 0L-inf
> >> 268 2014-07-28 14-48-49 2014-07-28 14-48-49 mc 0L-inf
> >> 178 2014-06-17 15-19-14 2014-06-17 15-19-14 mc 0L-inf
> >>
> >>
> >>
> >> Elton Smith
> >> Jefferson Lab MS 12H3
> >> 12000 Jefferson Ave STE 4
> >> Newport News, VA 23606
> >> (757)269-7625
> >> (757)269-6331 fax
> >>
> >> On 1/24/20 9:57 AM, Sean Dobbs wrote:
> >>> Hi all,
> >>>
> >>> We ran out of time at the Calorimetry meeting, but I wanted to bring
> >>> this email that I sent last week up again, to see if anyone had any
> >>> thoughts (or maybe the issue was resolved offline?). This seems
> >>> crucial for anyone analyzing data.
> >>>
> >>> Cheers,
> >>> Sean
> >>>
> >>>
> >>> On Tue, Jan 14, 2020 at 6:11 PM Sean Dobbs <sdobbs at fsu.edu> wrote:
> >>>> Hi all,
> >>>>
> >>>> The discrepancies that Jon Zarling has seen between runs in the
> >>>> 30000's and 40000's
> >>>> (https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_JeffersonLab_HDGeant4_issues_138&d=DwIGaQ&c=CJqEzB1piLOyyvZjb8YUQw&r=c-_tH8evYLC4MjBfbp0hiQ&m=bg_IXzqYQJjEPLmMwJGH1St3kILY4fM4wKKQyqQZv6s&s=u8ONG-wYb3Dt1x9D-l1BBmRtbu1qw1-xCbph3Vst7h4&e= ) were brought up
> >>>> in today's HDGeant4 meeting. Differences between run periods are
> >>>> surely due to some difference in the calibration constants used.
> >>>>
> >>>> I wonder if someone could remind me what the difference between how we
> >>>> did timing calibrations in 2017 and 2018 was? I noticed that
> >>>> /BCAL/tdiff_u_d had non-zero values in the 30000's and was zeroed out
> >>>> in the 40000's.
> >>>> Frankly, I can't remember what was done right now and couldn't find
> >>>> out where it was written down. This is relevant to the simulations
> >>>> since this table is applied when calibrating digihits, but isn't
> >>>> compensated for in mcsmear. But maybe I'm not remembering an
> >>>> important piece to the puzzle...
> >>>>
> >>>> Cheers,
> >>>> Sean
> >>>>
> >>>>
> >>>> ifarm1402.jlab.org> ccdb cat BCAL/tdiff_u_d:41509:mc | head -n 15
> >>>> +------------+
> >>>> | tdiff_u_d |
> >>>> | double |
> >>>> +------------+
> >>>> | 0.0 |
> >>>> | 0.0 |
> >>>> | 0.0 |
> >>>> | 0.0 |
> >>>> | 0.0 |
> >>>> | 0.0 |
> >>>> | 0.0 |
> >>>> | 0.0 |
> >>>> | 0.0 |
> >>>> | 0.0 |
> >>>> | 0.0 |
> >>>> <SNIP>
> >>>> ifarm1402.jlab.org> ccdb cat BCAL/tdiff_u_d:31001:mc | head -n 15
> >>>> +------------+
> >>>> | tdiff_u_d |
> >>>> | double |
> >>>> +------------+
> >>>> | 0.3226 |
> >>>> | 0.3226 |
> >>>> | 0.3226 |
> >>>> | 0.3226 |
> >>>> | 0.1294 |
> >>>> | 0.1294 |
> >>>> | 0.1294 |
> >>>> | 0.1294 |
> >>>> | -0.1444 |
> >>>> | -0.1444 |
> >>>> | -0.1444 |
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.jlab.org/pipermail/halld-cal/attachments/20200124/489873b1/attachment-0001.html>
More information about the Halld-cal
mailing list