Updated BTLDetId format potentially breaking backward compatibility

[fabiocos]

The recent PR #46977 updates the BTL numbering scheme, and correspondingly the BTLDetId data format, in its expected final format, as the layout is now frozen. This implies that the meaning of bit fields changes, this is tracked in the new version of the format with a dedicated bit, distinguishing old and new, with a translation function that is applied in the constructors depending on the presence of this bit or not. The schema evolution of the BTLDetId object is correctly managed in the IO rule.

Until the explicit construction of BTLDetId is involved, everything works smoothly, and backward compatibility is ensured by the id translation made in the constructors, as tested by processing in a typical runTheMatrix workflow step-1 input made with the old format with code using the new format. Anyway when access is needed to a collection storing the BTLDetId in its bare uint32_t format, and no explicit conversion is made, this may cause failures as that identifier is not stored in the geometry, based on the new format, as described in #46977 (comment). A typical example is from the standalone MtdValidation code

https://github.com/cms-sw/cmssw/blob/master/Validation/MtdValidation/test/mtdValidation_cfg.py#L78

that reruns the tracking rechit construction, at this point failing while accessing detids in the cluster collection and checking them against the MTDGeometry in

https://github.com/cms-sw/cmssw/blob/master/RecoLocalFastTime/FTLRecProducers/plugins/MTDTrackingRecHitProducer.cc#L91

without making any explicit creation of specialised detid formats.

I am not sure any issue might be seen in the production of RelVal samples, as it seem not to create problems in IBs. But simple analysis examples like that above clearly are affected, and needs some protection. To what extent that may be acceptable, or what possible alternative solution could be envisaged, should be better agreed before producing potentially problematic builds.

[cmsbuild]

cms-bot internal usage

[cmsbuild]

A new Issue was created by @fabiocos.

@Dr15Jones, @antoniovilela, @makortel, @mandrenguyen, @rappoccio, @sextonkennedy, @smuzaffar can you please review it and eventually sign/assign? Thanks.

cms-bot commands are listed here

[fabiocos]

A possible way out we are considering is to introduce a new geometry scenario for BTL, v4, that is in fact a replica of v3, but for some minor naming variation needed to distinguish the two. The new numbering scheme (new detailed constructor) should be associated to BTL v4 scenario, while the old one remains associated to BTL v3, and the BTLDetId data format is modified in such a way that it:

• does not attempt to translate old into new
• but it provides in the methods either old or new interpretation of the bit fields depending on the value of the bit used to track the change in data format version, to be associated to the move from scenario v3 to scenario v4 (whose actual geometry layout is unchanged in practice).

We are testing this approach, to reintroduce later the update without breaking the backward compatibility in some cases.

[makortel]

assign upgrade, geometry

[cmsbuild]

New categories assigned: upgrade,geometry

@bsunanda,@civanch,@Dr15Jones,@kpedro88,@makortel,@mdhildreth,@Moanwar,@srimanob,@subirsarkar you have been requested to review this Pull request/Issue and eventually sign? Thanks