You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Once CAFMaker is split in 2 (#219), it will be reasonable to create "CAF precursor" files (better name/metaphor required) which are art files containing nothing but StandardRecord objects. These are logically equivalent to CAFs, but stored in art format. One would simply run the "StandardRecordMaker" but not "CAFMaker" step, and use an outputCommands to drop essentially everything but the StandardRecords.
The motivation to do this is to allow re-creating the CAFs, particularly with new systematic weights. What we are looking for here, then, is a fcl that does the above, and additionally allows whatever genie-level objects are necessary for computation of the genie weights to survice the outputCommands. As I write this, I realize we will also need some mechanism to understand which genie objects are associated to which reconstructed slice. Perhaps this information is already fully-retrievable from the StandardRecord structure. Perhaps we will need to add something.
The text was updated successfully, but these errors were encountered:
Once CAFMaker is split in 2 (#219), it will be reasonable to create "CAF precursor" files (better name/metaphor required) which are art files containing nothing but StandardRecord objects. These are logically equivalent to CAFs, but stored in art format. One would simply run the "StandardRecordMaker" but not "CAFMaker" step, and use an
outputCommands
to drop essentially everything but the StandardRecords.The motivation to do this is to allow re-creating the CAFs, particularly with new systematic weights. What we are looking for here, then, is a fcl that does the above, and additionally allows whatever genie-level objects are necessary for computation of the genie weights to survice the outputCommands. As I write this, I realize we will also need some mechanism to understand which genie objects are associated to which reconstructed slice. Perhaps this information is already fully-retrievable from the StandardRecord structure. Perhaps we will need to add something.
The text was updated successfully, but these errors were encountered: