Project

General

Profile

Support #14889

Source module documentation

Added by Robert Sulej almost 3 years ago. Updated almost 3 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
Documentation
Target version:
-
Start date:
12/23/2016
Due date:
% Done:

0%

Estimated time:
Scope:
Internal
Experiment:
-
SSI Package:
Duration:

Description

Dear art Developers,

Please, consider extending the documentation of source modules. I saw it already has a placeholder in the art workbook, however this section is empty.

Many generator modules are being written as producers while at least in some cases they should be source modules (which we learned in ProtoDUNE in the recent weeks). I have impression that it may be unclear to art users when EmptyEvent should be used and when it is not enough, and people go for EmptyEvent + producer module just because it is extremely easier to write.

A base class a'la EDProducer/EDAnalyzer but for a source module could be an ideal solution, however surely I am not aware how much effort the implementation would need.

All the best wishes for holiday and happy New Year,
Robert

History

#1 Updated by Kyle Knoepfel almost 3 years ago

  • Status changed from New to Feedback

Have you seen the input Source documentation here? There is a direct link to this page from the main art wiki page. Please let us know if that documentation is insufficient.

Regarding your proposal for a base class that would provide a similar functionality, the existing base class is art::InputSource, from which the class template art::Source inherits. The reason we provide the Source class template is that the interface and behavior of things inheriting from InputSource is much more complicated than the interface/behavior for (e.g.) art::EDProducer. The InputSource is more complicated than the other module base classes because it drives art.

#2 Updated by Robert Sulej almost 3 years ago

Hi Kyle,

Thank you for the link! Yes it is helpful. Somehow this material did not appear in our discussions. From the first look I get the idea and can google function names to see some actual implementations (NOvA and LArIAT, which looks like based on NOvA):
http://nusoft.fnal.gov/nova/novasoft/doxygen/html/NOvARawInputDriver_8cxx_source.html
http://nusoft.fnal.gov/lariat/doxygen/html/LArRawInputDriver_8cxx_source.html

We did not start coding yet, but I think the above links will make it easier, since there is all code filling the event.

May I have one more question? The implementation of readFile in the detail class should create art::FileBlock - is this class only for art bookkeeping or there is some more functionality for source modules? The two implementations I've found seem to do all the file parsing on their own, using only their class members to keep the access and read the input file.

Thank you again for your reply (maybe the material from wiki plus a most trivial but working code example can make it to the art workbook?).
Robert

#3 Updated by Kyle Knoepfel almost 3 years ago

The art::FileBlock object can be passed to various state-transition callbacks, exposing input-file information to users. For your case, we recommend you use the following art::FileBlock c'tor:

 art::FileBlock(art::FileFormatVersion const& version, std::string const& filename);

It is best if those arguments to the c'tor can be as meaningful as possible for your use cases.

We will add this to the to-do list for updating the art workbook.

#4 Updated by Kyle Knoepfel almost 3 years ago

  • Tracker changed from Feature to Support
  • Status changed from Feedback to Closed


Also available in: Atom PDF