Bug #1083: filter::ChannelFilter should be made into a service
Event display uses IChannelStatusService in a non-interoperable way
lariov::IChannelStatusService::Status() is basically unusable in a experiment-independent way, since there is no standard meaning associated to its values.
LArSoft event display does that nonetheless, in the fashion that was of the deprecated
The solution of the general
Status() problem goes through discussion between experiments, possibly before MicroBooNE DB starts to get filled with these values (it might be too late already).
The specific solution for the event display would be a bit-by-bit implementation side by side with a numeric threshold like it is now.
About the former, the proposal is to have as FHiCL parameter a list of quality levels to skip ("good", "bad", "noisy") and the event display will draw everything else, except the non-physical channels.
#2 Updated by Tracy Usher over 4 years ago
I am able to make the event display work within the context of MicroBooNE by adding the uboone specific service for accessing channel status to my fhicl files. I have been told a uboone solution is in the works for this. I thought I had read a workaround for other experiments on the "breaking changes" page?
There still seems to be an issue that a large number of channels appear to have the wrong status and are therefore not drawn in the event display.
#3 Updated by Tracy Usher over 4 years ago
With respect to the status codes... The original implementation of ChannelFilter had two primary access methods to query if a channel was "bad" or "noisy". When MicroBooNE took its first noise data there appeared some channels in the data stream which were "unphysical" - channels read out but which are not physically connected to sense wires (due to the design of the systems). This required an update to ChannelFilter to get rid of those which is where the category "NOTPHYSICAL" came from.
At the same time the strategy was changed from implementing a series of access methods for individual for status to allowing for a single access method to return the status of a channel which could then be queried by the user. This includes the status "GOOD". The list of status was then made hierarchal so that one could accept channels easily at or below (or above) a certain desired status. Two benefits: this prevents the need for if - else blocks if more than one status needs to be checked, one can use a fhicl parameter to set the level of acceptance. Both are very useful for the event display.
Note that the original access methods were maintained so no existing code needed to change. Not sure this was a good idea....
Whatever the final implementation, I would like to see functionality similar to the above...