Feature #9255

Ordering of config_dumper output

Added by Christopher Backhouse over 5 years ago. Updated over 3 years ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:
Spent time:
SSI Package:


What order is config_dumper output in? It looks random.

Something stable, perhaps the order the modules ran in, would make it much easier to compare two files to tell if they were processed in the same way.


#1 Updated by Christopher Backhouse over 5 years ago

For each individual block, the order it was typed in the fcl file, rather than apparently at random, would also be much easier to read.

#2 Updated by Marc Paterno over 5 years ago

  • Status changed from New to Feedback

The ordering of the outputs you're looking at is reproducible, but in some cases it is not easy to predict.

  1. The order of items within a ParameterSet is sorted by key. The declaration order of contents in the FHiCL "table" that yields a ParameterSet is intentionally irrelevant to the value of the ParameterSet.
  2. The order of the items printed by config_dumper is the order of the ParameterSetID objects calculated for those ParameterSet instances. The id reflects the contents of the ParameterSet, so changing any of the contents can change the sort order, when compared with the original (before the change) contents. Two configurations that are the actually the same should yield the same output, but different configurations are not trivial to compare to find the source of the differences.

It is not really feasible to change the basic features of the parameter set system, which are critical to the behavior of the systems using FHiCL. However, if we understood the underlying goal you are pursuing, we may be able to devise a solution to support it. Can you provide a use-case describing the end you are looking to achieve?

#3 Updated by Christopher Backhouse over 5 years ago

The use case was exactly that of comparing two files that had been processed similarly but slightly differently, looking for the critical difference. The trouble is that, according to your description of the algorithm, modules with changes to their configurations can get completely resorted, making it difficult to see what actually changed. I was using a visual diff tool (meld, kdiff, emacs-diff etc).

While ParameterSets maybe can't change, the collection of parameter sets that makes up the full configuration presumably is under your control. Alphabetical order would be a little better than this ID ordering, but using some kind of chronological sequence number would be better still. Ideally you'd get as close as possible to the initial fcl file (with all the @locals expanded). For files that have been processed multiple times you'd be trying to get close to the concatenation of all the fcls.

#4 Updated by Marc Paterno over 5 years ago

Thanks for the clarification. I think we now understand the request well enough for the art team to develop a proposal for a solution. We will discuss it and produce a time estimate at our next meeting (Monday).

#5 Updated by Kyle Knoepfel over 3 years ago

  • Category set to Application
  • Status changed from Feedback to Resolved
  • Assignee set to Kyle Knoepfel
  • Target version set to 2.08.00
  • % Done changed from 0 to 100
  • SSI Package art added

We have implemented this to print out the ParameterSet instances in alphabetical order according to table name, which was the most straightforward path to improvement. If, after testing this, a separate ordering is desired, please open another issue.

Please note, however, that the FHiCL-parsing implementation does not retain the order of tables in which they were declared in a configuration file.

Implemented with commit art:7d54922.

#6 Updated by Kyle Knoepfel over 3 years ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF