Update MkFit to support multiple iterations

[makortel]

PR description:

This PR updates MkFit to support multiple tracking iterations. For now, preliminary tuning, and an option to switch pattern recognition to MkFit, is provided for initialStep, lowPtQuadStep, highPtTripletStep, lowPtTripletStep, detachedQuadStep, pixelLessStep, and tobTecStep. Work for tuning for these as well as the later iterations continues in parallel. This PR adds Modifiers for each of these iterations (plus detachedTripletStep and mixedTripletStep) to allow switching any set of them to be switched to MkFit, and a ModifierChain to switch them all (this is intended only as a temporary solution, with a single Modifier to switch all iterations seen as the longer term solution once a satisfactory tuning has been achieved).

In addition this PR includes

• Physics fix to use 1D strip hits in the barrel
• Move all geometry-related code to an ESProduct from EDProducers
• Customize function to replace pattern recognition in HLT iter0 to MkFit, enabled in the X.7 workflow
• Support for strip cluster charge cut per iteration
• Option to limit the internal concurrency in MkFit to 1 with tbb::task_arena, in order to be able to account all computations in EDModule timing measurements (like framework timers or FastTimerService)
• Some technical optimization

In addition to the physics tuning there are several technical issues remaining that will be addressed in future PR(s).

The JSON files for per-iteration parameters will be moved to cms-data (and removed from the commit history) after the PR review is otherwise complete.

Requires cms-sw/cmsdist#6917

FYI @mtosi @vmariani @mmusich

PR validation:

Tested workflows 11634.0 and 11634.7 run.

MTV plots comparing MkFit (enabled in all the aforementioned iterations) to CKF can be found from http://uaf-10.t2.ucsd.edu/~mmasciov/MkFit_multiIteration_forPR/plots_500evts_lessIters_all/. The plots were done in CMSSW_11_2_0 with ttbar+PU 50 with realistic 2021 conditions. The mkFit was compiled with gcc for SSE3 in red (setup in the external pull request), and icc for AVX2 in black, run on Skylake Gold on a single thread.

[cmsbuild]

-code-checks

Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-33802/22788

ERROR: Build errors found during clang-tidy run.

Suppressed 584 warnings (583 in non-user code, 1 with check filters).
--
RecoTracker/MkFit/plugins/MkFitGeometryESProducer.cc:18:10: error: 'mkFit/IterationConfig.h' file not found [clang-diagnostic-error]
#include "mkFit/IterationConfig.h"
         ^
Suppressed 680 warnings (679 in non-user code, 1 with check filters).
--
RecoTracker/MkFit/plugins/MkFitProducer.cc:26:10: error: 'mkFit/IterationConfig.h' file not found [clang-diagnostic-error]
#include "mkFit/IterationConfig.h"
         ^
Suppressed 1026 warnings (1025 in non-user code, 1 with check filters).
--
RecoTracker/MkFit/plugins/MkFitHitConverter.cc:36:10: error: 'mkFit/MkStdSeqs.h' file not found [clang-diagnostic-error]
#include "mkFit/MkStdSeqs.h"
         ^
Suppressed 1116 warnings (1115 in non-user code, 1 with check filters).
--
RecoTracker/MkFit/plugins/MkFitOutputConverter.cc:220:41: error: type 'const mkfit::EventOfHits' does not provide a subscript operator [clang-diagnostic-error]
        auto const isPixel = eventOfHits[hitOnTrack.layer].is_pix_lyr();
                                        ^
Suppressed 1603 warnings (1602 in non-user code, 1 with check filters).
--
gmake: *** [config/SCRAM/GMake/Makefile.coderules:128: code-checks] Error 2
gmake: *** [There are compilation/build errors. Please see the detail log above.] Error 2

[makortel]

@smuzaffar @mrodozov How can I ask code-checks to be run with a cmsdist PR? I did not understand how to apply the command suggested in the PR command list

In case an external update is needed to run code-checks (e.g. due to interface changes in header files) then request the code-checks with the external tools configuration e.g. code-checks with cms.week0_PR_01234567/47.0-cms2

[smuzaffar]

@makortel , one should first start the test for cmsdist PR. That will build externals and deploy them on cvmfs. On the summary page of cmsdist PR, there should be a link for cmssw-tool-conf which should be used starting the code-ckechs. I have updated the http://cms-sw.github.io/cms-bot-cmssw-cmds.html to include this information

[smuzaffar]

code-checks with cms.week1.PR_a23f90cc/46.0-f33a7e654ce2bd583f9cc1a2001b31c1

[cmsbuild]

-code-checks

Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-33802/22791

• This PR adds an extra 316KB to repository

• There are other open Pull requests which might conflict with changes you have proposed:

  • File Configuration/PyReleaseValidation/python/upgradeWorkflowComponents.py modified in PR(s): [DD4hep] start on geometry XML payload producer #33548, Add run3 tracking low pu era #33532
  • File Validation/RecoTrack/python/plotting/trackingPlots.py modified in PR(s): EXO regional tracking iteration #32806

Code check has found code style and quality issues which could be resolved by applying following patch(s)

• code-format:
  https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-33802/22791/code-format.patch
  e.g. curl https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-33802/22791/code-format.patch | patch -p1
  You can also run scram build code-format to apply code format directly

[mmusich]

The JSON files for per-iteration parameters will be moved to cms-data (and removed from the commit history) after the PR review is otherwise complete.

how often are these files supposed to change, if at all?

[makortel]

one should first start the test for cmsdist PR. That will build externals and deploy them on cvmfs. On the summary page of cmsdist PR, there should be a link for cmssw-tool-conf which should be used starting the code-ckechs. I have updated the http://cms-sw.github.io/cms-bot-cmssw-cmds.html to include this information

Thanks @smuzaffar!

[cmsbuild]

+code-checks

Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-33802/22800

• This PR adds an extra 20KB to repository

• There are other open Pull requests which might conflict with changes you have proposed:

  • File Configuration/PyReleaseValidation/python/upgradeWorkflowComponents.py modified in PR(s): [DD4hep] start on geometry XML payload producer #33548, Add run3 tracking low pu era #33532
  • File Validation/RecoTrack/python/plotting/trackingPlots.py modified in PR(s): EXO regional tracking iteration #32806

[fwyzard]

Years of experience have amply demonstrated that very little is "temporary" in the CMS software.

[srimanob]

+Upgrade

The mkfit workflow, 11634.7, is dumped properly and run until the end.

Note that,

• the DigiTrigger step is part of Phase-2. However, the mkfit workflow defined under UpgradeWorkflow_trackingMkFit is for 2017 and 2021 only. But it is not harmful to have it there.
• I am not sure I follow the individual trackingMkFit modifier. What is the plan for validation, or we go directly of a chain of modifiers in central validation?
  FYI @makortel @mtosi

[makortel]

Does @cms-sw/hlt-l2 prefer to not have the customize function then?

[fwyzard]

@makortel I've asked Trigger Coordination, and the answer has been that TSG does not plan to use it or support this customisation; and it must not prevent any future HLT updated from being promptly merged in CMSSW, even if it breaks this customisation.

So, the customisation can go in, but only if O&C agrees to never consider it a blocking issue for merging HLT updates.

[makortel]

So, the customisation can go in, but only if O&C agrees to never consider it a blocking issue for merging HLT updates.

The X.7 workflow is not part of the tests run in PR tests, so a HLT update causing the X.7 workflow to break would not be caught in the PR tests but only in IBs (and therefore would not block HLT update PRs). If/when X.7 workflow breaks, I'd be happy to fix it (or remove the customization if a quick fix would be impractical) without any effort from HLT.

@qliphy @silviodonato @smuzaffar Would you find this acceptable?

[chayanit]

+1

I'm also curious about the plan for validation.

[qliphy]

So, the customisation can go in, but only if O&C agrees to never consider it a blocking issue for merging HLT updates.

The X.7 workflow is not part of the tests run in PR tests, so a HLT update causing the X.7 workflow to break would not be caught in the PR tests but only in IBs (and therefore would not block HLT update PRs). If/when X.7 workflow breaks, I'd be happy to fix it (or remove the customization if a quick fix would be impractical) without any effort from HLT.

@qliphy @silviodonato @smuzaffar Would you find this acceptable?

Silvio and me are fine with this. @cms-sw/hlt-l2 Do you have further comments?
We are going to build 12_0_0_pre3 tomorrow, and can include this if possible.

[fwyzard]

Thanks @qliphy @silviodonato . I think TSG is OK with tihs approach.

[fwyzard]

+hlt

[qliphy]

+1

[cmsbuild]

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 be automatically merged.