search

art-framework-suite / art

The implementation of the art physics event processing framework
Other
2 stars 7 forks source link

expand Results concept #79

Open knoepfel opened 3 years ago

knoepfel commented 3 years ago

This issue has been migrated from https://cdcvs.fnal.gov/redmine/issues/18628 (FNAL account required) Originally created by @rlcee on 2017-12-28 00:02:23

Please consider if it would be possible and logical to expand the concept of Results products. I am thinking of it as a container for products that are relevant to the file (or whole dataset) in the same way as products in a Run record are relevant to the run.
I particular, add a "art::Results& getResults()" method to the Event, SubRun and Run, and a readResults(art::Results) method to EDProducer, etc. as a call-back when Results change. The use case I'm thinking about is the following. In the first stage of a simulation job we create a geant geometry with a number for each volume. We then record, in the event products, for example, the volume number where a particle started or stopped. To convert this number back to a volume name in later jobs, we write a conversion table product to the subrun record. But when we concatenate, we end up with too many of these records, all duplicates. The right conceptual procedure is to write one product per file (can only have one geant geometry per job), and allow all modules to access it while reading in later jobs. A ResultsProducer would purge duplicates during concatenation in this application, but you could keep all records with a range of validity or similar by default. I think there are other use cases too.

knoepfel commented 3 years ago

Comment by @knoepfel on 2018-01-08 18:21:37

Further discussion is necessary on this. We will contact you for more feedback.

knoepfel commented 3 years ago

Comment by @rlcee on 2018-01-25 15:30:31

I'm still interested in this. Please name a time to meet, at your convenience. Thanks

knoepfel commented 3 years ago

Comment by @cjbackhouse on 2021-10-19 19:05:17

A very similar use case came up in DUNE discussion the other day. This was also about storing the geometry information, but our motivation to want to go to Results level was to ensure the information could be loaded early enough, before analyzers start trying to query the geometry. The asymmetry of Results with the usual Run/Subrun/Event storage made this seem more challenging than it needed to be though.