Experiment-independent channel filter in geometry service
#1 Updated by Tracy Usher almost 6 years ago
The primary issue here is that for MicroBooNE there are more readout channels than wires in the TPC. The data acquisition system is reading those channels and inserting them into the data stream with channel ID's which are above the "valid" channel maximum. The current channel conversion methods in the geometry service check the channel value and if greater than the expected number (for instrumented wires) it throws an exception. Currently the reconstruction software is not catching this exception so it is passed up to the art level before being handled.
The obvious, but time consuming, solution is to insert try-catch blocks in all the code calling a channel conversion method in the geometry service with the catch clause simply continuing the loop over channels as the handling of illegal channels will have to be done in the calling routine.
... I think...
#2 Updated by Gianluca Petrillo almost 6 years ago
- MicroBooNE has channels that are not associated with wires
- these channels are not relevant in the reconstruction
- some code is channel-based and tries to get wire numbers based on channel ID
Why is this being reported only now? is it triggered by some channel mapping change, by some user code change, or was it always there with everybody living with that?
I don't think I have ever recognized any failure as coming from this issue.
From the answers, a proper solution can be devised.
#3 Updated by Gianluca Petrillo almost 6 years ago
I summarize an intense e-mail exchange with Tracy Usher.
MicroBooNE has readout channels that produce actual information in the form of
raw::RawDigit, that are not connected to a physical wire.
Querying those channels with
Geometry service gives trouble.
I think we agreed that
ChannelFilter (not in the geometry) should be made aware of them.
I proposed to add a flag to the
raw::RawDigit class declaring whether its channel is ethereal. While this idea was not rejected, it was pointed out that there are existing
raw::RawDigit files already from the real detector, and the ability to correctly process them is required (without reprocessing them).
My almost-random thoughts follow.
- I believe channels are quite abused: I would expect them used only in relation to the readout simulation and raw data calibration (that is,
CalWireXxxx). Other uses should be exceptional.
- Only in those cases, one wants to loop through all channels and he/she might incur in the "wireless" channel problem.
- Other reconstruction objects holding a channel should not end up having an invalid one.
- Every time channels are indiscriminately accessed, a channel filter should be used to know whether each channel is, in Tracy's words, "bad", "sick", "whatever".
- This channel filter service does not belong to
Geometry, and I think at this point could be implemented as a
artservice/service provider pair and optionally interfaced to a database. Once the database interface is blessed, this work can start (maybe earlier than that, too).
Finally, it was agreed that a workaround for the specific problem is to perform a simple check in the place where channels are required.
Geometry service knows how many channels there are (
Geometry::NChannels()), and that figure currently includes only wired channels (documentation should be updated to make that a requirement, if this is accepted).
See also issue #1083.