I am currently working on the analysis of our most recent testbeam with the RD50-MPW4. There are not many details of the chip needed for this topic here, despite that the MPW4 is a small size (4 x 4 mm^2) prototype.
I wanted to use the fake rate histograms of the AnalysisEfficiency module to estimate the noise level.
A few things:
Using the “RADIUS” method:
I encountered a mean fakePixelPerEvent of ~1.1, which definitely is far too high and not realistic. The reason (by checking the code) is that tracks that do have an intercept get skipped (line 574). Shouldn’t it be the other way around, skipping tracks without an intercept (With our small DUT, we have quite a few of those)? Or do I miss something, and this is actually intended behavior?
Using the “EDGE” method:
I encounter a mean fakePixelPerEvent of ~0.9. Still far too high. Here, we need to have any track intercepting the DUT, and all clusters/pixels are considered as good / not fake. The problem is, though, that the hFakePixelPerEvent and hFakeClusterPerEvent histograms only get filled if we run into the track_in_active if condition in line 630. In my opinion, these 2 histograms have to be filled with “0” if track_in_active == true. For the other histograms, it makes sense to only fill them when we deal with a fake hit, but these two should be treated differently imho.
Doing it how I proposed (filling with 0), I get ~0.45 fakePixelPerEvent. Better, but still not realistic. Placing a few debug messages → the vast majority of “fake”-clusters result from events in which a few telescope planes got hit, but the number of hit planes < min_hits_on_track of the Tracking4D module. To me, it looks like particles got scattered somewhere downstream of the DUT → no Track as downstream telescope planes not fully hit → still cluster on DUT should not be considered fake. The comment in line 627 indicates that somebody was thinking about this problem:
// Study the dut response if there is no track pointing to the active
// area of the dut. There might still be particles, that we failed to
// track!
How could one resolve this and make a proper noise estimate possible?
One could check for hits on telescope planes and demand that there must be none but at least one on the DUT for clusters to be considered fake. However, what if other planes are noisy? Having a noise hit in one telescope-plane in the same event as a noise hit on the DUT would suppress the fake classification of the DUT cluster…
fake_rate_method : Method used in the fake rate estimate. The main idea is to look for clusters and hits that are far away from reconstructed tracks. Those are defined as fake, which neglects effects of tracking in-efficiency. There are two slightly different methods. The RADIUS method considers DUT clusters without reconstructed track in a radius of fake_rate_distance pixel pitches around them as fake. The EDGE method looks for events without tracks intercepting the DUT within its active area plus fake_rate_distance pixel pitches in each direction, and considers all DUT activity in these events as fake. The former method is intended for large DUTs, the latter for small ones. Defaults to RADIUS .
It is preferred to use the EDGE method if you do have small DUTs (4x4 pixels in our case). Depending on your cuts 4x4mm2 might be considered large
This might be a bug @ffeindt has written the extension and might comment on this after being back from vacation. In the meantime, I would try to invert the logic and see what is happening (adding a ! in line 574).
This is behaving as intended since only events where there is no track reconstructed should be considered. In this case you only want to study exactly these events, so your proposal
will change your fake noise with the triggering/on-dut tracking efficiency, which is in your case roughly 50%, bringing you down from 0.9 to 0.45. This should not be intended behaviour to me
I believe testing the radius method is what you want. 4x4mm2 are highly unlikely to be hit twice in one event. So if there is a track, everything not associated can be declared noise.
As a side remark - I think it is dangerous to assume that one knows the noise rate/event of a detector. In this case, there would be no need for the study. A very first estimate can be the ratio of clusters to tracks for events with a track. (simply place the clustering of your dut behind the module that filters on the number of tracks.
Hi @bpilsl, thank you for bringing this up! I agree with @lhuth,
The first point you raise regarding the “RADIUS” method indeed looks like a mistake to me. Sorry for that, I am a bit puzzled how that slipped testing and reviewing. It would be nice if you could correct and test that again.
Regarding the “EDGE” method, everything looks fine to me. You consider only events where nothing came close to your sensor, the rest is no part of your denominator — so to speak.
The last point is something I am aware of, hence the caveat in the documentation. So, as long as your tracking efficiency is far from unity, but constant, the module indicates if your noise goes up due to a change in operating conditions (handy, e.g. in a threshold scan). If you want a correct number, you need to ensure that your tracking efficiency is high (I think the tracking modules come with tons of options to optimize that), and to avoid combinatorial background (e.g. filter events with more than one track).
Fixing the RADIUS method is pretty straight forward. The if-condition simply needs to get inverted. I’ll file a merge request as soon as I figured out a problem with the CI
On the edge method I do not quite agree though. In my opinion the way it is implemented in the moment is not very intuitive. When I look at a “fake hits per event” histogram, I would expect events without a fake hit to have an effect on it too. The way it is implemented atm only fills these histograms when we run in the “!track_in_active” if condition in line 630. So when no track is in the current event, these histograms are not being filled at all, so they represent something more like a "fake hits per event for events without a track intercepting the DUT. I think the way it is done in the RADIUS method (l. 606 - l. 609) by filling those histograms also in case of no fake hits with 0, no matter if there was a track for this event or not would also be better suited for this method.
But OK if this is how you picture the EDGE method to fill those histograms, it’s fine by me and I also get your arguments, for my specific use case the “fixed” RADIUS method is the one to use than.
I agree with both of you, getting a noise estimate this way is not straight forward and I’ll instead look into Lennart’s proposal. I’ll also look into the proposal of relaxing the track fitting parameters a bit to get a better tracking efficiency though.
Just to clarify the idea behind the EDGE method (and to exclude that there is a flaw in the logic we had):
is exactly what is being determined by this. If there is no track at all, one does not know if a) no particle passed the dut or b) we missed the track in the reconstruction. b) will happen in 10% of the cases for ADENIUM if you ask for 6 hits per track.
If you have a track, that does not intersect with your DUT and the active area is small enough to have <=1 track per trigger you precisely know that whatever your DUT has seen is fake. So it does represent the fake hits per event. The only caveat is that you need a significant fraction of events that do not hit your DUT. If you add a zero for every event with a track, you bias yourself. Imaging your trigger being smaller than the DUT: With the current implementation you would state that you cannot give any number for this. Your proposal would always result in 0 fake hits/event.
The same logic holds for the RADIUS method where events are skipped, where no track is reconstructed. In this case, you have no chance to determine if the hits belong to a track that you have not reconstructed or are fake.
“fake hits per event for events without a track intercepting the DUT”
This is exactly what you want. Just imagine it like a dark measurement that you would do in the lab.
