Geo: Fix Run 4 barrel beam pipe section

[f3sch]

Fix wrong radius of wrap-vol for the inner section of the beam pipe, introduced in #13772.
This disables effectively this part of the pipe since it is the mother volume of the actual pipe (the wrap-vol is smaller than the child volume).
This puzzled us for a while now since for ITS3 this improves the IP resolution by quite a large bit at low-pt.
Material before:

Material after:

@fgrosa @ChunzhengLab this is hopefully all lets rerun the sims from scratch (for proper hit generation).

@hahassan7 or is there something I am overlooking?

[github-actions]

REQUEST FOR PRODUCTION RELEASES:
To request your PR to be included in production software, please add the corresponding labels called "async-" to your PR. Add the labels directly (if you have the permissions) or add a comment of the form (note that labels are separated by a ",")

+async-label <label1>, <label2>, !<label3> ...

This will add <label1> and <label2> and removes <label3>.

The following labels are available
async-2023-pbpb-apass4
async-2023-pp-apass4
async-2024-pp-apass1
async-2022-pp-apass7
async-2024-pp-cpass0
async-2024-PbPb-apass1
async-2024-ppRef-apass1
async-2024-PbPb-apass2
async-2023-PbPb-apass5

[f3sch]

@sawenzel and @hahassan7, actually I suspect this is the case for all vacuum volumes (though I stopped looking after the Bellow...)
So, probably there are currently no material interactions generated for most of the material heavy objects of the pipe, which is probably quite bad for FOCal simulations and should be checked and possibly fixed.

Or more general, is there any reason why we should not use Pipe as a base class to avoid wrong code duplication?

[alibuild]

Error while checking build/O2/fullCI_slc9 for d7058d3 at 2025-09-03 04:11:

## sw/BUILD/O2-full-system-test-latest/log
Detected critical problem in logfile reco_NOGPU.log


## sw/BUILD/o2checkcode-latest/log
--
========== List of errors found ==========
++ GRERR=0
++ grep -v clang-diagnostic-error error-log.txt
++ grep ' error:'
++ GRERR=1
++ [[ 1 == 0 ]]
++ mkdir -p /sw/INSTALLROOT/51f322d80dd22a5c386d40228f9478242e558f5a/slc9_x86-64/o2checkcode/1.0-local412/etc/modulefiles
++ cat
--

Full log here.

[hahassan7]

Hi @f3sch , Sorry for my late reply. The vacuum inside the pipe should be from 0 to the internal radius of the pipe, so from 0 to outerRadius - thickness. If you make it from 0 to outer radius, then the pipe vacuum volume will overlap with the beryllium pipe volume. But then you are right that the volume should always be added into a bigger volume. So I think the right thing to do would be to add the vacuum volume into the beryllium one or keep the vacuum volume as independent and add it into the mother volume of both.

[f3sch]

@hahassan7, the vacuum is the mother volume e.g. IP_PIPEMOTHER, the line I changed modified the shape of this volume. The point is exactly that the child, in this case IP_PIPE, must be completely contained in the mother volume, otherwise the stepping does not work.
And, I think the way it is done, is the natural one, e.g. first defining the empty space, here a vacuum, and then filling it with things to occupy it, here the actual pipe.

The point why I pinged, was that I suspect that this also wrong maybe for more volumes of this Run4 beam pipe.
For the bellow for example, we have:

  aluBeforeBellows->DefineSection(3, kZ6, kBellowSectionOuterRadius - kBeryliumSectionThickness, kBellowSectionOuterRadius);
....
  aluBeforeBellowsVacuum->DefineSection(1, kZ6, 0., kBellowSectionOuterRadius - kBeryliumSectionThickness);

in this case, as is natural, the vacuum is the mother volume of the actual bellow stretching from kBellowSectionOuterRadius - kBeryliumSectionThickness to kBellowSectionOuterRadius. However the vacuum only goes until the inner radius. Thus when stepping through the geometry, the modeler will never reach the actual bellow and not produce any hits.
Which of course, triggered my other question, why we could not make this inherit from the already correct Pipe and save a bit of code duplication, since most of the pipe will stay the same and only very small sections of it need modifications.

[hahassan7]

@f3sch , I just checked, you are actually right. When we add a node into a mother volume the node overrides the mother's material, so the vacuum is removed and replaced with beryllium. So what you did is the right thing. It would be also nice if you can do the same for the other volumes ? if not I will take care of them later at some point.
Thanks for the fix.

[f3sch]

I would rather like to move forward with merging this since I don't want to fiddle with things without the means to check the impact.

@sawenzel if good for you, please merge.

[sawenzel]

Thanks for the fix!

[sawenzel]

The suggestion to do a separate Run4 pipe came from myself. While there are advantages to share code between all pipes, a separate code for a separate LHC run is less risky. It allows to do things in more isolation.