Project

General

Profile

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 over 5 years ago. Updated about 5 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
-
Target version:
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

Feature #8868: Develop key map for automatic registration of FHiCL typesClosedKyle Knoepfel

Feature #8869: Produce string-rendered version of allowed ParameterSetClosedKyle Knoepfel

Feature #8870: Create parameter checking algorithm against FHiCL referenceClosedKyle Knoepfel

Feature #8872: Set and retrieve values from FHiCL using new C++ typesClosedKyle Knoepfel


Related issues

Related to fhicl-cpp - Feature #9078: ParameterSet validation enhancementsClosed06/09/2015

Blocked by art - Feature #8772: Facility to retrieve individual sequence elements in FHiCLClosed05/13/2015

Blocks art - Feature #9099: Implement FHiCL validation in artClosed06/10/201508/01/2015

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

#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 about 5 years ago

  • Target version changed from 1.18.00 to 1.16.00

#11 Updated by Christopher Green about 5 years ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF