2025 Detector first release version

The Rich group has released a new version of the 2025 Geometry through !667 (merged). Based on this, a new LHCb geometry version needs to be released. This issue is created to track that.

According to the new naming convention, https://gitlab.cern.ch/lhcb/Detector/-/blob/master/CONTRIBUTING.md?ref_type=heads, this new version can be named as 2025.v00.00.

@gcorti @bcouturi @jonrob @msaur

assigned to @mexu

mentioned in merge request !667 (merged)

Following the comments from @jonrob , we need to do this a.s.a.p !667 (comment 9034987)

We need to do this as soon as possible, as it will take longer than expected to ensure the new tag is used and picked up in all the necessary places, both online and at the pit. It’s crucial to get this tag ready soon, even if it’s an early preliminary version that will be updated before data taking actually starts. I want to make sure we have all the updates ready to use it as soon as possible.

Please let me know your thoughts on this, as well as your opinion on the name. Once we reach an agreement, I will quickly create an MR to address this.

@gcorti @bcouturi @jonrob

I have no real opinion on the name other than perhaps follow the convention introduced with the 2024 tag run3/2024.Q1.2-v00.00

One other though is are there other sub system changes needed ? I mean like !669 (merged) which sounds like it might be a similar deal to the RICH change ?

Didn't you also @mexu mention FT might have some change they wish to make ?

But, yes, my main request is can we not delay making a tag too long...

b.t.w. the Q1 bit in the 2024 tag is probably a bit redundant. I would agree the year and a version is likely enough ? So run3/2025.v00.00 seems reasonable enough to me...

I need to make a new tag for the VP with the shims removed for 2025. I have been waiting for !374 (merged) to be merged before doing that, and I really hope it should be merged imminently. However, I can make a tag sooner if desperately needed, since the changes there only affect simulation.

BTW, the reason for having the Q1.2 bit in the 2024 tag was because it was originally envisaged that the VP shims would be removed during the June TS, so we'd need a different tag for the latter half of the year. But in the end, the removal was delayed until the current YETS. Since they have now been removed, the VP geometry should stay the same throughout 2025.

Its hardly a major point, but couldn’t you have just incremented the v00.00 part of the tag as required, when the shims where removed.

FT MRs are a bit tricky... We might go through all their open MRs with the FT team next week to clarify their purpose and the merge order, etc. I'm not sure if they will be merged in the short term...

As for Velo, yes.

Its hardly a major point, but couldn’t you have just incremented the v00.00 part of the tag as required, when the shims where removed.

No, because the geometry with the shims would have been applicable only to data taken during Q1.2 and the version without the shims would only have been applicable for data taken during Q3.4. It is a genuine difference in the detector geometry between the two parts of the year.

As for Velo, yes.

Sorry @mexu, I'm not sure which point this is in response to. Are you saying you do want me to make a 2025 VP version before !374 (merged) is merged?

sorry, I mean we can wait for !374 (merged)

OK thanks for clarifying :)

Following the merge of !374 (merged), I have now created !679 (merged) that includes a version of the VP geometry for 2025 (as well as an updated version of 2024)

for ref, we have 6 FT opening MRs:

• Add sensitiveVolumeID function in DeIOV, !664
• Add SciFi timing !659
• Update of FT utils, !653 (merged)
• FT conditions update for spillover emulation， !637

Anything that only affects simulation does not concern me from the RTA side. What we want there is to get whatever will affect data taking in asap and create a (first) tag as soon as we can so we are ready to start testing it. We need plenty of time for this prior to beam.

Based on the discussion at PAC I understood that is the plan. @mexu and @gcorti can confirm, but the agreement is on producing updated version of MC as soon as possible, even as it is not the final configuration, to allow enough time for various checks. When additional updates will be available then a new samples will be produced as well.

changed the description

The first tag shoudl include all things relevant for a first release and accoomdate both reconstruction and simulation requirements as much as possible.

There are a few things in the pipeline that should be included for a new version of 2024 that also should be picked up for a 2025 first version. Some have already been merged to component/XX/run3/trunk, so we need to cross check what is there and when needed make a directory tag for those componenets so that we can pick them up in the new version.

In the meantime we are already testing in Gauss the next geometry by usign lhcb/run3/trunk and we are introducing the same tests in Boole.

@mexu @gcorti Can you please comment on where we stand w.r.t. preparing the 2025 detector version ? from the RTA side I would really like to have this ready soon.

Sorry for the delay. I will create an MR for that today, then you and Gloria can comment on it.

mentioned in merge request !695 (merged)

closed with merge request !695 (merged)

mentioned in commit 6327d084