Project

General

Profile

Bug #10381

Bug #1083: filter::ChannelFilter should be made into a service

Event display uses IChannelStatusService in a non-interoperable way

Added by Gianluca Petrillo over 4 years ago. Updated over 3 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
Event Display
Target version:
-
Start date:
10/02/2015
Due date:
% Done:

0%

Estimated time:
Occurs In:
Experiment:
-
Co-Assignees:
Duration:

Description

Currently, 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 ChannelFilter class.

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.

Associated revisions

Revision e567ccac (diff)
Added by Gianluca Petrillo over 4 years ago

Removed all references to deprecated ChannelFilter, except one (see issue #10381).

History

#1 Updated by Lynn Garren over 4 years ago

  • Status changed from New to Accepted

Needs discussion with MicroBooNE

#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...

#4 Updated by Tracy Usher over 4 years ago

Last comment, I promise! It is too late for MicroBooNE, there is a database that has been populated.

#5 Updated by Katherine Lato over 3 years ago

  • Status changed from Accepted to Rejected

This would cause breaking changes that aren't acceptable, and since It is too late for MicroBooNE, we don't plan on doing this.

#6 Updated by Katherine Lato over 3 years ago

  • Status changed from Rejected to Closed


Also available in: Atom PDF