Attendees:
Kurt Biery, Herb Greenlee, Chris Jones, Rob Kutschke, Adam Lyon, Paul Russo, Kanika Sachdev, Liz Sexton-Kennedy, Erica Snider
artists: Lynn Garren, Chris Green, Kyle Knoepfel, Marc Paterno
Agenda:
[Since the meeting was sparsely attended at the beginning, we started with AOB.]
Herb expressed a desire for a facility to generate SAM metadata for TFileService-produced files, which is not currently supported by art. After some discussion, it was suggested that MicroBooNE write its own service to do this. Chris also suggested that the in-memory metadata db can be written into the TFile object via the endJob virtual function.
[The rest of the meeting focused on the syntax, concepts and requirements of secondary files (related to issues 6071 and 6557).]
Rob stated the general requirements for specifying secondary files in a FHiCL file:
1) person needs to be able to write a simple one by hand
2) in general, they will be automatically generated
Additional boundary conditions imposed by SAM introduce difficulties. Since SAM cannot be queried to return a specific file with a given name:
– files must be loaded locally through SAM’s file-querying mechanism, and
– experiment must then inject the local filename into art.
Original idea is to specify some kind of priority tree in FHiCL. Chris J. wondered if such a specification was indeed necessary and mentioned that CMS currently does not require such a specification but assumes that files and the events therein are properly ordered. Marc suggested that even if a priority tree is not necessary at this time, allowing for its specification is reasonable since it might be desired later.
Chris G. proposed two possible syntaxes:
OPTION 1:
source:
{
fileNames: [ “1.root”, “10.root” ]
secondaries: [
{ a: “1.root”
b: [“2.root”, “3.root”] }
{ a: “3.root”
b: [“4.root”, “5.root”] }
{ a: “10.root”
b: [“2.root”, “6.root”] }
]
}
[[ “a” and “b” to be replaced by something more descriptive. ]]
OR
OPTION 2:
source:
{
fileNames: [ “1.root”, “10.root” ]
secondaries: {
labels: {
n1: “1.root”
n2: “2.root”
n3: “3.root”
n4: “4.root”
n5: “5.root”
n6: “6.root”
n10: ”10.root”
}
tree: {
n1: [n2,n3]
n3: [n4,n5]
n10: [n2,n6]
}
}
}
Preference for syntax 1 as it omits unnecessary labels, although possibly long filenames may need to be specified multiple times.
Regardless of chosen syntax, Rob asks for good printed representations of what FHiCL thinks the tree is, and good error messages when an invalid tree specification is inputted into the code.