Mixing ECON-D type index & dense index (?); Capture block indexing

[IzaakWN]

Is it possible we are using the wrong ECON-D index here? I think that in some places where we use "module type index" modIdx, it should be "readout sequence / dense index" imod?

https://github.com/CMS-HGCAL/cmssw/blob/fb288fa9aa202fdfd43f6681dbcd98758182df90/Geometry/HGCalMapping/plugins/alpaka/HGCalDenseIndexInfoESProducer.cc#L76-L111

I noticed that modIdx is always 0 for the TB2024v1 module locators, because all modules are of the same type (with same first half of their respective typecodes): https://github.com/CMS-HGCAL/cmssw/blob/fb288fa9aa202fdfd43f6681dbcd98758182df90/CondFormats/HGCalObjects/interface/HGCalMappingModuleIndexer.h#L68

As a consequence, i1 and i2 are always constant in nano, here: https://gitlab.cern.ch/hgcal-dpg/hgcal-comm/-/blob/master/NanoTools/plugins/HGCalNanoTableProducer.cc?ref_type=heads#L108-111

[IzaakWN]

Somewhat related: Since there are now 3 ECON-D's per capture block, do we need to update the capture block indices in the module locator files here? https://gitlab.cern.ch/hgcal-dpg/hgcal-comm/-/blob/master/Configuration/data/ModuleMaps/modulelocator_TB2024v1.txt?ref_type=heads However, it seems like we were able to run without any issues? If so, is this information redundant, or can it be retrieved from the data format in a "self-discovery" way?

[pfs]

ah right so I was thinking about this and indeed there is an ambiguity from the point of view of dense indexing doing econdIdx = 0,1,2,3,4,5 for capture block =0,0,0,0,0,0 is the same as econdIdx = 01,2,0,1,2 for capture block =0,0,0,1,1,1 we should however put the proper index for book keeping let me test and commit to hgcal-comm. In parallel this one can be merged safely

[pfs]

actually testing for the change in the module locator this uncovered an interesting feature in the HGCalMappingModuleIndexer.h: it needs a reset of the final index when a capture block is not full I'm fixing it, let's keep this open

[pfs]

I think we can close right?