Draft: IGNORE: draft merge of run5 into master to get public diff to work out what still needs to be done
Merge request reports
Activity
603 603 output_transform=lambda Output: {"DataKeys": [location]}, 604 604 **kwargs 605 605 ).Output 606 out.force_type(force_type) 606 if force_type != "" : 607 out.force_type(force_type) this is not needed -- instead of doing
make_data_with_FetchDataFromFile(... , force_type='')which this enables, you can already domake_data_with_FetchDataFromFile(... , force_type='unknown_t')if that is really what you want to...aside: I'd very much would like to learn the circumstances where specifying 'unknown_t' -- or not specifying anything, which is the same thing as specifying 'unknown_t', just less explicit -- would actually be needed/usefull, as almost any code that uses the result will have a strong opinion on what types it will accept, and if it is the wrong one, it is just going to generate an error downstream during the event loop.
added RTA label
added Upgrade2 label
added 231 commits
-
f8d1a49d...d67cfc78 - 229 commits from branch
master - 85bac652 - rebase
- 45f0e255 - Merge branch 'run5-rebased' into run5
-
f8d1a49d...d67cfc78 - 229 commits from branch
48 48 }; 49 49 50 50 // number of detector layers/regions 51 enum Number { NumVelo = 26, NumUT = 4, NumFT = 12, NumMuon = 5 }; 51 enum Number { NumVelo = 32, NumUT = 4, NumFT = 12, NumMuon = 5, NumMP = 6 }; 53 53 { "accT3S", &MCTrackInfo::accT3S }, 54 54 { "accT1", &MCTrackInfo::accT1 }, 55 55 { "accT2", &MCTrackInfo::accT2 }, 56 { "accT3", &MCTrackInfo::accT3 } } ) {} 56 { "accT3", &MCTrackInfo::accT3 }, 57 { "hasFT", &MCTrackInfo::hasFT }, 58 { "hasMP", &MCTrackInfo::hasMP } } ) {} -
On those classes, i think it will be better to have those defined and moved out of LHCb but make them in Rec. I don't think we use any of those at the level of Gauss, but only Boole eventually if we create those track info objects as part of Boole step "given-digitisation". As we are not yet there, i would not change this code here. tell me if I am wrong on this, but part of the "rewriting the TrackInfo" was exactly to avoid having this code overlapping to run1/2/3 definitions allowing backward compatibility. We will anyway have to re-modify all this for magnet station in case or study and determine what makes sense or not to define with new trackers.
-
@tevans i see that now we have some conflicts to master here. Not sure if we know why, but i tried to merge master locally and fix them in !5022 (merged) . I wonder if it's better that i try to run the full chain again with this and other run5-branches rebased and if all works, i just push directly to this branch?
mentioned in merge request !5022 (merged)
added 2 commits
added 40 commits
-
a6d33c0a...d4a4a8f7 - 39 commits from branch
master - e81cd4fb - Merge remote-tracking branch 'origin/master' into run5
-
a6d33c0a...d4a4a8f7 - 39 commits from branch