Totem Timing detectors: updated mapping for future rereco of dedicated run data #24683

nminafra · 2018-09-27T14:28:52Z

This PR updates the mapping for Totem timing detectors for dedicated 90m run.
In more detail: the internal cabling of some detectors was not corresponding to the tables. We used the tomography with strip detectors to reverse engineer the correct correspondence.

NOTES:
in a previous PR (#23198) was mentioned "not all channels are connected, therefore it is not possible to double check all channels."
Now all channels have been checked and corrected.

Thanks

@jan-kaspar @forthommel

cmsbuild · 2018-09-27T14:29:13Z

The code-checks are being triggered in jenkins.

cmsbuild · 2018-09-27T14:31:28Z

+code-checks

Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-24683/6618

cmsbuild · 2018-09-27T14:31:48Z

A new Pull Request was created by @nminafra (Nicola Minafra) for master.

It involves the following packages:

CondFormats/CTPPSReadoutObjects
EventFilter/CTPPSRawToDigi

@perrotta, @tocheng, @cmsbuild, @franzoni, @slava77, @ggovi, @pohsun, @lpernie can you please review it and eventually sign? Thanks.
@forthommel, @jan-kaspar, @tocheng, @Martin-Grunewald, @mmusich, @seemasharmafnal this is something you requested to watch as well.
@davidlange6, @slava77, @fabiocos you are the release manager for this.

cms-bot commands are listed here

perrotta · 2018-09-27T15:11:52Z

please test

cmsbuild · 2018-09-27T15:12:11Z

The tests are being triggered in jenkins.
https://cmssdt.cern.ch/jenkins/job/ib-any-integration/30696/console Started: 2018/09/27 17:12

cmsbuild · 2018-09-27T17:24:12Z

+1
Tested at: e367733
https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-24683/30696/summary.html

cmsbuild · 2018-09-27T17:24:15Z

Comparison job queued.

cmsbuild · 2018-09-27T21:43:42Z

Comparison is ready
https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-24683/30696/summary.html

Comparison Summary:

No significant changes to the logs found
Reco comparison results: 0 differences found in the comparisons
DQMHistoTests: Total files compared: 32
DQMHistoTests: Total histograms compared: 3162160
DQMHistoTests: Total failures: 1
DQMHistoTests: Total nulls: 0
DQMHistoTests: Total successes: 3161962
DQMHistoTests: Total skipped: 197
DQMHistoTests: Total Missing objects: 0
DQMHistoSizes: Histogram memory added: 0.0 KiB( 31 files compared)
Checked 134 log files, 14 edm output root files, 32 DQM output files

pohsun · 2018-10-01T09:44:52Z

+1

slava77 · 2018-10-02T07:05:13Z

EventFilter/CTPPSRawToDigi/src/RawToDigiConverter.cc

@@ -343,7 +343,7 @@ void RawToDigiConverter::run(const VFATFrameCollection &coll, const TotemDAQMapp

          const TotemDAQMapping::TotemTimingPlaneChannelPair SWpair = mapping.getTimingChannel( totemSampicFrame.getHardwareId() );
          // for FW Version > 0 plane and channel are encoded in the dataframe
-          if ( totemSampicFrame.getFWVersion() == 0 )  // Mapping not present in HW, read from SW
+          if ( totemSampicFrame.getFWVersion() < 0x30 )  // Mapping not present in HW, read from SW for FW versions < 3.0


is there a history document for this?
It may help to have it linked inline to make the version number related logic less magic.

Not at the moment, we'll try to provide it.
Here a small mapping related summary:
FW 0x00 was the first test, without any mapping information encoded in the data format.
FW 0x2n (in particular 0x23 that was used for the data taking) are firmware versions with mapping information: the mapping in the FPGA overruled the software for on-line debugging*. Now, it is better to use the mapping in the software for easier history and debugging.
In case of future version (>0x30) the mapping will be read from the FPGA for the same reasons as above.

*: as a reminder, we had one shot. One week of data taking without any way to double check the mapping before (with data).

Do I understand correctly, that no data actually existed for production processing with getFWVersion() == 0
and also that no data exists yet with version >= 0x30?
In this case everything was so far processed in the else // Mapping read from HW, checked by SW block below.
It's worth taking a look at the data with these detectors present to have a sanity check.
Please suggest an input file.

We used FW == 0 in some test runs without beam or anyway without any physical importance.
FW >= 0x30 is only for future compatibility

The 2 FW versions used in production were:
0x23 for the 90m alignment run: 318529 for example, or anyway the whole fill 6837
0x24 for the 90m dedicated run: fills 6877, 6879, 6881, 6882, 6884, 6885, 6890, 6891, 6892
a good run is for example 319270

NOTE: FW 0x24 doesn't change the data format, it was a small bug fix

a good run is for example 319270

do you happen to have a pointer to a /RAW file from this run?

Actually I'm having problems with DAS, but you can use this run instead that I had in one of my previous tests:
/store/data/Run2018B/TOTEM3/RAW/v1/000/319/176/00000/009A26F8-6E7F-E811-ADB1-FA163EF96F9B.root

I don't find this file on disk (or anything from TOTEM3 dataset).

@slava77 Honestly, I wouldn't know what to answer. the files are listed on DAS and we used them to test the mapping a few weeks ago and now I'm also not able to access them.
https://cmsweb.cern.ch/das/request?view=list&limit=150&instance=prod%2Fglobal&input=file+dataset%3D%2FTOTEM3%2FRun2018B-v1%2FRAW+run%3D319176

@slava77 @nminafra Indeed, since they appear to be present only on T0_CH_CERN_Export, T0_CH_CERN_MSS, T1_US_FNAL_Buffer, and T1_US_FNAL_MSS. Is it worth launching a PhEDEx request (to which site?), or is there any way PdmV people can help?

slava77 · 2018-10-02T07:05:25Z

Reco comparison results: 0 differences found in the comparisons

I guess the relevant data workflows are not tested.
@nminafra please clarify which data periods are affected.
Please confirm that everything that was updated here and in #23198 was incorrectly mapped for runs from 311626 (March 12, 2018) and the most recent is the correct mapping for this full data taking period. If some data exists in runs starting from 311626 but with a different mapping, we will need a split.

As is, this PR will likely end up in 10_4_X.
Is this enough, or do you intend to have backports?

BTW, what is the status of making this mapping to the database?

nminafra · 2018-10-02T07:24:45Z

@slava77 Thanks for pointing this out.
Indeed, this mapping is valid for the full data taking. The mapping we used before was the "nominal" one, while this one was checked using data and takes into account mistakes made during the cabling.
Therefore, no split needed.

The re reco for this run is not planned yet (to my understanding); therefore we'll see in the future if we need a backport.

Regarding the database, at the moment there is no planning for future data taking with those detectors (the front-end was physically removed from the tunnel...) therefore there is no plan to move this particular mapping to the database. In case, this priority can be rediscussed with the coordinators.

ggovi · 2018-10-02T14:46:03Z

+1

slava77 · 2018-10-05T05:37:19Z

+1

for #24683 e367733

code changes are in line with the PR description (with some more details provided in Totem Timing detectors: updated mapping for future rereco of dedicated run data #24683 (comment))
jenkins tests pass and comparisons with the baseline show no differences (the standard tests apparently have no data with the PPS fast timing detectors)
local tests with the commissioning/alignment run 136.8562 show somewhat expected behavior of channel remapping (and a different choice of logic to pick the channel info)
e.g. as in the remap for the bottom part, which is the most affected by remapping [almost all channels in planes 0-3 moved]: channels from plane 1 went to plane 3

It seems like this commissioning data is good enough to check that the code logic is OK

cmsbuild · 2018-10-05T05:37:36Z

This pull request is fully signed and it will be integrated in one of the next master IBs (tests are also fine). This pull request will now be reviewed by the release team before it's merged. @davidlange6, @slava77, @smuzaffar, @fabiocos (and backports should be raised in the release meeting by the corresponding L2)

slava77 · 2018-10-08T13:35:18Z

@nminafra
please clarify if the timing detectors are a part of the heavy ion data taking.
I'm assuming no.
However, if they are, we probably need this fix in the 10_3_X.

nminafra · 2018-10-08T15:10:13Z

@slava77 the readout of the totem timing was physically removed from the tunnel during TS2. Of course, the pps timing (diamonds, not touched by this pr) is still there, but roman pots will anyways not be inserted during heavy ion runs.
This pr will be needed for the rereco which, to my knowledge, is not scheduled yet.

slava77 · 2018-10-16T09:41:37Z

@fabiocos
please check this PR and merge or clarify if some updates are needed.

fabiocos · 2018-10-16T12:29:16Z

+1

it does not look to require backport for data taking

nminafra added 2 commits September 27, 2018 16:20

Modifying mapping priority: for all acquired data software has priority

f3be7a4

Fixed mapping for dedicated run

e367733

cmsbuild added this to the CMSSW_10_3_X milestone Sep 27, 2018

cmsbuild added alca-pending code-checks-pending comparison-pending db-pending orp-pending pending-signatures reconstruction-pending tests-pending labels Sep 27, 2018

cmsbuild added code-checks-approved and removed code-checks-pending labels Sep 27, 2018

cmsbuild added tests-started and removed tests-pending labels Sep 27, 2018

cmsbuild added tests-approved and removed tests-started labels Sep 27, 2018

cmsbuild added comparison-available and removed comparison-pending labels Sep 27, 2018

cmsbuild added alca-approved and removed alca-pending labels Oct 1, 2018

slava77 reviewed Oct 2, 2018

View reviewed changes

cmsbuild added db-approved and removed db-pending labels Oct 2, 2018

slava77 mentioned this pull request Oct 3, 2018

add/update highBetaStar 2018 workflows with a physics data run #24795

Closed

cmsbuild added fully-signed and removed pending-signatures reconstruction-pending labels Oct 5, 2018

cmsbuild added the reconstruction-approved label Oct 5, 2018

smuzaffar modified the milestones: CMSSW_10_3_X, CMSSW_10_4_X Oct 10, 2018

cmsbuild added orp-approved and removed orp-pending labels Oct 16, 2018

cmsbuild merged commit 4e5abab into cms-sw:master Oct 16, 2018

forthommel deleted the totem_timing_mappingPR branch October 16, 2018 14:22

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Totem Timing detectors: updated mapping for future rereco of dedicated run data #24683

Totem Timing detectors: updated mapping for future rereco of dedicated run data #24683

nminafra commented Sep 27, 2018

cmsbuild commented Sep 27, 2018

cmsbuild commented Sep 27, 2018

cmsbuild commented Sep 27, 2018

perrotta commented Sep 27, 2018

cmsbuild commented Sep 27, 2018 •

edited

cmsbuild commented Sep 27, 2018

cmsbuild commented Sep 27, 2018

cmsbuild commented Sep 27, 2018

pohsun commented Oct 1, 2018

slava77 Oct 2, 2018

nminafra Oct 2, 2018

slava77 Oct 2, 2018

nminafra Oct 2, 2018

slava77 Oct 2, 2018

nminafra Oct 2, 2018

slava77 Oct 3, 2018

nminafra Oct 4, 2018

forthommel Oct 4, 2018

slava77 commented Oct 2, 2018

nminafra commented Oct 2, 2018 •

edited

ggovi commented Oct 2, 2018

slava77 commented Oct 5, 2018

cmsbuild commented Oct 5, 2018

slava77 commented Oct 8, 2018

nminafra commented Oct 8, 2018

slava77 commented Oct 16, 2018

fabiocos commented Oct 16, 2018

Totem Timing detectors: updated mapping for future rereco of dedicated run data #24683

Totem Timing detectors: updated mapping for future rereco of dedicated run data #24683

Conversation

nminafra commented Sep 27, 2018

cmsbuild commented Sep 27, 2018

cmsbuild commented Sep 27, 2018

cmsbuild commented Sep 27, 2018

perrotta commented Sep 27, 2018

cmsbuild commented Sep 27, 2018 • edited

cmsbuild commented Sep 27, 2018

cmsbuild commented Sep 27, 2018

cmsbuild commented Sep 27, 2018

pohsun commented Oct 1, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

slava77 commented Oct 2, 2018

nminafra commented Oct 2, 2018 • edited

ggovi commented Oct 2, 2018

slava77 commented Oct 5, 2018

cmsbuild commented Oct 5, 2018

slava77 commented Oct 8, 2018

nminafra commented Oct 8, 2018

slava77 commented Oct 16, 2018

fabiocos commented Oct 16, 2018

cmsbuild commented Sep 27, 2018 •

edited

nminafra commented Oct 2, 2018 •

edited