[ALICE3] Rough attempt to pave ML disks as done for OT

[scannito]

No description provided.

[Copilot]

Pull request overview

This PR attempts to extend the existing “segmented/module” (front/back sensor) paving used for OT disks to also cover ML disks in the ALICE3 FT3 geometry.

Changes:

• Add a new Rin == 10 configuration and enable the “v3 paving” X-position logic for Rin == 10 in FT3Module::create_layout.
• Change FT3Layer::createLayer so ML layers are no longer forced into the trapezoidal path when layoutFT3 == kSegmented.
• Modify Detector::defineSensitiveVolumes to (effectively) register only the segmented front/back sensor volumes.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.

File	Description
Detectors/Upgrades/ALICE3/FT3/simulation/src/FT3Module.cxx	Adds Rin==10 offset handling and extends special paving logic to Rin==10 as well as Rin==20.
Detectors/Upgrades/ALICE3/FT3/simulation/src/FT3Layer.cxx	Adjusts layout selection so kSegmented can apply to ML layers (commented-out prior special-casing).
Detectors/Upgrades/ALICE3/FT3/simulation/src/Detector.cxx	Changes sensitive-volume registration to scan only segmented front/back sensor volume names.

Comments suppressed due to low confidence (3)

Detectors/Upgrades/ALICE3/FT3/simulation/src/FT3Layer.cxx:245

• The layout selection now contains commented-out logic inside the if condition, and the nearby comment claims “only OT disks are segmented”, which is no longer true when layoutFT3 == kSegmented now routes ML layers into the segmented branch. Please remove the commented-out condition and update the comment to match the current behavior (or re-introduce an explicit ML-vs-OT condition if still required).

  // ### options for ML and OT disk layout
  if (ft3Params.layoutFT3 == kTrapezoidal /*|| (mIsMiddleLayer && ft3Params.layoutFT3 == kSegmented)*/) {
    // trapezoidal ML+OT disks
    // (disks with TGeoTubes doesn'n work properly in ACTS, due to polar coordinates on TGeoTube sides)

    // (!) Currently (March 12, 2026), only OT disks are segmented --> use Trapezoidal option for ML disks as a simplified segmentation
    // To be changed to "true" paving with modules, as for the OT disks

Detectors/Upgrades/ALICE3/FT3/simulation/src/FT3Module.cxx:218

• The Rin == 10 and Rin == 20 branches are identical (same offsets/flags). Consider merging them into a single condition (e.g., Rin == 10 || Rin == 20) or factoring these offsets into a small lookup to avoid future drift between the two configurations.

  } else if (Rin == 10 && sensor_height == 9.6 && sensor_width == 5.0) {
    x_condition_min = -Rin - 4;
    x_condition_max = Rin;
    dist_offset = 2;
    adjust_bottom_y_pos = false;
    adjust_bottom_y_neg = false;
    x_adjust_bottom_y_pos = 3.5;
    bottom_y_pos_value = 3.5;
    bottom_y_neg_value = -3.5;
  } else if (Rin == 20 && sensor_height == 9.6 && sensor_width == 5.0) {
    x_condition_min = -Rin - 4;
    x_condition_max = Rin;
    dist_offset = 2;
    adjust_bottom_y_pos = false;
    adjust_bottom_y_neg = false;
    x_adjust_bottom_y_pos = 3.5;
    bottom_y_pos_value = 3.5;
    bottom_y_neg_value = -3.5;

Detectors/Upgrades/ALICE3/FT3/simulation/src/FT3Module.cxx:257

• In the special paving path (if (Rin == 10 || Rin == 20)), the function parameter overlap is ignored and shadowed by a hard-coded local float overlap = 0.3. This makes the caller-provided overlap ineffective and can also trigger shadowing/unused-parameter warnings depending on compiler flags. Consider using the passed-in overlap (with a sensible default when it’s 0/unset) or renaming the local variable and removing the unused parameter if it’s not meant to be configurable.

    if (Rin == 10 || Rin == 20) { // v3 paving, rough attempt
      float overlap = 0.3;
      // NB: these are left edges
      float X_start = -2.0 - 13.5 * (sensor_width - overlap);
      float X_start_pos = 2.0 - 0.5 * (sensor_width - overlap);

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

defineSensitiveVolumes() now always searches for FT3Sensor_front_* / FT3Sensor_back_* volumes and no longer registers the single sensor volumes created by the kTrapezoidal/kCylindrical layouts (named via GeometryTGeo::getFT3SensorPattern()), which would result in 0 sensitive volumes (and therefore no hits) when those layouts are selected. Consider branching on FT3BaseParam::layoutFT3 (or detecting which volumes exist): for non-segmented layouts, look up the per-layer sensor volume and fail loudly if it’s missing; for segmented layouts, keep the front/back scan. Also consider treating iSens == 0 as an error to avoid silent misconfiguration.

[Copilot]

After commenting out the ML special-case, volumeName is assigned but never used. If the build enables -Wunused-but-set-variable / -Werror, this can break compilation; otherwise it’s still dead code. Please remove volumeName (or restore its use as part of the sensitive-volume lookup).