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.
100%
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 over 5 years ago
- Blocked by Feature #8772: Facility to retrieve individual sequence elements in FHiCL added
#2 Updated by Kyle Knoepfel over 5 years ago
- Target version set to 1.18.00
#3 Updated by Rob Kutschke over 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
}
vs
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
}
vs
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 over 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.
#5 Updated by Kyle Knoepfel over 5 years ago
- Related to Feature #9078: ParameterSet validation enhancements added
#6 Updated by Kyle Knoepfel over 5 years ago
- Related to Feature #9079: Conditional configuration for fhiclcpp types added
#7 Updated by Kyle Knoepfel over 5 years ago
- Related to deleted (Feature #9079: Conditional configuration for fhiclcpp types)
#8 Updated by Kyle Knoepfel over 5 years ago
- Blocks Feature #9099: Implement FHiCL validation in art added
#9 Updated by Kyle Knoepfel over 5 years ago
- Status changed from Assigned to Resolved
The features have been implemented with commit fhicl-cpp:36dcfbccdb0d127855fc25838fef209dd042103f.
#10 Updated by Kyle Knoepfel over 5 years ago
- Target version changed from 1.18.00 to 1.16.00
#11 Updated by Christopher Green over 5 years ago
- Status changed from Resolved to Closed