Feature #8773: Create new types in FHiCL that automatically register allowed parameters. - art - Fermilab Redmine

Feature #8773

Feature #7538: art service/module command-line helpers

Feature #8770: Implement parameter set validation - task 3a of issue #7538

Create new types in FHiCL that automatically register allowed parameters.

Added by Kyle Knoepfel about 5 years ago. Updated almost 5 years ago.

Status:

Closed

Priority:

Normal

Assignee:

Kyle Knoepfel

Category:

Target version:

1.16.00

Start date:

05/19/2015

Due date:

08/01/2015

% Done:

100%

Estimated time:

(Total: 98.00 h)

Spent time:

20.00 h (Total: 146.00 h)

Scope:

Internal

Experiment:

SSI Package:

fhicl-cpp

Duration: 75

Description

A required feature of FHiCL configuration validation is the ability for the user to register parameters that are allowed for a given FHiCL configuration. A possible interface that has been significantly explored would allow the expected FHiCL configuration (e.g.):

pset: {
   flag : false
   list : [2,4,15]
   pset2 : {
      flag : true
   }
}

to be declared as

struct PSet2 {
  Atom<bool> flag { Key("flag") };
};

struct PSet {
  Atom<bool> flag { Key("flag") };
  Sequence<int> list { Key("list") };
  Table<PSet2> pset2 { Key("pset2") };
};

where the Atom, Sequence, and Table class templates can accept comments for annotations to be provided in FHiCL printouts, and they can also support default values. In addition, Sequence needs to be able to support nested structures (e.g.):

Sequence< Sequence<int> > seqOfSequences { Key("seqs") };
Sequence< Table<PSet2> > seqOfTables { Key("seqOfTables") };

In order for this to work, one must be able to compare (and therefore access) individual elements of sequences, which is a feature requested in issue #8772.

Subtasks

Related issues

History

#1 Updated by Kyle Knoepfel about 5 years ago

Blocked by Feature #8772: Facility to retrieve individual sequence elements in FHiCL added

#2 Updated by Kyle Knoepfel about 5 years ago

Target version set to 1.18.00

#3 Updated by Rob Kutschke about 5 years ago

I would like to add a use case for discussion - a complete solution can wait until a later date. This issue has to do with groups of definitions that have properties like, if A is true then B must not be present but if A is false then B must be present.

An example of this is the configuration of a 3D shape:

myVolume : {
shape : sphere
centerPosition : [ 0., 0., 0. ] // mm in Mu2e Coordinate system
radius : 10. // mm
}

myVolume : {
shape : box
centerPosition : [ 0., 0., 0. ] // mm in Mu2e Coordinate system
halfLengths : [ 5., 5., 10. ] // mm
}

In this case either radius or halfLengths must be present, depending on the value of shape. There are no circumstances in which both or neither are allowed.

In this particular cases we can solve the problem by reformulating many things:

myVolume : {
shape : sphere
centerPosition : [ 0., 0., 0. ] // mm in Mu2e Coordinate system
parameters : [ 10. ] // radius, in mm
}

myVolume : {
shape : box
centerPosition : [ 0., 0., 0. ] // mm in Mu2e Coordinate system
parameters : [ 5., 5., 10. ] // half lengths in mm
}

I am comfortable with delegating this sort of checking to the end user, at least in the initial release and perhaps even longer term. But I need to know how to write the validation struct for the first version of this example - do I have to make both radius and halfLengths parameters with default values ? I don't really like that but I can live with it for a while.

#4 Updated by Kyle Knoepfel about 5 years ago

Thank you for your input, Rob. Such a use case is indeed something that needs to be supported at some point. I am considering a syntax that would allow one to specify conditional references, but such functionality will not necessarily be slated for the Alpha Centauri release due to other issues that need addressing.

A question: what should the desired behavior be if a user were to specify (e.g.)

myVolume.shape : trapezoid

where trapezoid was not declared to be an option? The proposed ParameterSet validation suite currently supports checking the existence of FHiCL names and not values. However, for this use case, value-checking must be interleaved with the FHiCL-name validation so that the appropriate reference keys can be compared conditionally.

Presumably, the user will want the code to throw if an unsupported value is specified. However, doing so requires adding Options() and/or Range() arguments to the fhiclcpp-type constructors. Adding such optional c'tor arguments would likely be a desirable feature, but it is not clear that it could be implemented by Aug. 1.

This may be an example where specifying default values for radius and halfLengths is required until the other features can be implemented. I'd like to talk with you, however, about a reasonable way forward given the time constraints.