Feature #7303

Specifying one metadata parameter on the command-line makes the rest mandatory

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

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


Estimated time:
SSI Package:


I believe if any of --sam-application-family, --sam-application-version, or --sam-file-type is specified on the command-line, then the others must be too. If they are all omitted, then they are sensibly inherited from the parent file or left blank. The same if one is specified in the fcl?

If the rationale for this behaviour was discussed I never saw it.

Why shouldn't I be able set a new file-type at the command line without having to duplicate all the other information?


#1 Updated by Christopher Backhouse over 6 years ago

I found issue 4679 which is the same thing for other parameters and asserts that NOvA requested this behaviour for some reason? I'm sure there must have been a miscommunication there.

I can imagine that we said "if one of these fields is set in the output file, they all should be", but not "they should all come from one place". I can probably guess a phrasing using "specified" that is ambiguous between those two.

#2 Updated by Christopher Green over 6 years ago

  • Tracker changed from Bug to Feature
  • Category set to Metadata
  • Status changed from New to Feedback
  • SSI Package art added
  • SSI Package deleted ()

Per minutes of the 2014/11/13 stakeholder meeting:

The original requirement was that the --sam-application-family, --sam-application-version, and --sam-file metadata routed to SAM needed to be consistent, which was checked at the post FHiCL-processing stage. This can be done as late as a FHiCL file (does not have to be atthe command line), but it cannot be done in code.

General tone of original discussion was that the primary responsibility of ensuring consistency of metadata was on the user end, with the exception of some information that is naturally available w/in art — runs used, etc.

At the moment, however, it is not clear whether the behavior Chris B. is observing is enforced by art proper or the NOvA software layered on top of it.

The artists’ recommendation is that experiments need to first investigate their own code and see if the behavior they are observing is due to user code or art code. If the behavior is enforced from art and different behavior is requested, then the interested stakeholders should meet, along with the artists, and the SAM folks to discuss a resolution.

#3 Updated by Christopher Backhouse over 6 years ago

One clarification: it's not who enforces that behaviour, that's definitely art. The question is whether some of those parameters are being set by the NOvA software, which would mean that it happens too late for art to do the check at all; or whether it all comes from art somehow, and it's just an ordering question on the art side.

#4 Updated by Dominick Rocco about 6 years ago

This thread seems to have died a while ago. One problem is that the parameters must be supplied all together, or not at all, which can be frustrating for certain interactive tests or scripted uses. Another major deficiency, however, is that the input options are limited in such a way that an extra scripting layer is required. It is almost always the case that we want these parameters to be copied from the parent file to the daughter. Since the only options are command line or fcl, the wrapper script must read the parameters from the parent and add them to the command line for the daughter process. It would be much more convenient if there could be a module or plugin that could be configured to handle this more seamlessly.

#5 Updated by Kyle Knoepfel almost 6 years ago

  • Target version set to 521

#6 Updated by Kyle Knoepfel over 4 years ago

  • Status changed from Feedback to Assigned
  • Assignee set to Kyle Knoepfel

#7 Updated by Kyle Knoepfel over 3 years ago

  • Target version deleted (521)

Also available in: Atom PDF