[Primexd] [New Comment] Follow-up Re: Follow-up Re: error in translation table for TAGM column 21
Alexander Somov
somov at jlab.org
Wed Dec 18 11:17:29 EST 2019
Hi,
The CCAL part seems to be correct. I've not yet checked the TAGM,
but if you think that it's correct, it's Ok with me.
Cheers,
Sasha
________________________________
From: Justin Stevens <jrsteven at jlab.org>
Sent: Wednesday, December 18, 2019 10:38 AM
To: Alexander Somov <somov at jlab.org>
Cc: jonesrt at jlab.org <jonesrt at jlab.org>; primexd at jlab.org <primexd at jlab.org>
Subject: Re: [Primexd] [New Comment] Follow-up Re: Follow-up Re: error in translation table for TAGM column 21
Hi Sasha and Richard,
After digging back through the logbook I tracked down the source of the TAGM error, see https://logbooks.jlab.org/entry/3755595 for more details. The bottom line is that I propose to use these two new XML files for the TT in CCDB
Run range 60000-69999: /work/halld2/home/jrsteven/tagmTT/tt_RunPeriod-2019-01+.xml
Run range 70000+: /work/halld2/home/jrsteven/tagmTT/tt_RunPeriod-2019-11-default.xml
I have fixed the sqlite version of the TT and generated the XML where I now reproduce _exactly_ the text in your XML file for CCAL. By putting this in the sqlite file, it will also be properly mapped for the EPICs GUIs, because Hovanes uses this as input there.
Please take a look at these XML files and confirm that they are ready to be uploaded to CCDB. I will not make any changes in CCDB until I have confirmation from both of you.
-Justin
On Dec 13, 2019, at 5:11 PM, Alexander Somov <somov at jlab.org<mailto:somov at jlab.org>> wrote:
The order was originally wrong in the TT when we started PrimEx. David L. was working on the interface
to propagate changes from the CCDB to the TT. Don't submit anything, I will take a look.
________________________________
From: Justin Stevens <jrsteven at jlab.org<mailto:jrsteven at jlab.org>>
Sent: Friday, December 13, 2019 4:15 PM
To: Alexander Somov <somov at jlab.org<mailto:somov at jlab.org>>
Cc: jonesrt at jlab.org<mailto:jonesrt at jlab.org> <jonesrt at jlab.org<mailto:jonesrt at jlab.org>>; primexd at jlab.org<mailto:primexd at jlab.org> <primexd at jlab.org<mailto:primexd at jlab.org>>
Subject: Re: [Primexd] [New Comment] Follow-up Re: Follow-up Re: error in translation table for TAGM column 21
They are swapped because that is the order of the columns in the sqlite table which generates the XML. In terms of the XML and how it’s used in the offline software (as with all our other detectors) the order doesn’t matter.
I will make the change to the sqlite table, such that it produces the XML TT which matches what your preference. This way we can continue to make changes to the TT which propagate to both the standard EPICs GUIs and the XML file used for offline processing.
-Justin
On Dec 13, 2019, at 3:50 PM, Alexander Somov <somov at jlab.org<mailto:somov at jlab.org>> wrote:
Why did you swap row and columns in the translation table ?
We have a numbering convention in the detector, which is also used in the local monitoring.
Please don't modify the CCAL section without at least letting us know about this.
________________________________
From: Justin Stevens <jrsteven at jlab.org<mailto:jrsteven at jlab.org>>
Sent: Friday, December 13, 2019 7:11 AM
To: Alexander Somov <somov at jlab.org<mailto:somov at jlab.org>>
Cc: jonesrt at jlab.org<mailto:jonesrt at jlab.org> <jonesrt at jlab.org<mailto:jonesrt at jlab.org>>; primexd at jlab.org<mailto:primexd at jlab.org> <primexd at jlab.org<mailto:primexd at jlab.org>>
Subject: Re: [Primexd] [New Comment] Follow-up Re: Follow-up Re: error in translation table for TAGM column 21
Actually Sasha, I was quite careful to be sure that I did not cause an error in the CCAL translation table when I updated CCDB. If you look carefully at the diff you show below, they are functionally equivalent (i.e. channel number, col, row numerical values are identical in the xml tags, although the order is different).
In fact, I did more than a diff before I put this in CCDB. I actually ran the CCAL_online plugin and hd_dump to confirm that the results are identical for the CCAL before and after my upload. If you want to try this for yourself you can run these commands:
setenv JANA_CALIB_URL mysql://ccdb_user@hallddb.jlab.org/ccdb
# your version of the TT just checked in to CCDB yesterday evening is now the default
hd_dump -DDCCALDigiHit -DDCCALHit /cache/halld/RunPeriod-2019-01/rawdata/Run061887/hd_rawdata_061887_000.evio
# my version of the TT uploaded to CCDB on 12/3/19 (set using calibration context before your upload)
hd_dump -DDCCALDigiHit -DDCCALHit -PJANA_CALIB_CONTEXT="calibtime=2019-12-12-18-00-00" /cache/halld/RunPeriod-2019-01/rawdata/Run061887/hd_rawdata_061887_000.evio
They result in the same hit objects in our standard halld_recon framework. If there are other issues with the TT, please let me know and I’ll be happy to fix them promptly. Now I’ll get back to fixing the actual problem with the TAGM reported by Richard.
-Justin
On Dec 12, 2019, at 7:50 PM, somov at jlab.org<mailto:somov at jlab.org> wrote:
Follow-up Re: Follow-up Re: error in translation table for TAGM column 21<https://logbooks.jlab.org/entry/3752314>
* Edit<https://logbooks.jlab.org/entry/3752314/edit?destination=email/send>
* Delete<https://logbooks.jlab.org/entry/3752314/delete?destination=email/send>
Lognumber 3752314<https://logbooks.jlab.org/entry/3752314>. Submitted by jonesrt<https://logbooks.jlab.org/user/jonesrt> on Thu, 12/12/2019 - 14:54<https://logbooks.jlab.org/entries?start_date=1576176890&end_date=1576184090&book=HDLOG&book=HDTAGGER>.
There is 1 comment...
Translation Table <https://logbooks.jlab.org/comment/24915#comment-24915>
new
by somov<https://logbooks.jlab.org/user/somov> on Thu, 12/12/2019 - 19:46
The translation table /Translation/DAQ2detector was overwritten in the beginning of December 2019,
see below
create jrsteven 2019-12-03 13-12-36 Created assignment '/Translation/DAQ2detector:60000:default:2019-12-03_13-12-36
As a result, the CCAL table was corrupted for the PrimEx run period, see some differences between the old and
new table below (the data is Ok, the CCAL reconstruction didn't work properly if you run it after 12/03/19, fixed now)
(I will also update the run period 70000+ when we understand TAGM cabling)
I restored the table and going to check it. The TAGM was restored according to the PrimEx run period, for
consistency (we need to debug and correct swapped DSC/TDC cables though).
----------------------------------------------------------------------------------
When you update CCDB tables, please check and modify only sections relevant to you
(using diff is not a bad idea to compare versions).
----------------------------------------------------------------------------------
.............................
< <channel number="0" detector="CCAL" col="-6" row="5"/>
< <channel number="1" detector="CCAL" col="-1" row="-6"/>
< <channel number="2" detector="CCAL" col="-2" row="-6"/>
< <channel number="3" detector="CCAL" col="-3" row="-6"/>
< <channel number="4" detector="CCAL" col="-4" row="-6"/>
< <channel number="5" detector="CCAL" col="-5" row="-6"/>
< <channel number="6" detector="CCAL" col="-6" row="-6"/>
< <channel number="7" detector="CCAL" col="-6" row="-1"/>
< <channel number="8" detector="CCAL" col="-6" row="-2"/>
< <channel number="9" detector="CCAL" col="-6" row="-3"/>
< <channel number="10" detector="CCAL" col="-6" row="-4"/>
< <channel number="11" detector="CCAL" col="-6" row="-5"/>
---
> <channel number="0" detector="CCAL" row="5" col="-6"/>
> <channel number="1" detector="CCAL" row="-6" col="-1"/>
> <channel number="2" detector="CCAL" row="-6" col="-2"/>
> <channel number="3" detector="CCAL" row="-6" col="-3"/>
> <channel number="4" detector="CCAL" row="-6" col="-4"/>
> <channel number="5" detector="CCAL" row="-6" col="-5"/>
> <channel number="6" detector="CCAL" row="-6" col="-6"/>
> <channel number="7" detector="CCAL" row="-1" col="-6"/>
> <channel number="8" detector="CCAL" row="-2" col="-6"/>
> <channel number="9" detector="CCAL" row="-3" col="-6"/>
> <channel number="10" detector="CCAL" row="-4" col="-6"/>
> <channel number="11" detector="CCAL" row="-5" col="-6"/>
Logbooks: HDLOG<https://logbooks.jlab.org/book/hdlog> HDTAGGER<https://logbooks.jlab.org/book/hdtagger>
References: 3751784 - Follow-up Re: error in translation table for TAGM column 21<https://logbooks.jlab.org/entry/3751784>
Here is a diff between a current (tt_bad) and what it would look like corrected (tt_good). The line numbers might be off, as I am comparing what existed back in February before and after the change that introduced the mutation. That is, you want to comment out the line where col="21" is assigned for the DISCIM and F1TDC sections, then uncomment the line where is should be assigned in each section. The correct value is there, but it is commented out. Apparently before the "fix the dup" correction, both entries were uncommented in the tt, which prompted David to try and fix it. Problem was, he commented out the wrong one.
[jonesrt at gluey<mailto:jonesrt at gluey> TranslationTable]$ diff tt_bad.xml tt_good.xml
24712c24712
< <channel number="8" detector="TAGM" col="21" row="0"/>
---
> <!--channel number="8" detector="TAGM" col="21" row="0"/-->
24823c24823
< <!--channel number="11" detector="TAGM" col="21" row="0"/-->
---
> <channel number="11" detector="TAGM" col="21" row="0"/>
25394c25394
< <channel number="23" detector="TAGM" col="21" row="0"/>
---
> <!--channel number="23" detector="TAGM" col="21" row="0"/-->
25499c25499
< <!--channel number="26" detector="TAGM" col="21" row="0"/-->
---
> <channel number="26" detector="TAGM" col="21" row="0"/>
_______________________________________________
Primexd mailing list
Primexd at jlab.org<mailto:Primexd at jlab.org>
https://mailman.jlab.org/mailman/listinfo/primexd
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.jlab.org/pipermail/primexd/attachments/20191218/e73ac65c/attachment-0002.html>
More information about the Primexd
mailing list