add tot and charge and sizes plots

Add few more variables to ACTS pixel clusters for ART tests. These are computed within IDPVM. This adds charge and tot and their relation @pibutti

@sroe from a quick check, I see that tot of 14, 15 and 16 now provide positive charge. The tot of 16 still happen in the endcap (I do not see them in the barrel but it may well be just luck).

Maybe we can increment the value to 2e5 (instead of the current 1e5) for these big tot values (since tot=13 gives 1.2e5)? Do I get it right that the 15 and 16 tot values will disappear with a dedicated MR addressing https://its.cern.ch/jira/browse/ATLITKSW-301 ?

added ACTS label

This merge request affects 2 packages:

• InnerDetector/InDetValidation/InDetPhysValMonitoring
• Tracking/Acts/ActsMonitoring

Affected files list will not be printed in this case

Adding @keli ,@battagl ,@pagessin ,@lshan ,@jburzyns ,@tbold ,@cvarni ,@sroe ,@lgagnon ,@jojungge ,@stsuno ,@goetz ,@toyamaza as watchers

added InnerDetector PhysValidation Tracking main review-pending-level-1 labels

changed the description

Hi @cvarni, these are very useful, thanks...and we should keep an eye on these plots as we develop the calibration strategy. To address your questions:

• 14, 15 and 16 are all just 'overflow' but I see that indeed the charge value should be increased; I will follow your suggestion and set it to 2e5.

• Yes, the MR addressing ATLITKSW-301 should get rid of the 15,16 values in the RDO

Additional comment: While changing the code to get rid of the 15,16 values I noticed there is a lower level cutoff also, which is set to 1 (i.e. the code effectively does if (ToT<1) ToT =1;. I didn't have time to make the random number plot and check whether this makes sense, but I think it is reflected in the plot you show which gives a higher probability for the 1 value. Perhaps these should simply be thrown away, I don't think it makes sense to have ToT = 0 as there has to be some threshold.

Hi @sroe, I might be completely off course here, but I was wondering these days what are the reasons for very long clusters we see in Pixel. Carlo and I were looking to the pixel size vs eta of the cluster for the various barrel layers and at low eta we noticed somewhat large clusters. (in attachment a plot of the cluster size in X vs cluster eta for innermost barrel layer). @goetz has shown that such large clusters carry some problems for position / uncertainty estimates (see his event display)

I was indeed about to ask what are the current settings for threshold for Pixel sensors and how low charge deposits are treated. Are you saying that we are risking to attach many low charge hits to simulated clusters that should be cut away by proper pixel settings?

Let me also tag @tstreble and @ncalace concerning the tot<1 point

resolved all threads

@sroe can you open a JIRA about this? we should bring the discussion there instead of using the MR as the discussing ground XD

resolved all threads

resolved all threads

CI Result SUCCESS (hash 24394874)

	Athena
externals
cmake
make
tests

Full details available on this CI monitor view. Check the JIRA CI status board for known problems
Athena: number of compilation errors 0, warnings 0
For experts only: Jenkins output (remote access info)

added ITk label

Changes are fine and CI succeeds, approving for L1. -L1

added review-approved label and removed review-pending-level-1 label

merged

mentioned in commit 6f60dcee