Project

General

Profile

Feature #23801

Request to extend TriggerNameServices to read names from previous jobs

Added by Giuseppe Cerati over 1 year ago. Updated 12 days ago.

Status:
Feedback
Priority:
Normal
Assignee:
Category:
Infrastructure
Target version:
Start date:
12/23/2019
Due date:
% Done:

0%

Estimated time:
4.00 h
Scope:
Internal
Experiment:
-
SSI Package:
Duration:

Description

TriggerNameServices is currently built based on the trigger results from the current job.
However, it would be good it could return the trigger names of filters run on previous jobs.
The functionality could be similar to what is currently done in EventSelector::acceptEvent(TriggerResults const& tr).

Here is a code snipped that works for me:

  art::ValidHandle<art::TriggerResults> filter = e.getValidHandle<art::TriggerResults>(art::InputTag("TriggerResults","","OverlayFiltersPostStage2"));
  std::vector<std::string> trigger_path_names;
  fhicl::ParameterSet pset;
  if (!fhicl::ParameterSetRegistry::get(filter->parameterSetID(), pset)) { throw cet::exception("PSet Not Found???"); }
  trigger_path_names = pset.get<std::vector<std::string> >("trigger_paths", {});
  if (trigger_path_names.size()!=filter->size()) { throw cet::exception("Size mismatch???"); }
  for (size_t itp=0;itp<filter->size();itp++) {
    std::cout << "filter name=" << trigger_path_names.at(itp) << " decision=" << filter->at(itp).accept()  << std::endl;
  }

(Thanks Kyle for the help!)

History

#1 Updated by Kyle Knoepfel over 1 year ago

  • Scope set to Internal
  • Status changed from New to Under Discussion
  • Project changed from LArSoft to art

#2 Updated by Kyle Knoepfel over 1 year ago

The art developers will discuss this feature. In particular, any issues related to multi-threading need to be understood before this feature is implemented.

#3 Updated by Kyle Knoepfel 11 months ago

  • Target version set to 3.06.00

#4 Updated by Kyle Knoepfel 11 months ago

  • Estimated time set to 4.00 h
  • Assignee set to Kyle Knoepfel
  • Status changed from Under Discussion to Assigned
  • Category set to Infrastructure

#5 Updated by Kyle Knoepfel 10 months ago

  • Target version deleted (3.06.00)

It appears this issue will take more discussion among stakeholders before it can be implemented.

#6 Updated by Kyle Knoepfel 15 days ago

  • Target version set to 3.09.00

#7 Updated by Kyle Knoepfel 12 days ago

  • Status changed from Assigned to Feedback

Basic proposal challenges

It is quite difficult to adjust the interface to be able to provide trigger path names from previous processes without the event--i.e. there's no good way to do:

art::ServiceHandle<TriggerNamesService> triggerNames;
std::vector<std::string> path_names = triggerNames->getTrigPaths("OverlayFiltersPostStage2"); // Difficult to achieve

The reason for this is because the storage of trigger path names and the rest of the process' configuration are not closely aligned. I could come up with some way of doing this that would work now, but it would hardly be extensible if the schema needs to change.

Counter-proposal

However, once an event object is available, there is enough information to directly identify the path names for the relevant process. I have therefore added interface to the TriggerNamesService so that the code in the description of this issue can be equivalently expressed in art 3.09 as:

art::ServiceHandle<TriggerNamesService> triggerNames;

// 'results' is of type 'std::map<std::string, art::HLTPathStatus>'
auto results = triggerNames->pathResults(e, "OverlayFiltersPostStage2");

for (auto const& [path_name, path_status] : results) {
  std::cout << "filter name=" << path_name 
            << " decision=" << path_status.accept() << '\n';
}

Notice that there no longer is any explicit interaction with the art::TriggerResults object. For those who would like to use the TriggerResults object, the following interface is provided:

art::ServiceHandle<TriggerNamesService> triggerNames;
art::TriggerResults const& tr = triggerNames->triggerResults(e, "OverlayFiltersPostStage2");

Because almost all uses of path names are used with a trigger-results object, I believe this meets the need. Do you agree, or is an alternative approach required?

Also available in: Atom PDF