PrHybridSeeding - Issues in DD4HEP builds
See discussion in #370 (comment 5875097)
PrHybridSeeding is giving very different results between Detdesc and dd4hep.
DetDesc
PrHybridSeeding INFO Number of counters : 21
| Counter | # | sum | mean/eff^* | rms/err^* | min | max |
| "Created T2x1 three-hit combinations in case 0" | 130424 | 78183 | 0.59945 | 0.60972 | 0.0000 | 6.0000 |
| "Created T2x1 three-hit combinations in case 1" | 201837 | 131353 | 0.65079 | 0.71665 | 0.0000 | 10.000 |
| "Created T2x1 three-hit combinations in case 2" | 381682 | 301339 | 0.78950 | 0.95432 | 0.0000 | 20.000 |
| "Created XZ tracks (part 0)" | 219 | 11325 | 51.712 | 47.114 | 1.0000 | 405.00 |
| "Created XZ tracks (part 1)" | 219 | 11147 | 50.900 | 38.520 | 4.0000 | 209.00 |
| "Created XZ tracks in case 0" | 146 | 7120 | 48.767 | 29.595 | 3.0000 | 158.00 |
| "Created XZ tracks in case 1" | 146 | 8434 | 57.767 | 42.520 | 6.0000 | 308.00 |
| "Created XZ tracks in case 2" | 146 | 6918 | 47.384 | 52.995 | 1.0000 | 405.00 |
| "Created full hit combinations in case 0" | 10758 | 10758 | 1.0000 | 0.0000 | 1.0000 | 1.0000 |
| "Created full hit combinations in case 1" | 9873 | 9873 | 1.0000 | 0.0000 | 1.0000 | 1.0000 |
| "Created full hit combinations in case 2" | 10648 | 10648 | 1.0000 | 0.0000 | 1.0000 | 1.0000 |
| "Created seed tracks" | 146 | 7732 | 52.959 | 20.279 | 15.000 | 101.00 |
| "Created seed tracks (part 0)" | 73 | 4438 | 60.795 | 24.073 | 15.000 | 115.00 |
| "Created seed tracks (part 1)" | 73 | 4239 | 58.068 | 22.743 | 17.000 | 123.00 |
| "Created seed tracks in case 0" | 146 | 3874 | 26.534 | 11.351 | 3.0000 | 58.000 |
| "Created seed tracks in case 1" | 146 | 7300 | 50.000 | 19.562 | 13.000 | 102.00 |
| "Created seed tracks in case 2" | 146 | 8222 | 56.315 | 22.243 | 15.000 | 114.00 |
| "Created seed tracks in recovery step" | 73 | 455 | 6.2329 | 4.1727 | 0.0000 | 20.000 |
| "Created two-hit combinations in case 0" | 25034 | 560295 | 22.381 | 13.668 | 0.0000 | 88.000 |
| "Created two-hit combinations in case 1" | 22752 | 735783 | 32.339 | 16.713 | 0.0000 | 120.00 |
| "Created two-hit combinations in case 2" | 19255 | 1000491 | 51.960 | 26.627 | 3.0000 | 166.00 |
DD4HEP
PrHybridSeeding INFO Number of counters : 15
| Counter | # | sum | mean/eff^* | rms/err^* | min | max |
| "Created XZ tracks (part 0)" | 219 | 0 | 0.0000 | 0.0000 | 0.0000 | 0.0000 |
| "Created XZ tracks (part 1)" | 219 | 0 | 0.0000 | 0.0000 | 0.0000 | 0.0000 |
| "Created XZ tracks in case 0" | 146 | 0 | 0.0000 | 0.0000 | 0.0000 | 0.0000 |
| "Created XZ tracks in case 1" | 146 | 0 | 0.0000 | 0.0000 | 0.0000 | 0.0000 |
| "Created XZ tracks in case 2" | 146 | 0 | 0.0000 | 0.0000 | 0.0000 | 0.0000 |
| "Created seed tracks" | 146 | 0 | 0.0000 | 0.0000 | 0.0000 | 0.0000 |
| "Created seed tracks (part 0)" | 73 | 0 | 0.0000 | 0.0000 | 0.0000 | 0.0000 |
| "Created seed tracks (part 1)" | 73 | 0 | 0.0000 | 0.0000 | 0.0000 | 0.0000 |
| "Created seed tracks in case 0" | 146 | 0 | 0.0000 | 0.0000 | 0.0000 | 0.0000 |
| "Created seed tracks in case 1" | 146 | 0 | 0.0000 | 0.0000 | 0.0000 | 0.0000 |
| "Created seed tracks in case 2" | 146 | 0 | 0.0000 | 0.0000 | 0.0000 | 0.0000 |
| "Created seed tracks in recovery step" | 73 | 0 | 0.0000 | 0.0000 | 0.0000 | 0.0000 |
| "Created two-hit combinations in case 0" | 25034 | 0 | 0.0000 | 0.0000 | 0.0000 | 0.0000 |
| "Created two-hit combinations in case 1" | 25891 | 0 | 0.0000 | 0.0000 | 0.0000 | 0.0000 |
| "Created two-hit combinations in case 2" | 25034 | 0 | 0.0000 | 0.0000 | 0.0000 | 0.0000 |
Likely related to known issues with FT, but we need the maintainer of PrHybridSeeding to dig in to confirm what exactly is leading to the differences in the two builds.
@lohenry @decianm FYI Can you assign to the maintainer of this alg ?
Designs
- Show closed items
Activity
-
Newest first Oldest first
-
Show all activity Show comments only Show history only
- Christopher Rob Jones added to epic &1
added to epic &1
- Christopher Rob Jones added RTA WP2 dd4hep labels
- Christopher Rob Jones changed the description
Compare with previous version changed the description
- Christopher Rob Jones mentioned in issue #370
mentioned in issue #370
- Louis Henry assigned to @lohenry
assigned to @lohenry
- Developer
Thanks @jonrob for opening a dedicated issue.
I do not have time right now but this is on my top list (and I have asked for some help too). This is most probably related to a different sign pattern between DD4HEP and DetDesc.
- Author Maintainer
Just to add, in the above dd4hep and detdesc tests
PrStoreSciFiHits
seems to now have identical counters in the two builds.DetDesc
PrStoreSciFiHits INFO Number of counters : 25 | Counter | # | sum | mean/eff^* | rms/err^* | min | max | | "Average X in T1U" | 25390 | -1147757 | -45.205 | 1259.0 | -2655.9 | 2656.3 | | "Average X in T1V" | 25817 | -897896 | -34.779 | 1243.7 | -2656.1 | 2656.2 | | "Average X in T1X1" | 25034 | -925634.9 | -36.975 | 1267.1 | -2645.1 | 2646.0 | | "Average X in T1X2" | 25891 | -298078.4 | -11.513 | 1252.4 | -2646.1 | 2646.1 | | "Average X in T2U" | 25104 | -375271.7 | -14.949 | 1269.0 | -2656.2 | 2656.3 | | "Average X in T2V" | 25439 | -298291.2 | -11.726 | 1257.7 | -2655.7 | 2656.1 | | "Average X in T2X1" | 24438 | -486965 | -19.927 | 1271.8 | -2646.1 | 2646.0 | | "Average X in T2X2" | 26257 | -207297 | -7.8949 | 1260.4 | -2645.6 | 2646.1 | | "Average X in T3U" | 28022 | -43942.37 | -1.5681 | 1509.7 | -3187.9 | 3188.2 | | "Average X in T3V" | 28655 | -400006.4 | -13.959 | 1507.2 | -3188.4 | 3188.4 | | "Average X in T3X1" | 27113 | -91969.27 | -3.3921 | 1507.7 | -3176.1 | 3176.2 | | "Average X in T3X2" | 29576 | -484715.6 | -16.389 | 1497.5 | -3175.4 | 3176.1 | | "Hits in T1U" | 292 | 25390 | 86.952 | 23.850 | 33.000 | 161.00 | | "Hits in T1V" | 292 | 25817 | 88.414 | 25.166 | 35.000 | 202.00 | | "Hits in T1X1" | 292 | 25034 | 85.733 | 22.409 | 33.000 | 173.00 | | "Hits in T1X2" | 292 | 25891 | 88.668 | 24.704 | 37.000 | 172.00 | | "Hits in T2U" | 292 | 25104 | 85.973 | 23.719 | 37.000 | 149.00 | | "Hits in T2V" | 292 | 25439 | 87.120 | 23.693 | 41.000 | 157.00 | | "Hits in T2X1" | 292 | 24438 | 83.692 | 23.084 | 35.000 | 181.00 | | "Hits in T2X2" | 292 | 26257 | 89.921 | 26.576 | 39.000 | 266.00 | | "Hits in T3U" | 292 | 28022 | 95.966 | 24.310 | 41.000 | 185.00 | | "Hits in T3V" | 292 | 28655 | 98.134 | 26.849 | 42.000 | 186.00 | | "Hits in T3X1" | 292 | 27113 | 92.853 | 24.753 | 40.000 | 200.00 | | "Hits in T3X2" | 292 | 29576 | 101.29 | 26.522 | 51.000 | 186.00 | | "Total number of hits" | 73 | 316736 | 4338.8 | 970.22 | 2445.0 | 6520.0 |
DD4HEP
PrStoreSciFiHits INFO Number of counters : 25 | Counter | # | sum | mean/eff^* | rms/err^* | min | max | | "Average X in T1U" | 25390 | -1147476 | -45.194 | 1259.0 | -2655.8 | 2656.3 | | "Average X in T1V" | 25817 | 897610.5 | 34.768 | 1243.7 | -2656.2 | 2656.1 | | "Average X in T1X1" | 25034 | 925634.9 | 36.975 | 1267.1 | -2646.0 | 2645.1 | | "Average X in T1X2" | 25891 | -298078.4 | -11.513 | 1252.4 | -2646.1 | 2646.1 | | "Average X in T2U" | 25104 | -374994.1 | -14.938 | 1269.0 | -2656.2 | 2656.3 | | "Average X in T2V" | 25439 | 298009.9 | 11.715 | 1257.7 | -2656.1 | 2655.7 | | "Average X in T2X1" | 24438 | 486965 | 19.927 | 1271.8 | -2646.0 | 2646.1 | | "Average X in T2X2" | 26257 | -207297 | -7.8949 | 1260.4 | -2645.6 | 2646.1 | | "Average X in T3U" | 28022 | -43632.52 | -1.5571 | 1509.7 | -3187.9 | 3188.2 | | "Average X in T3V" | 28655 | 399689.5 | 13.948 | 1507.2 | -3188.4 | 3188.4 | | "Average X in T3X1" | 27113 | 91969.27 | 3.3921 | 1507.7 | -3176.2 | 3176.1 | | "Average X in T3X2" | 29576 | -484715.6 | -16.389 | 1497.5 | -3175.4 | 3176.1 | | "Hits in T1U" | 292 | 25390 | 86.952 | 23.850 | 33.000 | 161.00 | | "Hits in T1V" | 292 | 25817 | 88.414 | 25.166 | 35.000 | 202.00 | | "Hits in T1X1" | 292 | 25034 | 85.733 | 22.409 | 33.000 | 173.00 | | "Hits in T1X2" | 292 | 25891 | 88.668 | 24.704 | 37.000 | 172.00 | | "Hits in T2U" | 292 | 25104 | 85.973 | 23.719 | 37.000 | 149.00 | | "Hits in T2V" | 292 | 25439 | 87.120 | 23.693 | 41.000 | 157.00 | | "Hits in T2X1" | 292 | 24438 | 83.692 | 23.084 | 35.000 | 181.00 | | "Hits in T2X2" | 292 | 26257 | 89.921 | 26.576 | 39.000 | 266.00 | | "Hits in T3U" | 292 | 28022 | 95.966 | 24.310 | 41.000 | 185.00 | | "Hits in T3V" | 292 | 28655 | 98.134 | 26.849 | 42.000 | 186.00 | | "Hits in T3X1" | 292 | 27113 | 92.853 | 24.753 | 40.000 | 200.00 | | "Hits in T3X2" | 292 | 29576 | 101.29 | 26.522 | 51.000 | 186.00 | | "Total number of hits" | 73 | 316736 | 4338.8 | 970.22 | 2445.0 | 6520.0 |
Could there still be diffs between the builds the above is not showing ??
Collapse replies - Developer
Have a look at the min/max values in T1x1 and T1v for instance, they are reversed. And the sign of the mean is too
Edited by Louis Henry - Author Maintainer
Duh, I missed those sign diffs...
- Author Maintainer
@lohenry Can you remind me, do we have a dedicated issue for the FT hit issue above ?
Note, this now seems to be the limiting step in getting a Velo-FT tracking running, if you follow the discussions in #370 - So it is now super critical to get this 'long standing' issue addressed. Is there any hope to get this done asap (by which I mean the coming days) ?
FYI @gligorov
- Author Maintainer
So, I just submitted !3051 (closed)
Not to be merged, but just adds an empircal fix for the flips seen in the x of some hits from
PrStoreSciFiHits
Not perfect, I still see some diffs at the fraction of a mm level, but maybe enough to let us start to look into issues downstream of, at least until @lohenry fixes dd4hep properly (and of course whatever the issues are might have implications elsewhere....)
1 - Developer
To be clear this is not to be merged because you're fixing the symptoms rather than the root cause?
- Author Maintainer
Exactly. Its purely to try and get the data created by the alg to agree just so we can see what happens in the next steps. No way this should be considered the fix, that will only come with fixing the transforms that this information is derived from in Detector.
B.t.w. PrSeeding is going to get something similar in a bit...
- Developer
And the forward in due course I guess?
cc @ascarabo can I haz something similar for the forward in Allen plz?
- Author Maintainer
Not sure, looked no further than the
HybridSeeding
so far...See !3052 (merged)
- Developer
OK I think having the Allen and Moore forwards with this kind of hack at least available as a branch to be used for local testing would be helpful.
- Author Maintainer
and now !3053 (closed) which is another 'not for merge' MR correcting some weird 'number from 4 not 0' issue seen with the DeFT IDs (@lohenry ?)
Edited by Christopher Rob Jones - Author Maintainer
Note (@decianm ) with the above I now get a seg. fault in some track checker from the TS, so where this is really progress or not remains to be seen..
Thread 2 (Thread 0x7f1bd15ec700 (LWP 3012377) "python"): #0 0x00007f1c13b2f659 in waitpid () from /lib64/libc.so.6 #1 0x00007f1c13aacf62 in do_system () from /lib64/libc.so.6 #2 0x00007f1c13aad311 in system () from /lib64/libc.so.6 #3 0x00007f1c055dc7b6 in TUnixSystem::Exec (this=0xc54cc0, shellcmd=0x7f1bb696dd50 "/cvmfs/lhcb.cern.ch/lib/lcg/releases/ROOT/6.24.06-3455f/x86_64-centos7-gcc11-dbg/etc/gdb-backtrace.sh 3012262 1>&2") at /build/jenkins/workspace/lcg_release_pipeline/build/projects/ROOT-6.24.06/src/ROOT/6.24.06/core/unix/src/TUnixSystem.cxx:2120 #4 0x00007f1c055dd057 in TUnixSystem::StackTrace (this=0xc54cc0) at /build/jenkins/workspace/lcg_release_pipeline/build/projects/ROOT-6.24.06/src/ROOT/6.24.06/core/unix/src/TUnixSystem.cxx:2411 #5 0x00007f1c059102a6 in (anonymous namespace)::do_trace (sig=1) at /build/jenkins/workspace/lcg_release_pipeline/build/projects/ROOT-6.24.06/src/ROOT/6.24.06/bindings/pyroot/cppyy/cppyy-backend/clingwrapper/src/clingwrapper.cxx:182 #6 0x00007f1c05910322 in (anonymous namespace)::TExceptionHandlerImp::HandleException (this=0x2345cda0, sig=1) at /build/jenkins/workspace/lcg_release_pipeline/build/projects/ROOT-6.24.06/src/ROOT/6.24.06/bindings/pyroot/cppyy/cppyy-backend/clingwrapper/src/clingwrapper.cxx:195 #7 0x00007f1c055e09f3 in TUnixSystem::DispatchSignals (this=0xc54cc0, sig=kSigSegmentationViolation) at /build/jenkins/workspace/lcg_release_pipeline/build/projects/ROOT-6.24.06/src/ROOT/6.24.06/core/unix/src/TUnixSystem.cxx:3644 #8 0x00007f1c055d89ae in SigHandler (sig=kSigSegmentationViolation) at /build/jenkins/workspace/lcg_release_pipeline/build/projects/ROOT-6.24.06/src/ROOT/6.24.06/core/unix/src/TUnixSystem.cxx:407 #9 0x00007f1c055e0949 in sighandler (sig=11) at /build/jenkins/workspace/lcg_release_pipeline/build/projects/ROOT-6.24.06/src/ROOT/6.24.06/core/unix/src/TUnixSystem.cxx:3620 #10 <signal handler called> #11 0x00007f1be6e31346 in non-virtual thunk to LHCb::Detector::detail::DeIOVObject::delta() const () from /usera/jonesc/LHCbCMake/Nightlies/Detector/InstallArea/x86_64_v2-centos7-gcc11+dd4hep-dbg/lib/libDetectorLib.so #12 0x00007f1bd543ccf7 in TransportSvc::findLocalGI (this=this entry=0x7f1bb6960f80, point1=..., point2=..., gi=gi entry=0x7f1bb53419c8, topGi=...) at ../Det/DetDescSvc/src/TransportSvc.cpp:257 #13 0x00007f1bd543e0c5 in TransportSvc::intersections_r (this=0x7f1bb6960f80, point=..., vect=..., tickMin= 0x7f1bd15ea830: 0, tickMax= 0x7f1bd15ea838: 1, intersept=std::vector of length 0, capacity 0, accelCache=std::any containing TransportSvc::AccelCache = {...}, geometry=..., threshold=0.0001, guessGeometry=0x0) at ../Det/DetDescSvc/src/TransportSvc.cpp:413 #14 0x00007f1bdea3f6bc in DetailedMaterialLocator::intersect (this=0x4f2fb9b0, start=..., vect=..., intersepts=std::vector of length 0, capacity 0, accelCache=std::any containing TransportSvc::AccelCache = {...}, geometry=...) at ../Tr/TrackExtrapolators/src/DetailedMaterialLocator.cpp:71 #15 0x00007f1bdeaa3ef5 in MaterialLocatorBase::intersect (this=this entry=0x4f2fb9b0, p=..., v=..., intersepts=std::vector of length 0, capacity 0, accelCache=std::any containing TransportSvc::AccelCache = {...}, geometry=...) at ../Tr/TrackExtrapolators/src/MaterialLocatorBase.cpp:45 #16 0x00007f1bdeaa48da in MaterialLocatorBase::intersect (this=0x4f2fb9b0, traj=..., intersepts=std::vector of length 0, capacity 0, accelCache=std::any containing TransportSvc::AccelCache = {...}, geometry=...) at ../Tr/TrackExtrapolators/src/MaterialLocatorBase.cpp:178 #17 0x00007f1bdeac6ea7 in TrackMasterExtrapolator::propagate (this=0x4f030330, state=..., zNew=<optimized out>, transMat=0x7f1bd15eb000, geometry=..., pid=..., grid=0x0) at ../Tr/TrackExtrapolators/src/TrackMasterExtrapolator.cpp:205 #18 0x00007f1bdeaaab68 in TrackExtrapolator::propagate (this=0x4f030330, state=..., z=-114.444, geometry=..., pid=..., grid=0x0) at ../Tr/TrackExtrapolators/src/TrackExtrapolator.cpp:59 #19 0x00007f1bdeaaad5b in TrackExtrapolator::propagate (this=0x4f030330, track=..., z=-114.444, state=..., geometry=..., pid=..., grid=0x0) at ../Tr/TrackExtrapolators/src/TrackExtrapolator.cpp:36 #20 0x00007f1bd6f29284 in TrackResChecker::resolutionHistos (this=this entry=0x4f30a6c0, htool=..., track=..., mcPart=..., geometry=...) at /usera/jonesc/LHCbCMake/Nightlies/LHCb/InstallArea/x86_64_v2-centos7-gcc11+dd4hep-dbg/include/Event/State.h:450 #21 0x00007f1bd6f2c589 in TrackResChecker::operator() (this=this entry=0x4f30a6c0, tracks=..., mcParts=..., links=..., lhcb=...) at ../Tr/TrackCheckers/src/TrackResChecker.cpp:140 #22 0x00007f1bd6f35481 in _ZZN5Gaudi10Functional7details19filter_evtcontext_tIJNS_6Range_ISt6vectorIPKN4LHCb5Event2v15TrackESaISA_EEN9__gnu_cxx17__normal_iteratorIPKSA_SC_EEEE14KeyedContainerINS5_10MCParticleEN10Containers18KeyedObjectManagerINSL_7hashmapEEEENS5_10LinksByKeyENS5_8Detector12DeIOVElementINSR_6detail11DeIOVObjectEEEEE5applyINS1_8ConsumerIFvRKSI_RKSP_RKSQ_RKSV_ENS0_6Traits4use_IJNS5_3Det8LbDD4hep21useConditionHandleForIJSV_EEENS18_11BaseClass_tINS1B_23ConditionAccessorHolderI16TrackCheckerBaseEEEEEEELb1EEESt5tupleIJ20DataObjectReadHandleISI_ES1M_ISP_ES1M_ISQ_ENS1B_17ConditionAccessorISV_EEEEEEDaRKT_RT0_ENKUlDpRKT_E_clIJS1N_S1O_S1P_S1R_EEEDaS21_ (__closure=<optimized out>) at /usera/jonesc/LHCbCMake/Nightlies/Gaudi/InstallArea/x86_64_v2-centos7-gcc11+dd4hep-dbg/include/GaudiAlg/FunctionalDetails.h:472 #23 _ZSt13__invoke_implIvZN5Gaudi10Functional7details19filter_evtcontext_tIJNS0_6Range_ISt6vectorIPKN4LHCb5Event2v15TrackESaISB_EEN9__gnu_cxx17__normal_iteratorIPKSB_SD_EEEE14KeyedContainerINS6_10MCParticleEN10Containers18KeyedObjectManagerINSM_7hashmapEEEENS6_10LinksByKeyENS6_8Detector12DeIOVElementINSS_6detail11DeIOVObjectEEEEE5applyINS2_8ConsumerIFvRKSJ_RKSQ_RKSR_RKSW_ENS1_6Traits4use_IJNS6_3Det8LbDD4hep21useConditionHandleForIJSW_EEENS19_11BaseClass_tINS1C_23ConditionAccessorHolderI16TrackCheckerBaseEEEEEEELb1EEESt5tupleIJ20DataObjectReadHandleISJ_ES1N_ISQ_ES1N_ISR_ENS1C_17ConditionAccessorISW_EEEEEEDaRKT_RT0_EUlDpRKT_E_JRS1O_RS1P_RS1Q_RS1S_EES1U_St14__invoke_otherOS1X_DpOT1_ (__f=...) at /cvmfs/lhcb.cern.ch/lib/lcg/releases/gcc/11.1.0-e80bf/x86_64-centos7/include/c++/11.1.0/bits/invoke.h:61 #24 _ZSt8__invokeIZN5Gaudi10Functional7details19filter_evtcontext_tIJNS0_6Range_ISt6vectorIPKN4LHCb5Event2v15TrackESaISB_EEN9__gnu_cxx17__normal_iteratorIPKSB_SD_EEEE14KeyedContainerINS6_10MCParticleEN10Containers18KeyedObjectManagerINSM_7hashmapEEEENS6_10LinksByKeyENS6_8Detector12DeIOVElementINSS_6detail11DeIOVObjectEEEEE5applyINS2_8ConsumerIFvRKSJ_RKSQ_RKSR_RKSW_ENS1_6Traits4use_IJNS6_3Det8LbDD4hep21useConditionHandleForIJSW_EEENS19_11BaseClass_tINS1C_23ConditionAccessorHolderI16TrackCheckerBaseEEEEEEELb1EEESt5tupleIJ20DataObjectReadHandleISJ_ES1N_ISQ_ES1N_ISR_ENS1C_17ConditionAccessorISW_EEEEEEDaRKT_RT0_EUlDpRKT_E_JRS1O_RS1P_RS1Q_RS1S_EENSt15__invoke_resultIS1U_JDpT0_EE4typeEOS1U_DpOS29_ (__fn=...) at /cvmfs/lhcb.cern.ch/lib/lcg/releases/gcc/11.1.0-e80bf/x86_64-centos7/include/c++/11.1.0/bits/invoke.h:96 #25 _ZSt12__apply_implIZN5Gaudi10Functional7details19filter_evtcontext_tIJNS0_6Range_ISt6vectorIPKN4LHCb5Event2v15TrackESaISB_EEN9__gnu_cxx17__normal_iteratorIPKSB_SD_EEEE14KeyedContainerINS6_10MCParticleEN10Containers18KeyedObjectManagerINSM_7hashmapEEEENS6_10LinksByKeyENS6_8Detector12DeIOVElementINSS_6detail11DeIOVObjectEEEEE5applyINS2_8ConsumerIFvRKSJ_RKSQ_RKSR_RKSW_ENS1_6Traits4use_IJNS6_3Det8LbDD4hep21useConditionHandleForIJSW_EEENS19_11BaseClass_tINS1C_23ConditionAccessorHolderI16TrackCheckerBaseEEEEEEELb1EEESt5tupleIJ20DataObjectReadHandleISJ_ES1N_ISQ_ES1N_ISR_ENS1C_17ConditionAccessorISW_EEEEEEDaRKT_RT0_EUlDpRKT_E_RS1T_JLm0ELm1ELm2ELm3EEEDcOS1U_OS1X_St16integer_sequenceImJXspT1_EEE (__t=std::tuple containing = {...}, __f=...) at /cvmfs/lhcb.cern.ch/lib/lcg/releases/gcc/11.1.0-e80bf/x86_64-centos7/include/c++/11.1.0/tuple:1806 #26 _ZSt5applyIZN5Gaudi10Functional7details19filter_evtcontext_tIJNS0_6Range_ISt6vectorIPKN4LHCb5Event2v15TrackESaISB_EEN9__gnu_cxx17__normal_iteratorIPKSB_SD_EEEE14KeyedContainerINS6_10MCParticleEN10Containers18KeyedObjectManagerINSM_7hashmapEEEENS6_10LinksByKeyENS6_8Detector12DeIOVElementINSS_6detail11DeIOVObjectEEEEE5applyINS2_8ConsumerIFvRKSJ_RKSQ_RKSR_RKSW_ENS1_6Traits4use_IJNS6_3Det8LbDD4hep21useConditionHandleForIJSW_EEENS19_11BaseClass_tINS1C_23ConditionAccessorHolderI16TrackCheckerBaseEEEEEEELb1EEESt5tupleIJ20DataObjectReadHandleISJ_ES1N_ISQ_ES1N_ISR_ENS1C_17ConditionAccessorISW_EEEEEEDaRKT_RT0_EUlDpRKT_E_RS1T_EDcOS1U_OS1X_ (__t=std::tuple containing = {...}, __f=...) at /cvmfs/lhcb.cern.ch/lib/lcg/releases/gcc/11.1.0-e80bf/x86_64-centos7/include/c++/11.1.0/tuple:1817 #27 Gaudi::Functional::details::filter_evtcontext_t<Gaudi::Range_<std::vector<LHCb::Event::v1::Track const*, std::allocator<LHCb::Event::v1::Track const*> >, __gnu_cxx::__normal_iterator<LHCb::Event::v1::Track const* const*, std::vector<LHCb::Event::v1::Track const*, std::allocator<LHCb::Event::v1::Track const*> > > >, KeyedContainer<LHCb::MCParticle, Containers::KeyedObjectManager<Containers::hashmap> >, LHCb::LinksByKey, LHCb::Detector::DeIOVElement<LHCb::Detector::detail::DeIOVObject> >::apply<Gaudi::Functional::details::Consumer<void (Gaudi::Range_<std::vector<LHCb::Event::v1::Track const*, std::allocator<LHCb::Event::v1::Track const*> >, __gnu_cxx::__normal_iterator<LHCb::Event::v1::Track const* const*, std::vector<LHCb::Event::v1::Track const*, std::allocator<LHCb::Event::v1::Track const*> > > > const&, KeyedContainer<LHCb::MCParticle, Containers::KeyedObjectManager<Containers::hashmap> > const&, LHCb::LinksByKey const&, LHCb::Detector::DeIOVElement<LHCb::Detector::detail::DeIOVObject> const&), Gaudi::Functional::Traits::use_<LHCb::Det::LbDD4hep::useConditionHandleFor<LHCb::Detector::DeIOVElement<LHCb::Detector::detail::DeIOVObject> >, Gaudi::Functional::Traits::BaseClass_t<LHCb::Det::LbDD4hep::ConditionAccessorHolder<TrackCheckerBase> > >, true>, std::tuple<DataObjectReadHandle<Gaudi::Range_<std::vector<LHCb::Event::v1::Track const*, std::allocator<LHCb::Event::v1::Track const*> >, __gnu_cxx::__normal_iterator<LHCb::Event::v1::Track const* const*, std::vector<LHCb::Event::v1::Track const*, std::allocator<LHCb::Event::v1::Track const*> > > > >, DataObjectReadHandle<KeyedContainer<LHCb::MCParticle, Containers::KeyedObjectManager<Containers::hashmap> > >, DataObjectReadHandle<LHCb::LinksByKey>, LHCb::Det::LbDD4hep::ConditionAccessor<LHCb::Detector::DeIOVElement<LHCb::Detector::detail::DeIOVObject> > > >(Gaudi::Functional::details::Consumer<void (Gaudi::Range_<std::vector<LHCb::Event::v1::Track const*, std::allocator<LHCb::Event::v1::Track const*> >, __gnu_cxx::__normal_iterator<LHCb::Event::v1::Track const* const*, std::vector<LHCb::Event::v1::Track const*, std::allocator<LHCb::Event::v1::Track const*> > > > const&, KeyedContainer<LHCb::MCParticle, Containers::KeyedObjectManager<Containers::hashmap> > const&, LHCb::LinksByKey const&, LHCb::Detector::DeIOVElement<LHCb::Detector::detail::DeIOVObject> const&), Gaudi::Functional::Traits::use_<LHCb::Det::LbDD4hep::useConditionHandleFor<LHCb::Detector::DeIOVElement<LHCb::Detector::detail::DeIOVObject> >, Gaudi::Functional::Traits::BaseClass_t<LHCb::Det::LbDD4hep::ConditionAccessorHolder<TrackCheckerBase> > >, true> const&, std::tuple<DataObjectReadHandle<Gaudi::Range_<std::vector<LHCb::Event::v1::Track const*, std::allocator<LHCb::Event::v1::Track const*> >, __gnu_cxx::__normal_iterator<LHCb::Event::v1::Track const* const*, std::vector<LHCb::Event::v1::Track const*, std::allocator<LHCb::Event::v1::Track const*> > > > >, DataObjectReadHandle<KeyedContainer<LHCb::MCParticle, Containers::KeyedObjectManager<Containers::hashmap> > >, DataObjectReadHandle<LHCb::LinksByKey>, LHCb::Det::LbDD4hep::ConditionAccessor<LHCb::Detector::DeIOVElement<LHCb::Detector::detail::DeIOVObject> > >&) (handles=std::tuple containing = {...}, algo=...) at /usera/jonesc/LHCbCMake/Nightlies/Gaudi/InstallArea/x86_64_v2-centos7-gcc11+dd4hep-dbg/include/GaudiAlg/FunctionalDetails.h:471 #28 Gaudi::Functional::details::Consumer<void (Gaudi::Range_<std::vector<LHCb::Event::v1::Track const*, std::allocator<LHCb::Event::v1::Track const*> >, __gnu_cxx::__normal_iterator<LHCb::Event::v1::Track const* const*, std::vector<LHCb::Event::v1::Track const*, std::allocator<LHCb::Event::v1::Track const*> > > > const&, KeyedContainer<LHCb::MCParticle, Containers::KeyedObjectManager<Containers::hashmap> > const&, LHCb::LinksByKey const&, LHCb::Detector::DeIOVElement<LHCb::Detector::detail::DeIOVObject> const&), Gaudi::Functional::Traits::use_<LHCb::Det::LbDD4hep::useConditionHandleFor<LHCb::Detector::DeIOVElement<LHCb::Detector::detail::DeIOVObject> >, Gaudi::Functional::Traits::BaseClass_t<LHCb::Det::LbDD4hep::ConditionAccessorHolder<TrackCheckerBase> > >, true>::execute() (this=0x4f30a6c0) at /usera/jonesc/LHCbCMake/Nightlies/Gaudi/InstallArea/x86_64_v2-centos7-gcc11+dd4hep-dbg/include/GaudiAlg/Consumer.h:34 #29 0x00007f1beb7721ef in Gaudi::details::LegacyAlgorithmAdapter::execute (this=<optimized out>) at ../GaudiKernel/include/GaudiKernel/Algorithm.h:48 #30 0x00007f1bec2182f5 in Gaudi::Algorithm::sysExecute (this=this entry=0x4f30a6c0, ctx=...) at ../GaudiKernel/src/Lib/Algorithm.cpp:366 #31 0x00007f1bea8918db in GaudiAlgorithm::sysExecute (this=0x4f30a6c0, ctx=...) at ../GaudiAlg/src/lib/GaudiAlgorithm.cpp:117 #32 0x00007f1be735b16a in AlgWrapper::execute (this=this entry=0x4f6bc9a0, evtCtx=..., AlgoStates=...) at ../Hlt/HLTScheduler/src/ControlFlowNode.h:62
- Author Maintainer
Actually, looks like the seg. fault is actually from
LHCb::Detector::detail::DeIOVObject::delta()
in Detector@bcouturi any ideas ?
- Author Maintainer
So, turns out there is already an issue for this one. #326
- Developer
Created by none other than the sage of DD4HEP... yourself!
- Author Maintainer
and finally... !3054 (closed) which side-steps the issue for the track monitoring by defaulting to a different extrapolator, one I know is more-or-less OK with dd4hep as I use it int RICH.
Eventually we will probably find a use case for which
TrackMasterExtrapolator
has to be used for some reason, at which point some progress on the above issue will have to be made... - Author Maintainer
lets stop any discussion of the extrapolators here (my fault) and move that to the above issue...
- Author Maintainer
What i am now seeing with the above. Seeding is doing better, but still something not quite right.
- Author Maintainer
DetDesc
PrHybridSeeding INFO Number of counters : 21 | Counter | # | sum | mean/eff^* | rms/err^* | min | max | | "Created T2x1 three-hit combinations in case 0" | 130424 | 78183 | 0.59945 | 0.60972 | 0.0000 | 6.0000 | | "Created T2x1 three-hit combinations in case 1" | 201837 | 131353 | 0.65079 | 0.71665 | 0.0000 | 10.000 | | "Created T2x1 three-hit combinations in case 2" | 381682 | 301339 | 0.78950 | 0.95432 | 0.0000 | 20.000 | | "Created XZ tracks (part 0)" | 219 | 11325 | 51.712 | 47.114 | 1.0000 | 405.00 | | "Created XZ tracks (part 1)" | 219 | 11147 | 50.900 | 38.520 | 4.0000 | 209.00 | | "Created XZ tracks in case 0" | 146 | 7120 | 48.767 | 29.595 | 3.0000 | 158.00 | | "Created XZ tracks in case 1" | 146 | 8434 | 57.767 | 42.520 | 6.0000 | 308.00 | | "Created XZ tracks in case 2" | 146 | 6918 | 47.384 | 52.995 | 1.0000 | 405.00 | | "Created full hit combinations in case 0" | 10758 | 10758 | 1.0000 | 0.0000 | 1.0000 | 1.0000 | | "Created full hit combinations in case 1" | 9873 | 9873 | 1.0000 | 0.0000 | 1.0000 | 1.0000 | | "Created full hit combinations in case 2" | 10648 | 10648 | 1.0000 | 0.0000 | 1.0000 | 1.0000 | | "Created seed tracks" | 146 | 7732 | 52.959 | 20.279 | 15.000 | 101.00 | | "Created seed tracks (part 0)" | 73 | 4438 | 60.795 | 24.073 | 15.000 | 115.00 | | "Created seed tracks (part 1)" | 73 | 4239 | 58.068 | 22.743 | 17.000 | 123.00 | | "Created seed tracks in case 0" | 146 | 3874 | 26.534 | 11.351 | 3.0000 | 58.000 | | "Created seed tracks in case 1" | 146 | 7300 | 50.000 | 19.562 | 13.000 | 102.00 | | "Created seed tracks in case 2" | 146 | 8222 | 56.315 | 22.243 | 15.000 | 114.00 | | "Created seed tracks in recovery step" | 73 | 455 | 6.2329 | 4.1727 | 0.0000 | 20.000 | | "Created two-hit combinations in case 0" | 25034 | 560295 | 22.381 | 13.668 | 0.0000 | 88.000 | | "Created two-hit combinations in case 1" | 22752 | 735783 | 32.339 | 16.713 | 0.0000 | 120.00 | | "Created two-hit combinations in case 2" | 19255 | 1000491 | 51.960 | 26.627 | 3.0000 | 166.00 |
dd4hep
PrHybridSeeding INFO Number of counters : 21 | Counter | # | sum | mean/eff^* | rms/err^* | min | max | | "Created T2x1 three-hit combinations in case 0" | 130421 | 78184 | 0.59947 | 0.60972 | 0.0000 | 6.0000 | | "Created T2x1 three-hit combinations in case 1" | 342672 | 232520 | 0.67855 | 0.71334 | 0.0000 | 10.000 | | "Created T2x1 three-hit combinations in case 2" | 876236 | 786103 | 0.89714 | 0.98538 | 0.0000 | 20.000 | | "Created XZ tracks (part 0)" | 219 | 28637 | 130.76 | 148.58 | 3.0000 | 1216.0 | | "Created XZ tracks (part 1)" | 219 | 28416 | 129.75 | 157.65 | 10.000 | 1174.0 | | "Created XZ tracks in case 0" | 146 | 7121 | 48.774 | 29.599 | 3.0000 | 158.00 | | "Created XZ tracks in case 1" | 146 | 18188 | 124.58 | 98.192 | 18.000 | 584.00 | | "Created XZ tracks in case 2" | 146 | 31744 | 217.42 | 213.56 | 20.000 | 1216.0 | | "Created full hit combinations in case 0" | 10757 | 10757 | 1.0000 | 0.0000 | 1.0000 | 1.0000 | | "Created full hit combinations in case 1" | 21604 | 21604 | 1.0000 | 0.0000 | 1.0000 | 1.0000 | | "Created full hit combinations in case 2" | 48364 | 48364 | 1.0000 | 0.0000 | 1.0000 | 1.0000 | | "Created seed tracks" | 146 | 0 | 0.0000 | 0.0000 | 0.0000 | 0.0000 | | "Created seed tracks (part 0)" | 73 | 0 | 0.0000 | 0.0000 | 0.0000 | 0.0000 | | "Created seed tracks (part 1)" | 73 | 0 | 0.0000 | 0.0000 | 0.0000 | 0.0000 | | "Created seed tracks in case 0" | 146 | 0 | 0.0000 | 0.0000 | 0.0000 | 0.0000 | | "Created seed tracks in case 1" | 146 | 0 | 0.0000 | 0.0000 | 0.0000 | 0.0000 | | "Created seed tracks in case 2" | 146 | 0 | 0.0000 | 0.0000 | 0.0000 | 0.0000 | | "Created seed tracks in recovery step" | 73 | 0 | 0.0000 | 0.0000 | 0.0000 | 0.0000 | | "Created two-hit combinations in case 0" | 25034 | 560295 | 22.381 | 13.668 | 0.0000 | 88.000 | | "Created two-hit combinations in case 1" | 25891 | 1023690 | 39.538 | 21.638 | 0.0000 | 148.00 | | "Created two-hit combinations in case 2" | 25034 | 1812497 | 72.401 | 36.335 | 4.0000 | 209.00 |
So some counters now seem good, but some obviously not so much..
- Developer
Doing the lord's work @jonrob
- Developer
Thanks a lot @jonrob ! Indeed that fix is what I had in mind if needed to progress while we figure out where the logical misstep is. Now as for the seeding differences, you can see that the XZ case 0 counters are nearly the same, and it is the U/V hit addition which fails.
I will have a short look today, I think I see at least how to narrow the issue down.
Edited by Louis Henry - Developer
Had a talk with @ldufour, who will have a look. The list of problems we see is the following:
-
- direction of digitisation (a priori hotfixed by !3051 (closed));
-
- y size of the hole in central mat: there seems to be a factor 2 at play here
-
- y size of mats in the central area (globaldy): the size should be reduced to match the hole
-
- minimum/maximum y value of all mats mirror points: from 1.12 to 1.5.
There are some other number issues but they should be related to the hole size.
-
- Author Maintainer
Thanks for this.
Not wishing to be a pain, but it is now 'beyond critical' that we get fixes (or, failing fixes ways to work around as best we can) for these longstanding FT issues as soon as we can, by which I mean days not weeks. The aim is to try and commission some sort of dd4hep trigger in the TS in Sept., but to get there we know there is almost certainly more issues hiding behind these FT ones yet to be found. So to get there we need these fixed as soon as we can so we can press on to the next.
So, please can everyone make fixing the dd4hep issues their top priority now, if you haven't already.
- Author Maintainer
As it happens I was just doing a quick deep dump of all the info created by
PrStoreSciFiHits
, just to see for myself where the diffs in the data it creates still are. here are the logs just in case they are useful to anyonejust compare them with your favorite diff frontend..
Probably they don't say much more than you already know from the above.
Is there any way to 'quick fix' things up, even if in a 'NOT TO BE MERGED' way, to get dd4hep the same as detdesc ? Or maybe just a bit closer ? We need this critically now in order to commissioning any alg that depends on these hits, either directly or indirectly, that I am assuming is most of the rest of the tracking sequence ?
- Author Maintainer
@ldufour @lohenry can you comment here please on what you see possible, and in what timescale ? I was not joking above when I said we really need fixes here in the coming days, otherwise the chances of our meeting the Sept. TS deadline to commission some sort of dd4hep HLT at the pit really start to diminish rapidly..
- Developer
Considering my timescales: I am in full vacations so no time to figure out exactly what is going on.
However, I have spent this morning making really, really makeshift piles of changes: !3065 (closed) and Detector!267 (closed). I will write there what I found out as to some hints why the FT DD4HEP current description is failing. Mostly, it is build order in layers X1 and V, plus some shifts.
Results: Detdesc
SeedTrackChecker INFO Results SeedTrackChecker INFO **** Seed 9558 tracks including 479 ghosts [ 5.01 %], Event average 4.82 % **** SeedTrackChecker INFO 01_hasT : 6497 from 7781 [ 83.50 %] 0 clones [ 0.00 %], purity: 99.56 %, hitEff: 98.00 % SeedTrackChecker INFO 02_long : 4642 from 4960 [ 93.59 %] 0 clones [ 0.00 %], purity: 99.70 %, hitEff: 98.60 % SeedTrackChecker INFO 03_long_P>5GeV : 3291 from 3420 [ 96.23 %] 0 clones [ 0.00 %], purity: 99.67 %, hitEff: 99.09 % SeedTrackChecker INFO 04_long_fromB : 7 from 7 [100.00 %] 0 clones [ 0.00 %], purity: 98.81 %, hitEff:100.00 % SeedTrackChecker INFO 05_long_fromB_P>5GeV : 7 from 7 [100.00 %] 0 clones [ 0.00 %], purity: 98.81 %, hitEff:100.00 % SeedTrackChecker INFO 06_UT+T_strange : 532 from 572 [ 93.01 %] 0 clones [ 0.00 %], purity: 99.66 %, hitEff: 98.26 % SeedTrackChecker INFO 07_UT+T_strange_P>5GeV : 286 from 297 [ 96.30 %] 0 clones [ 0.00 %], purity: 99.55 %, hitEff: 98.94 % SeedTrackChecker INFO 08_noVelo+UT+T_strange : 282 from 301 [ 93.69 %] 0 clones [ 0.00 %], purity: 99.70 %, hitEff: 98.43 % SeedTrackChecker INFO 09_noVelo+UT+T_strange_P>5GeV : 160 from 166 [ 96.39 %] 0 clones [ 0.00 %], purity: 99.65 %, hitEff: 98.94 % SeedTrackChecker INFO 10_UT+T_SfromDB : 5 from 5 [100.00 %] 0 clones [ 0.00 %], purity:100.00 %, hitEff: 98.33 % SeedTrackChecker INFO 11_UT+T_SfromDB_P>5GeV : 2 from 2 [100.00 %] 0 clones [ 0.00 %], purity:100.00 %, hitEff:100.00 % SeedTrackChecker INFO 12_noVelo+UT+T_SfromDB_P>5GeV : 1 from 1 [100.00 %] 0 clones [ 0.00 %], purity:100.00 %, hitEff:100.00 % SeedTrackChecker INFO 13_hasT_electrons : 1307 from 2418 [ 54.05 %] 0 clones [ 0.00 %], purity: 99.60 %, hitEff: 97.30 % SeedTrackChecker INFO 14_long_electrons : 402 from 472 [ 85.17 %] 0 clones [ 0.00 %], purity: 99.80 %, hitEff: 97.87 % SeedTrackChecker INFO 16_long_electrons_P>5GeV : 233 from 264 [ 88.26 %] 0 clones [ 0.00 %], purity: 99.81 %, hitEff: 98.56 %
DD4HEP:
SeedTrackChecker INFO Results SeedTrackChecker INFO **** Seed 9557 tracks including 476 ghosts [ 4.98 %], Event average 4.79 % **** SeedTrackChecker INFO 01_hasT : 6497 from 7781 [ 83.50 %] 0 clones [ 0.00 %], purity: 99.56 %, hitEff: 98.00 % SeedTrackChecker INFO 02_long : 4644 from 4960 [ 93.63 %] 0 clones [ 0.00 %], purity: 99.70 %, hitEff: 98.59 % SeedTrackChecker INFO 03_long_P>5GeV : 3293 from 3420 [ 96.29 %] 0 clones [ 0.00 %], purity: 99.67 %, hitEff: 99.08 % SeedTrackChecker INFO 04_long_fromB : 7 from 7 [100.00 %] 0 clones [ 0.00 %], purity: 98.81 %, hitEff:100.00 % SeedTrackChecker INFO 05_long_fromB_P>5GeV : 7 from 7 [100.00 %] 0 clones [ 0.00 %], purity: 98.81 %, hitEff:100.00 % SeedTrackChecker INFO 06_UT+T_strange : 532 from 572 [ 93.01 %] 0 clones [ 0.00 %], purity: 99.66 %, hitEff: 98.23 % SeedTrackChecker INFO 07_UT+T_strange_P>5GeV : 286 from 297 [ 96.30 %] 0 clones [ 0.00 %], purity: 99.55 %, hitEff: 98.91 % SeedTrackChecker INFO 08_noVelo+UT+T_strange : 282 from 301 [ 93.69 %] 0 clones [ 0.00 %], purity: 99.70 %, hitEff: 98.40 % SeedTrackChecker INFO 09_noVelo+UT+T_strange_P>5GeV : 160 from 166 [ 96.39 %] 0 clones [ 0.00 %], purity: 99.65 %, hitEff: 98.94 % SeedTrackChecker INFO 10_UT+T_SfromDB : 5 from 5 [100.00 %] 0 clones [ 0.00 %], purity:100.00 %, hitEff: 98.33 % SeedTrackChecker INFO 11_UT+T_SfromDB_P>5GeV : 2 from 2 [100.00 %] 0 clones [ 0.00 %], purity:100.00 %, hitEff:100.00 % SeedTrackChecker INFO 12_noVelo+UT+T_SfromDB_P>5GeV : 1 from 1 [100.00 %] 0 clones [ 0.00 %], purity:100.00 %, hitEff:100.00 % SeedTrackChecker INFO 13_hasT_electrons : 1307 from 2418 [ 54.05 %] 0 clones [ 0.00 %], purity: 99.58 %, hitEff: 97.27 % SeedTrackChecker INFO 14_long_electrons : 402 from 472 [ 85.17 %] 0 clones [ 0.00 %], purity: 99.78 %, hitEff: 97.83 % SeedTrackChecker INFO 16_long_electrons_P>5GeV : 233 from 264 [ 88.26 %] 0 clones [ 0.00 %], purity: 99.81 %, hitEff: 98.56 %
Matching and Forward are still in shambles.
- Developer
Having had a quick look at Forward and Matching, they do not seem to use much more of the geometry, but could it be that the unit conversions of the states Z positions are the problem here? They use states quite extensively, whose z are defined using Gaudi::Units, but for instance it could be that the tolerances tehmselves are not updated.
- Developer
- Developer
- Developer
Are the Allen algorithms "suffering" from the same unit conversion problems as the CPU ones?
- Developer
I don't know but I would like to find out
- Developer
Also @lohenry which samples are you running on?
- Author Maintainer
Note as long as you are using LCG 101x (now default in the nightlies, but you might have to flip a switch in your local builds to pick it up), dd4hep now uses the same units as everyone else, so conversions between the two worlds is no longer required ( and if you are using the utilities in Detector to do this these are automatically noops).
@lohenry what LCG version did you build against locally ?
If you are using 101x, the the only way unit conversions can still be an issue is if you have hardcoded factors of 10, for the cm->mm change, which is now no longer needed.
Edited by Christopher Rob Jones - Developer
./Moore/run gaudirun.py Moore/Hlt/Moore/tests/options/default_input_and_conds_hlt2.py Moore/Hlt/RecoConf/options/hlt2_light_reco_pr_kf_without_UT_RICH_Calo_Muon_with_mcchecking.py Moore/Hlt/RecoConf/options/all-pmts-active.py | tee log.log
@jonrob I did not change anything so surely not the latest LCG version, however I think I have no conversion left (apart from the hack in Rec).
- Developer
We should use the samples in lhcb-datapkg/PRConfig!251 (closed) to test, as these have the latest geometry and decoding.
I am afraid
default_input_and_conds_hlt2.py
inmaster
is too old for the Velo, as we have seen before. - Author Maintainer
So, comparing dd4hep
to detdesc
things don't look too bad this morning ?
I think the issues you had with the long tracking @lohenry where probably solved by switching to LCG101x.
2 - Developer
I see differences of 1 and 2 tracks in
Forward
andMatching
, which I would consider "looking good"Edited by Michel De Cian 1 - Author Maintainer
b.t.w. big thanks to @lohenry for implementing The Big Hack for SciFi yesterday...
Edited by Christopher Rob Jones 1 - Maintainer
Can this issue be closed? Comparing the dd4hep and detdesc references of the
hlt2_light_reco_pr_kf_without_UT_with_mcchecking
test onx86_64_v2-centos7-gcc12-opt
I see a difference in the number of long tracks on the order of 0.1%.
- Christopher Rob Jones mentioned in merge request !3051 (closed)
mentioned in merge request !3051 (closed)
- Christopher Rob Jones mentioned in issue #326
mentioned in issue #326
- Christopher Rob Jones mentioned in merge request !3054 (closed)
mentioned in merge request !3054 (closed)
- Louis Henry mentioned in merge request !3055 (merged)
mentioned in merge request !3055 (merged)
- Louis Henry mentioned in merge request Detector!263 (merged)
mentioned in merge request Detector!263 (merged)