Following on from the meeting today, for the FTHitEfficiencyMonitor, it should be configured as follows:
from RecoConf.hlt1_tracking import make_PrStoreSciFiHits_hits, make_FTRawBankDecoder_clusters
from PyConf.Algorithms import PrKalmanFilter_noUT, PrKalmanFilter_Velo, PrKalmanFilter_Seed, PrStoreSciFiHits, FTHitEfficiencyMonitor
for layer_under_study in range(12): # histograms for the first station
with PrKalmanFilter_noUT.bind(FillFitResult=True), \
PrKalmanFilter_Seed.bind(FillFitResult=True), \
PrKalmanFilter_Velo.bind(FillFitResult=True), \
make_PrStoreSciFiHits_hits.bind(disabled_layers=[layer_under_study]):
hlt2_tracks = make_tracks(light_reco=True, fast_reco=False, use_pr_kf=True)
ttracks = hlt2_tracks['BestSeed']['v1']
my_enabled_layers = [
j not in [layer_under_study] for j in range(12)
]
all_FT_pr_hits = PrStoreSciFiHits(
HitsLocation=make_FTRawBankDecoder_clusters(),
LayerMasks=tuple(my_enabled_layers)).Output
my_ft_efficiency_alg = FTHitEfficiencyMonitor(
name="FTHitEfficiencyLayer{}".format(layer_under_study),
TrackLocation= ttracks,
PrFTHitsLocation=all_FT_pr_hits,
LayerUnderStudy=layer_under_study)
data += [my_ft_efficiency_alg]
return CompositeNode(
"Monitoring",
data,
combine_logic=NodeLogic.LAZY_AND,
force_order=True
)
after some investigating and help from Laurent, it appears that the lack of thread-safety when running this multi-threaded might be coming from DD4HEP rather than the FT, we have reached out to the experts for advice.
Please let me know any other info you need. Many thanks
I reverted that MR locally and it is indeed the source of the change.
@jzhuo and I discussed a bit on friday why this might be happening. If I understand correctly, now the full relation tables are being persisted, whereas before only a single relation was. Also the thresholds are quite loose. So probably the MCTruthAndBkgCat
algorithm is using an incorrect relation from the table. Given that the particles are now being matched to e-, I would guess the it is now using a relation to a material interaction, but would need to do more tests to confirm
Izaac Sanderswood (f94f6541) at 23 Mar 23:19
Izaac Sanderswood (94af8163) at 23 Mar 23:19
Izaac Sanderswood (cd6432d5) at 22 Mar 18:25
update caloPID momentum to use fitted track momentum
... and 12 more commits
now described in Moore#736
I think LHCb!4453 may have caused a new truth matching bug incorrectly matching tracks to electrons (not yet confirmed).
If I compare master with an older version (Moore v54r22p6) for 1000 events in the same sample, we now have a sudden increase in the number of tracks truth matched as electron (by a factor of more than 13). The effect is has a charge asymmetry, in that the increase only appears to be for e- and not e+. Most of these seem to be coming from tracks previously matched to pions, but not exclusively.
I only notice because I am working on the Calo PID for T tracks, and the long track ECALPIDE distribution looks very wrong, with almost all "true electron" long tracks having a very low score, meaning this is probably a truth matching error and these are not really electrons. (The sample is a BSM B\to KH'(\to\mu\mu)
so the electrons are not signal but coming from the rest of the event, hence the low stats.)
The issue only seems have a small effect on T tracks, if any, so it is only Longs (I didn't check Downstream).
I have not yet confirmed that it is coming from here, but it seems the most likely culprit, but I think this MR may have caused a new truth matching bug incorrectly matching tracks to electrons.
If I compare master with an older version (Moore v54r22p6) for 1000 events in the same sample, we now have a sudden increase in the number of tracks truth matched as electron (by a factor of more than 13). The effect is has a charge asymmetry, in that the increase only appears to be for e- and not e+. Most of these seem to be coming from tracks previously matched to pions, but not exclusively.
I only notice because I am working on the Calo PID for T tracks, and the long track ECALPIDE distribution looks very wrong, with almost all "true electron" long tracks having a very low score, meaning this is probably a truth matching error and these are not really electrons. (The sample is a BSM B\to KH'(\to\mu\mu)
so the electrons are not signal but coming from the rest of the event, hence the low stats.)
The issue only seems have a small effect on T tracks, if any, so it is only Longs (I didn't check Downstream).
I think in order to change it I need to remove the const from the pid pointers, will this be an issue?
thanks, working on it now. Is there an easy way to correct the EoP's to use the fitted track momentum?
Izaac Sanderswood (474cdd13) at 21 Mar 15:09
Merge branch 'bandq_turboPersist_to_fullAndSpruce' into 'master'
... and 11 more commits
thanks! done
thanks! done
thanks! done
thanks! done
Thanks, I changed to unsigned int
and added a check that requires the index is less than the size of the ancestor container.
As for the correct magic value, I am not sure there is an easy way to figure it out. I have added a comment so people know it depends on the order the algorithms run, and in the ancestor associator algorithm there is a check that there are no ancestors. I don't think SmartRefVector
have keys, so not sure if it would be possible to explicitly define an index
thanks done
Izaac Sanderswood (0fda510e) at 21 Mar 14:40
improve code, add comments, add checks for ancestor index
... and 1087 more commits
Izaac Sanderswood (b26b53c8) at 21 Mar 14:11
Merge branch 'isanders-relationtable1d-addunique' into 'isanders-Ch...
... and 1 more commit
Izaac Sanderswood (79383da2) at 21 Mar 14:11