Project

General

Profile

Feature #6228

Redundant SelectEvents

Added by Rob Kutschke about 6 years ago. Updated about 4 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Kyle Knoepfel
Category:
Infrastructure
Target version:
2.01.00
Start date:
05/11/2014
Due date:
% Done:

100%

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

Description

The grammar to add a SelectEvents clause to an output or analyzer module is:

module_label : {
   module_type : foo
   SelectEvents: { SelectEvents: [ trigger_path_name ] }
}

This has always seemed redundant. Is there a good reason for it? If not, I would like to discuss removing the redunancy:

module_label : {
   module_type : foo
   SelectEvents  : [ p2a ] 
}

History

#1 Updated by Christopher Green about 6 years ago

  • Category set to Infrastructure
  • Status changed from New to Feedback
  • Target version set to 1.11.00
  • Estimated time set to 4.00 h
  • Experiment Mu2e added
  • Experiment deleted (-)
  • SSI Package art added
  • SSI Package deleted ()

There is no reason why this cannot be fixed. It is a historical feature of the old python-based configuration system. We can support both in the near term, but we would propose that the old format be retired eventually, say 1.12.00.

Is this acceptable?

#2 Updated by Christopher Green almost 6 years ago

  • Status changed from Feedback to Rejected
  • Assignee set to Christopher Green

The initial analysis of this problem was erroneous: a ParameterSet is involved because its ID is stored as an attribute of the History of the product. One could conceivably store the ID of the containing module configuration ParameterSet instead, but that is a semantic change that may have broader consequences. This seems like a major step to address something as simple as redundancy.

#3 Updated by Rob Kutschke almost 6 years ago

Thanks for looking at this. Given the latest analysis I concur with the decision to reject it. Please close the issue.

#4 Updated by Kyle Knoepfel about 4 years ago

  • Tracker changed from Bug to Feature
  • Status changed from Rejected to Resolved
  • Assignee changed from Christopher Green to Kyle Knoepfel
  • Target version changed from 1.11.00 to 2.01.00
  • % Done changed from 0 to 100

After further analysis, we determined that reassigning the ParameterSetID to the containing module configuration was safe. Since the semantic of the stored value has now changed, a file-format-version adjustment is warranted. The file-format-version must change with the art:version:"Arcturus" release anyway, so it is natural to include this ParameterSetID semantic change as well.

Enabling event-selection is now achieved by the following configurations:

physics : {
   analyzers : {
      a1 : {
         module_type : MyAnalyzer
         SelectEvents: [p1,p2]
      }
   }
}

and

outputs : {
   o1 : {
      module_type : AnyOutput
      SelectEvents: [p1,p2]
   }
}

The legacy configurations (the nested "SelectEvents.SelectEvents" clause as mentioned in the description of this issue) are still supported, but they are deprecated. If the deprecated configuration is used, the following diagnostic is emitted at the top of the art-process printout:

The nested "physics.analyzers.a1.SelectEvents.SelectEvents" configuration
is deprecated.  It will be replaced with:
  physics.analyzers.a1.SelectEvents: [...]

The stored configuration on disk is, therefore, the correct specification.

Implemented with art:899fb5ca.

#5 Updated by Kyle Knoepfel about 4 years ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF