MCH: fix for the DE600 electronics mapping

[aferrero2707]

The readout cables for the TB2 and TN2 groups are swapped for DE600, since the beginning of Run3.
The mapping is corrected to reflect this swap.

For details see https://its.cern.ch/jira/browse/MCH-11

[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

[aferrero2707]

@pillot @lmassacr this fix is only needed for the data taking starting from this year, the old data are encoded with the wrong mapping and this PR will not fix the existing CTFs.

I possible mitigation for the existing data will eventually come in a separate PR.

[lmassacr]

Hi Andrea,
Thanks! For my personal understanding, as I understood that the mapping is also encoded in the ctf, will this fix apply at the level of the digit filtering only, or will this fix also correct the mapping in the ctf that we will produce with the new data taking in 2025?

[lmassacr]

@pillot @lmassacr this fix is only needed for the data taking starting from this year, the old data are encoded with the wrong mapping and this PR will not fix the existing CTFs.

I possible mitigation for the existing data will eventually come in a separate PR.

it seems our two messages just crossed each other, thanks for the clarification :)

[pillot]

Thanks @aferrero2707! If I understand well, you swapped the solarId associated to 2 DS.

Aren't there other modifications needed for consistency in other mappings, for the CCDB-Proxy and mchview?

I am also wondering about the consistency of the existing CCDB objects like BadChannels? Here the DS are identified with SolarId & eLinkId encoded into a DsChannelId. So with this change at the next reconstruction they will be connected to a different DS in the segmentation?

I am getting lost between all the mappings and Ids...

[aferrero2707]

@pillot those are very good points!

First of all, the swap is not for 2 DS boards, but for two DS groups (5 boards on TB2, 3 boards on TN2).

Regarding MCHView: the current version clearly reports the wrong mapping (see screenshots attached to https://its.cern.ch/jira/browse/MCH-11). For example, the DsID=8355 is reported as attached to SolarId 218, while it should be 219.
Does MCHView rely on the O2 mapping? Or it has its own version?

For the CCDB objects like the BadChannels, if they are identified with SolarId+eLinkId then I think they are always correct - they simply reflect the status of the electronics as seen by the CRU. However, with the current mapping a bad channel associated for example to [SolarId=218, eLinkId=10] (the first DS board of the group corresponding to TB2 in the current mapping, and TN2 in the correct one) is translated into the wrong DE-DS pair, and so applied to the wrong cathode and pads. The new mapping should then fix this as well.

Could you point me to an example in the code where the BadChannels object is used? I can then check my hypothesis...

[pillot]

I cannot access the JIRA. It says "It may have been deleted or you don't have permission to view it.".

CCDB-Proxy and mchview have their own version of mapping in json format. They are generated from O2 with o2-mch-global-mapper (GlobalMapping/src/global-mapper.cxx). So I think they need to be regenerated.

The BadChannels (and the rejectList that also use DsChannelId) are both used to produce the status map (Status/src/StatusMapCreatorSpec.cxx), which is then used in the digit filtering. If the content of these objects is correct, then I would agree with you that the new mapping will fix the connection to the right DSId. But I imagine the correctness of the content depends on how these objects are produced. They can be produced from all sorts of inputs with Conditions/src/bad-channels-ccdb.cxx for instance. If the input was the solarId, eLinkId, then they are correct. If it was e.g. the DS index converted with the mapping, then they are not.

I suppose that the BadChannels currently in the CCDB are produced from the calibration workflow, and in this case I imagine the input is the solarId, eLinkId so the content is correct ?

I think the rejectList in the CCDB is still the default (empty) one in which case it does not matter. However, the rejectLists produced manually by the UD group might be affected if they used DS indices, although the effect is probably negligible in the end.

[aferrero2707]

@pillot thinking a bit more about it, I am now rather convinced that in this specific case the correctness of the StatusMap is irrelevant, simply because the digits from the involved boards are useless for the tracking. Due to the swap between the two cathodes, the hit information is significantly wrong for all the corresponding channels, and no good clusters can be formed. This can be seen from the pseudo-efficiency plot below, where one can see that the efficiency is ~zero for all the affected DS boards.

Hence, the StatusMap does not provide any useful information. Since the wrong mapping mixes pads inside this bad region, the wrong StatusMap information is also contained in the same bad region, with no practical effects.
Am I right?

By the way, we should permanently mark all this region as bad for all the runs collected until now. Can this be done with a single object in the CCDB?

Thanks!

[pillot]

Well I imagine it does not matter if you kill the right or the wrong digit if neither or them are used in the end, which might be the case for this particular problem in the mapping, although I am not completely sure.

Yes, these DS can be excluded in the rejectList. But one has to make sure we exclude the right ones, and their identification depends on the mapping. ;-)