Migrate tracker local reconstruction to Tasks #25122
Conversation
|
The code-checks are being triggered in jenkins. |
|
+code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-25122/7120 |
|
A new Pull Request was created by @makortel (Matti Kortelainen) for master. It involves the following packages: Configuration/StandardSequences @perrotta, @andrius-k, @kmaeshima, @schneiml, @civanch, @mdhildreth, @cmsbuild, @franzoni, @jfernan2, @slava77, @fabiocos, @davidlange6 can you please review it and eventually sign? Thanks. cms-bot commands are listed here |
|
@cmsbuild, please test workflow 135.13,10024.1,10024.5 |
|
The tests are being triggered in jenkins. |
|
Comparison job queued. |
|
Comparison is ready @slava77 comparisons for the following workflows were not done due to missing matrix map:
Comparison Summary:
|
|
Hi @makortel, are you planning to test this PR in playback? |
|
@andrius-k Umm, I'm not (I have no idea how to do that), but I don't mind if someone else tests. |
|
My two cents : This is a pure 10_4_X developments, and will be (assuming success of the review) part of a 10_4_X release at some point - I do not see the point of a playback - 10_4_X release will be used in the online DQM (and therefore part of a playback) in ... a year > 2018 |
|
On the other hand I do agree that testing the online clients (as part of PRs and/or in IBs) would be beneficial, as otherwise it is very easy to accidentally break them in technical migrations like here (as has happened many times in the past). Otherwise we may end up in testing them next time in spring 2021 or so. |
|
@andrius-k @boudoul @makortel, |
|
One set of cases is a different definition of trackerlocalreco in e.g. RecoLocalTracker/Configuration/python/RecoLocalTrackerHeavyIons_cff.py and RecoLocalTracker/Configuration/python/RecoLocalTracker_Cosmics_cff.py. Where these not migrated on purpose? Ignoring /test, /clients, /doc directories, and commented out lines, it looks like everything coming out of RecoLocalTracker/Configuration/python/RecoLocalTracker_cff.py was migrated. Good. Looking at /test e.g. DQM/BeamMonitor/test/beam_dqm_sourceclient-file_cfg.py and a few similar examples pick the trackerlocalreco from Configuration/StandardSequences/python/Reconstruction_cff.py and then use * or + syntax to add it to a Sequence type. A somewhat less invasive migration already used in the past is to define a trackerlocalrecoTask and instantiate a trackerlocalreco cms.Sequence from it and then explicitly change to trackerlocalrecoTask where it is relevant. |
|
@slava77 Thanks, so my grepping has become really rusty...
Yeah, that might be a good idea (maybe for #25110 as well). I did think of that, but recalling my past irritation with e.g. the task+sequence approach in iterative tracking configuration wanted to try to do the full migration as well, but then didn't (naively) realize how cumbersome it would really be. Maybe we then need to have (nearly) all standard sequences migrated to tasks first before removing the then-empty sequences. |
|
On 11/7/18 3:06 PM, Matti Kortelainen wrote:
@slava77
Thanks, so my grepping has become really rusty...
A somewhat less invasive migration already used in the past is to
define a trackerlocalrecoTask and instantiate a trackerlocalreco
cms.Sequence from it and then explicitly change to
trackerlocalrecoTask where it is relevant.
Yeah, that might be a good idea (maybe for #25110
as well). I did think of that, but recalling my past irritation with
e.g. the task+sequence approach in iterative tracking configuration
wanted to try to do the full migration as well, but then didn't
(naively) realize how cumbersome it would really be. Maybe we then need
to have (nearly) all standard sequences migrated to tasks first before
removing the then-empty sequences.
Now that I've looked more carefully, I see that my signoff of #25110 was
premature.
The xyzTask option can lead to quite a bit of duplication.
What are the dangers of making the * or + on tasks in sequences/paths to
be treated as .associate ?
|
That was exactly the part I didn't like in it. On the other hand the duplication is limited to Sequence/Task objects (i.e. for each current Sequence there would be a Task as well), but the contents of a Task(/Sequence) would be defined only once, and the Sequence is defined just as |
They would introduce the wrong mental model. For example, with |
|
Superseded by #25163 (that avoids a massive migration, sorry for the noise). |
Title says it all. I migrated all downstream configurations I managed to find with
git grep.Tested in CMSSW_10_4_X_2018-11-05-1100, no changes expected.