Project

General

Profile

Feature #25296

Expanded logic for SelectEvents

Added by David Brown 3 months ago. Updated 2 months ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
Infrastructure
Target version:
Start date:
12/09/2020
Due date:
% Done:

100%

Estimated time:
8.00 h
Spent time:
Scope:
Internal
Experiment:
Mu2e
SSI Package:
art
Duration:

Description

I would like to be able to configure the SelectEvents function with more complicated logical expressions on the filter paths. My use case requires selecting events which pass one filter but not any of a set of others: ie SelectEvents( A && !(B || C || ...|| Z)).
A way of implementing this in code (in a single process) would also work.

History

#1 Updated by Kyle Knoepfel 3 months ago

  • Status changed from New to Under Discussion
  • Subject changed from Expaneded logic for SelectEvents to Expanded logic for SelectEvents

#2 Updated by Kyle Knoepfel 3 months ago

  • Status changed from Under Discussion to Feedback

Although we do not think we can support arbitrary Boolean expressions at this time, we propose the addition of a RejectEvents parameter. For example, the following configuration:

outputs.out: {
  module_type: RootOutput
  SelectEvents: [s1, s2, ..., sN]
  RejectEvents: [r1, r2, ..., rM]
}

where s* and r* are trigger-path specifications, will have the same runtime semantics as:

if ((s1 || s2 || ... || sN) and not 
    (r1 || r2 || ... || rM)) {
  select_event(e);
}

Your use case would be configured as:

outputs.out: {
  module_type: RootOutput
  SelectEvents: [A]
  RejectEvents: [B, C, ..., Z]
}

Is this an acceptable solution for your needs?

#3 Updated by Kyle Knoepfel 3 months ago

  • Status changed from Feedback to Accepted

#4 Updated by Kyle Knoepfel 3 months ago

  • Estimated time set to 8.00 h
  • Target version set to 3.07.00
  • Assignee set to Kyle Knoepfel
  • Status changed from Accepted to Assigned
  • Category set to Infrastructure
  • SSI Package art added
  • SSI Package deleted (-)

#5 Updated by Kyle Knoepfel 2 months ago

  • % Done changed from 0 to 100
  • Status changed from Assigned to Resolved

Implemented with commits:

For analyzers or output modules that enable configuration description, one will see the following (e.g.):

knoepfel@scisoftbuild01 build_slf7.x86_64 $ art --print-description EventCounter                                                                                                                                                              

====================================================================================================

    module_type: EventCounter (or "art/test/Framework/Core/EventCounter")

        provider: art
        type    : analyzer
        source  : /home/knoepfel/scratch/art-devel/srcs/art/art/test/Framework/Core/EventCounter_module.cc
        library : /scratch/knoepfel/art-devel/e20_debug/build_slf7.x86_64/art/slf7.x86_64.e20.debug/lib/libart_test_Framework_Core_EventCounter_module.so

    Allowed configuration
    ---------------------

        ## Any parameters prefaced with '#' are optional.

        <module_label>: {

           module_type: EventCounter

           ## Events are selected based on the trigger-path entries provided in
           ## the 'SelectEvents' and 'RejectEvents' parameters.  For example, a
           ## configuration of
           ## 
           ##   SelectEvents: [A, B]
           ##   RejectEvents: [C, D]
           ## 
           ## would accept events that satisfy trigger-path criteria A or B and
           ## fail criteria C or D.  In other words, the event is accepted if the
           ## following Boolean expression evaluates to true:
           ## 
           ##   (A || B) and not (C || D)
           ## 
           ## For the majority of cases, a trigger-path criterion may be:
           ## 
           ##   1. A trigger-path name in the current process (e.g. tp)
           ##   2. A negated trigger-path name in the current process (e.g. "!tp")
           ##   3. A trigger-path name from a previous process (e.g. "previousProcess:tp")
           ## 
           ## More complicated expressions are allowed--see
           ##   https://cdcvs.fnal.gov/redmine/projects/art/wiki/Filtering_events
           ## 
           ## The default 'SelectEvents' and `RejectEvents` lists are empty,
           ## which is equivalent to selecting all events.

           SelectEvents: [
           ]

           RejectEvents: [
           ]

           ## The 'expected' parameter specifies the number of events that are
           ## expected to be processed, based on the corresponding 'SelectEvents'
           ## and 'RejectEvents' parameters.

           expected: <unsigned int>
        }

====================================================================================================

Also available in: Atom PDF