art series 2.08¶
In addition to other features and improvements, this version of
art has the features described below.
Processing input files with mixed process histories¶
art 2.08.00 it is permitted to process input files that were produced under different processing conditions and configurations. This feature is supported when using
art 2.08.00 to read an
art/ROOT file produced by any
Although reading input files with different processing histories is supported, the provenance associated with such processing can be difficult to understand. Because of that, users should try to maintain, to the extent possible, simple workflows that do not require such a processing model.
To print out the process history of a given file, use the
'file_info_dumper --process-history <art/ROOT file>' utility.
Due to implementation changes necessary to support processing of differently-produced input files, it is now possible with
art 2.08.00 to create
art::Ptr<T> objects to elements in
Event (as before),
Results container-like products. All
art::Ptr creation is done using the same interface for the
Results data-containment levels.
Note that it is not yet supported to create an
art::Ptr that is (part of) a product in one containment level, yet referring to a product in a different containment level--e.g. an
art::Ptr created in at the
Event level cannot refer to a
Declaring products to be consumed¶
In preparation for multi-threading, the "consumes" interface is now supported and encouraged for use. This interface allows a user to specify in a module constructor the products that will be retrieved during any calls to the
Results processing overrides.
There are six different interface calls that may be invoked. Some of the functions return tokens that facilitate product retrieval:
// Unconditional retrievals consumes<MyProd>(input_tag); // => ProductToken<MyProd> consumesMany<MyProd>(); // => void consumesView<MyElem>(input_tag); // => ViewToken<MyElem> // Conditional retrievals (e.g. within 'if' blocks) mayConsume<MyProd>(input_tag); // => ProductToken<MyProd> mayConsumeMany<MyProd>(); // => void mayConsumeView<MyElem>(input_tag); // => ViewToken<MyElem>
The tokens can be provided to the product retrieval interface--e.g.
event.getValidHandle(token)--for product lookup.
In addition, a facility exists to notify users which consumes calls should be called for a given module. The facility is enabled if users specify:
art ... [-M|--mt-diagnostics <mf destination>]at the command line. The allowed values for the destination are:
- Anything else is interpreted to be a file name (
/dev/nullfalls in this category)
The information is printed out at the end of the job.
See consumes documentation here.
messagefacility configuration validation and description¶
Configuration validation and description have been implemented for the
messagefacility. For the allowed configuration, type:
art --print-description message
For a print-out of the allowed message-logging destinations, type:
art --print-available mfPlugin # regular destinations art --print-available mfStatsPlugin # statistics destinations
For the description of a given destination, type:
art --print-description mfPlugin:<dest type>
# regular destination
art --print-description mfStatsPlugin:<dest type>
# statistics destination
N.B. Enabling configuration validation for the
messagefacility is a breaking change. Please be prepared that any mis-specified parameters contained in the
services.message table will produce run-time exceptions. The description facilities mentioned above will help you determine the correct configuration for the facility and for any given destination. Please also consult this list of breaking changes.
Resolves issue #11410.
stringstream messagefacility destination¶
Users can now insert messages into a
std::ostringstream destination and retrieve a reference to the
std::ostringstream object from within C++ code. This can be helpful in cases where looking/testing for a particular logged message is needed.
plugin description specification¶
The typical way to print the description of a given plugin is to type:
art --print-description HelloWor.*
However, in the case where there are multiple kinds of plugins that match the provided regular expression (e.g.):
descriptions for all of the matching plugins will be printed. It is now possible to refine the search so that only descriptions of a regular-expression-matched plugin with a given suffix will be printed. For example, typing:
art --print-description source:HelloWor.*
will only print the description associated with
lar::PtrMaker class template has been accepted by
art and has been renamed
art::PtrMaker. It is available at
art/Persistency/Common/PtrMaker.h. Please see here for documentation.
Please consult the list of breaking changes to determine if/how your code should be modified.