Decreasing Module Size in Maps Degrades Performance Significantly

[GNiendorf]

See SegmentLinking/LSTGeometry#9 for more information and the plots below. In the module maps the sensors are assumed to be (100, 100) mm or (100, 50) mm (width, length) but the geometry CSV files from tklayout specify them as (91.4, 100.5) mm and (96.0, 46.9) mm, slightly smaller. Using these sizes in the module map assumptions leads to the fake rate spiking and efficiency decreasing.

[GNiendorf]

See histograms below for comparison of the two module maps and also total number of connections change.

Number of Straight Connections: 67,980 reduced to 64,718 (csv sizes)
Number of Curved Connections: 128,852 reduced to 121,274 (csv sizes)

[GNiendorf]

Seems like the difference in fakerate is coming from the pT3's.

CSV Size Plots: Here
Master Plots: Here
Comparison: Here

[GNiendorf]

Here I've raised the sizes to (120, 120) mm and (120, 70) mm and we get a small fakerate decrease in some bins from making the modules larger, but not by much.

Big Boned Module Plots: Here
Master Plots: Here
Comparison Plots to Master: Here

[slava77]

Seems like the difference in fakerate is coming from the pT3's.

please add links to full plots for both cases (not just CSV and comparisons)

[slava77]

Here I've raised the sizes to (120, 120) mm and (120, 70) mm and we get a small fakerate decrease in some bins from making the modules larger, but not by much.

now I'm curious if we can go lower in size below the "hit-based" without a loss of efficiency and increase in fakes yet (subtract, e.g. a half of the difference)

[GNiendorf]

If I do half of the extensions, so half way between the hit-based and CSV sizes, I don't see a fakerate jump.

Number of Connections, Straight: 67,980 reduced to 64,886
Number of Connections, Curved: 128,852 reduced to 124,458

Ignore the labels below, it should say, "In-between" sizes or something like that for the green.

Keep in mind the plots below are in comparison to Master.

In-Between Sizes: Here
Master: Here
Comparison: Here

[slava77]

If I do half of the extensions, so half way between the hit-based and CSV sizes, I don't see a fakerate jump.

interesting

how about 1/4?

[GNiendorf]

I just want to point out too that this isn't an issue in my code. If you change the current hit-based code from Phillip to use the slightly smaller csv sizes then you get the performance plots below @slava77 @VourMa

Hit-Based Geometry with CSV Module Sizes: Here
Master Plots: Here
Comparison: Here

Comparison to Master below, showing the fakerate of pt3's going up.

[YonsiG]

We found some hardcoded places in the LST code package that the module sizes are hardcoded. Some examples are in the links below. This indicates that if we change the module size in the module map, we need to also change those consistently. More places need to be checked.

TrackLooper/SDL/Constants.h

Lines 160 to 161 in 78d8d24

	ALPAKA_STATIC_ACC_MEM_GLOBAL const float pixelPSZpitch = 0.15;
	ALPAKA_STATIC_ACC_MEM_GLOBAL const float strip2SZpitch = 5.0;

TrackLooper/SDL/Quintuplet.h

Lines 1185 to 1187 in 78d8d24

	float inv1 = 0.01f / 0.009f;
	float inv2 = 0.15f / 0.009f;
	float inv3 = 2.4f / 0.009f;

TrackLooper/SDL/PixelTriplet.h

Lines 830 to 836 in 78d8d24

	//PS Modules
	if (moduleType == 0) {
	error = 0.15f;
	} else //2S modules
	{
	error = 5.0f;
	}

.

TrackLooper/SDL/Triplet.h

Line 362 in 78d8d24

0.015f * alpaka::math::sqrt(acc, 0.1f + 0.2f * (rtOut - rtIn) / 50.f) * alpaka::math::sqrt(acc, r3In / rtIn);

[GNiendorf]

Just want to add for @YonsiG's comment that the 0.15 number is the pixel size for the PS module, not the module size.