There are a set of guidelines to follow for developing configurations and configuration-aware C++ code, resulting in:

  1. better maintainability
  2. easier-to-understand configurations
  3. less time debugging; more time on physics

It is recommended that everyone go through  the following two presentations:

  • Kyle Knoepfel – Configuration best practices, helpers and FHiCL-file validation – Video of presentation or Slides of presentation
    • This presentation covers setting up a FHiCL file including how to set up a PROLOG and the #include facility and the rules about using it. The directory of a file to be included must be present on the FHICL_FILE_PATH environment variable. Don’t abuse #include. Only #include files that contain only prologs. A common frustration is how to know what parameters to specify for a given module. While looking at the source code is one solution, it would be better to devise a system that would document itself. Kyle demonstrated ‘art –help’ and ‘art –print-available-modules’ and where users put in the allowed configuration. Trying to ensure easy-to-maintain code that is simple to understand allowing more time to be spent on physics.
  • Robert Kutschke – A Case Study in Using FHiCL to ensure single points of maintenance – Slides of presentation
    • When designing its use of FHiCL, Mu2e set two goals: parameters should have a single point of maintenance and FHiCL that can be run interactively should be runnable on the grid without editing.  Rob’s talk showed several FHiCL fragments from actual Mu2e MC production FHiCL files.  One technique is to define base configuration fragments and apply deltas to that base; this naturally leads to deep configuration hierarchies.  The trick to making an interactive FHiCL file grid-ready is to design the grid scripts and the interactive FHiCL files together; the grid scripts do their job by applying prefixes and postfixes to the interactive FHiCL file – we have never needed to “reach in and edit” a FHiCL file as part of a grid job.