- In the latest p17.06.00 production release noticed SMT hits deficit in events with the zero bias (ZB) data overlay => Reason of the low tracking efficiency
- Tests have been repeated with newer p17.06.01 release that had some, not directly related to the issue fixes; results are similar
- Older
releases show similar problem
- Effect is not seen when MC min. bias data are overlaid
- Effect is occupancy dependent (?)
 |
 |
 |
 |
Comments
- Plots show the number of SMT hits associated to a reconstructed track
- Statistics correspond to 3 bb (+ X) and 10 single neutrino + ZB events, respectively
- Plot on the upper-right corner illustrates the issue: too few tracks in events and they are of a low quality since fewer SMT hits are associated to them
Bug fix
Apparently, "DetId" (detctor identificator in a packed form) for MC and data are not identical. As a result, hits are corrupt, or lost from the entire "p-side" of SMT when MC and data are merged in "smtdigi". Here are deatils from Alex and Lisa:
- In SmtDataChunk
In Barrels that have only double-sided
ladders (Barrel=2,3,4,5)
in bbbar_only sample:
on the p-side there are 2446 bbbar strips
on the n-side there are 2918 bbbar strips
in bbbar+zb sample:
on the p-side there are 0 bbbar strips
on the n-side there are 3021 bbbar strips
in bbbar_only sample:
on the p-side there are 2446 bbbar strips
on the n-side there are 2918 bbbar strips
in bbbar+zb sample:
on the p-side there are 0 bbbar strips
on the n-side there are 3021 bbbar strips
- Proposal
Hello all,
finally I guess I found at least the main source of the problem.
A crucial point required for smtdigi package to work correctly is that
d0gstar hits entering smtdigi are sorted in tkHitList in the ascending
order of detector id. This requirement is necessary because smtdigi
collects charge from all hits belonging to one detector element (ladder or
wedge), then goes to the next detector element, collects all charge, etc.
Pileup package does not do any hit ordering. It is done in a simple inline
function which is a part of smtdigi and called compareDetId which accesses
DetIds of two sequencial hits and then the tkHitList is sorted according to
the DetIds. This procedure works correctly for ordering MC hits only and
zerobias hits only which agrees with our observations. The problem shows up
when we try to order a combination of MC and ZB. The reason is that DetId
are created differently in d0gstar MC and smt_real2mc packages.
Since d0gstar hit knows only about system, barrel, layer, ladder this is
what we pack as hit DetId. On the other hand, when converting real data hit
into MC format we already know system, barrel, layer, ladder, view and
strip number. Therefore when we do detid =
SmtAddress::Encoder(dettype,barrel,layer,ladder,view,Bstrnum);
in smt_real2mc we always have larger encoded number then when we do in
simpp
detid = SmtAddress::Encoder(dettype,barrel,layer,ladder,1,0);
Therefore for hit from ZB DetId will ALWAYS be larger than for MC hit
belonging to the same barrel,layer,ladder. For example, all true MC hits
belonging to bar 1 lay 3 lad 1 view 1 (view is always 1 for MC hits) have
DetId 321 while ZB hits range from 3662145 to 5112129 depending on the
strip number.
As a consequence, all MC hits enter the list first followed by all ZB hits.
So hits belonging to the same detector element will be in different parts
of the list and will be never merged correctly.
The most straightforward solution would be to change detid in smt_real2mc
from
detid =
SmtAddress::Encoder(dettype,barrel,layer,ladder,view,Bstrnum);
to
detid = SmtAddress::Encoder(dettype,barrel,layer,ladder,view,0);
but this will require rerunning zero bias samples.
The less painful solution is to modify compareDetId function. Now it gets
only DetId. Then we can unpack this DetId to exatact barrel, layer, ladder,
view and strip number. If strip number is not zero (it will happen for ZB
hits) do
detid = SmtAddress::Encoder(dettype,barrel,layer,ladder,view,0);
and compare DetId after that modification.
I guess Slava or Alex can fix it. Then it needs to be tested obviously.
Cheers
Lisa
finally I guess I found at least the main source of the problem.
A crucial point required for smtdigi package to work correctly is that
d0gstar hits entering smtdigi are sorted in tkHitList in the ascending
order of detector id. This requirement is necessary because smtdigi
collects charge from all hits belonging to one detector element (ladder or
wedge), then goes to the next detector element, collects all charge, etc.
Pileup package does not do any hit ordering. It is done in a simple inline
function which is a part of smtdigi and called compareDetId which accesses
DetIds of two sequencial hits and then the tkHitList is sorted according to
the DetIds. This procedure works correctly for ordering MC hits only and
zerobias hits only which agrees with our observations. The problem shows up
when we try to order a combination of MC and ZB. The reason is that DetId
are created differently in d0gstar MC and smt_real2mc packages.
Since d0gstar hit knows only about system, barrel, layer, ladder this is
what we pack as hit DetId. On the other hand, when converting real data hit
into MC format we already know system, barrel, layer, ladder, view and
strip number. Therefore when we do detid =
SmtAddress::Encoder(dettype,barrel,layer,ladder,view,Bstrnum);
in smt_real2mc we always have larger encoded number then when we do in
simpp
detid = SmtAddress::Encoder(dettype,barrel,layer,ladder,1,0);
Therefore for hit from ZB DetId will ALWAYS be larger than for MC hit
belonging to the same barrel,layer,ladder. For example, all true MC hits
belonging to bar 1 lay 3 lad 1 view 1 (view is always 1 for MC hits) have
DetId 321 while ZB hits range from 3662145 to 5112129 depending on the
strip number.
As a consequence, all MC hits enter the list first followed by all ZB hits.
So hits belonging to the same detector element will be in different parts
of the list and will be never merged correctly.
The most straightforward solution would be to change detid in smt_real2mc
from
detid =
SmtAddress::Encoder(dettype,barrel,layer,ladder,view,Bstrnum);
to
detid = SmtAddress::Encoder(dettype,barrel,layer,ladder,view,0);
but this will require rerunning zero bias samples.
The less painful solution is to modify compareDetId function. Now it gets
only DetId. Then we can unpack this DetId to exatact barrel, layer, ladder,
view and strip number. If strip number is not zero (it will happen for ZB
hits) do
detid = SmtAddress::Encoder(dettype,barrel,layer,ladder,view,0);
and compare DetId after that modification.
I guess Slava or Alex can fix it. Then it needs to be tested obviously.
Cheers
Lisa
- After fix (following 2nd soulution)
