Wire-Cell News

The configuration section of the WCT manual has details but for here, it's worth giving a quick review of WCT configuration. Ultimately, a WCT job is configured by providing a configuration sequence. This is simply an array of data structures. Each structure corresponds to a component instance. This is a C++ object instance of a WCT component class which inherits from one or more WCT interface base classes. At it's top level, each configuration data structure follows a simply object schema consisting of three attributes:

type

name the WCT component type (usually similar but not always identical to the corresponding C++ class name).

name

an optional instance name to differentiate multiple instances of the same type.

data

an optional and arbitrary instance configuration data structure.

In principle the configuration sequence can be provided in a variety of forms. In practice, just one form is supported: JSON, possibly compiled from Jsonnet. The user thus provides one or more files that ultimately produce a simple configuration sequence array and WCT uses that to instantiate and configure component objects.

The job finally runs by locating any configured component objects which happen to implement the interface IApplication. Any and all "apps" that are found are executed and through their own configuration (their instance configuration structure specified by the data attribute) they make use of other configured component objects.

Okay, so what, you want to configure some component but you don't know what parameters it honors. As always, the best way to know what code does is to read it. Short of that, WCT provides a special "app" component called ConfigDumper that can dispaly the default configuration which is hard-coded into the components' C++ implementation.

You can run this app without any configuration:

$ wire-cell -p WireCellApps -a ConfigDumper
[{"data":{"components":[],"filename":"/dev/stdout"},"name":"","type":"ConfigDumper"},{"data":{"filename":"/dev/stdout","nodes":[]},"name":"","type":"NodeDumper"}]

Or, for something a bit more pretty:

$ wire-cell -p WireCellApps -a ConfigDumper | json_pp 
[
   {
      "type" : "ConfigDumper",
      "name" : "",
      "data" : {
         "components" : [],
         "filename" : "/dev/stdout"
      }
   },
   {
      "type" : "NodeDumper",
      "name" : "",
      "data" : {
         "filename" : "/dev/stdout",
         "nodes" : []
      }
   }
]

The output is printed to stdout and the stderr logging is omitted here for clarity. You may replace the json_pp with your favorite JSON pretty-printer.

By default ConfigDumper dumps the configuration about all configurable components provided by the WCT plugins listed on the command line. At a minimum the WireCellApps plugin must be listed as it is required for WCT to find ConfigDumper itself. You can add additional plugins and their components will also be dumped. Here, WireCellGen is added:

$ wire-cell -p WireCellGen -p WireCellApps -a ConfigDumper | json_pp 
[
...
   {
      "name" : "",
      "type" : "PlaneImpactResponse",
      "data" : {
         "plane" : 0,
         "tick" : 500,
         "nticks" : 10000,
         "field_response" : "FieldResponse",
         "other_responses" : []
      }
   },
...
]

Only one of about three dozen instance configuration data structures is shown. It is the one for PlaneImpactResponse which was featured in a recent post.

Of course, as shown above, ConfigDumper itself takes some configuration. Namely the user may set an output file and may limit which components are dumped. This configuration can be provided in a usual configuration file but in the next example we use the process substitution feature of bash to do everything on the command line:

$ wire-cell -p WireCellSigProc -p WireCellGen -p WireCellApps \
            -a ConfigDumper \
            -c <(echo '[{type:"ConfigDumper",data:{filename:"dump.json",components:["FieldResponse","PlaneImpactResponse"]}}]')
$ cat dump.json |json_pp
[
   {
      "type" : "FieldResponse",
      "data" : {
         "filename" : ""
      },
      "name" : ""
   },
   {
      "name" : "",
      "data" : {
         "plane" : 0,
         "other_responses" : [],
         "field_response" : "FieldResponse",
         "tick" : 500,
         "nticks" : 10000
      },
      "type" : "PlaneImpactResponse"
   }
]

After running the ConfigDumper the user may wish to provide a variant configuration which is influenced by what was discovered. A few guidelines and caveats are useful here.

It's always best to read the source code to learn what configuration a component expects, and more importantly, what it does with the configuration it gets. With that said, the WCT ConfigDumper "app" provides an easy way to discover or simply remind oneself what is the default configuration of some component.