Project

General

Profile

Path and Module Management

Paths

  • All non-recognized parameters in the Physics parameter set shall be interpreted as paths. Something that cannot be a path (e.g. a non-sequence) shall cause an exception to be thrown.
  • A path shall be interpreted as a trigger path or an end path depending on its contents. A path referring to both observers (outputs and analyzers) and modifiers (producers and filters) shall cause an exception to be thrown.
  • The content and validity of paths shall be determined without the need for module construction.
  • trigger_paths will be ignored if specified.
  • end_paths will be ignored if specified.
  • The order of specification of paths shall be irrelevant.
  • The order of specification of modules in an end path shall be irrelevant.
  • Specification of multiple end paths shall be interpreted as if one end path were specified whose contents were the union of each component end path.

Modules.

  • For version 1.0, modules in trigger paths shall be constructed for each schedule.
  • Future versions should allow for fully re-entrant modules, and modules requiring serial access to a named resource (e.g. ROOT).
  • Products shall be registered once per module label: infrastructure shall ensure this.