art series 2.08¶
Previous series release notes
Next series release notes
New features¶
In addition to other features and improvements, this version of art
has the features described below.
Processing input files with mixed process histories¶
With 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 art
version.
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.
Resolves issues: #5182, #11760, #16602.
art::Ptr
s to SubRun
, Run
, and Results
products¶
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), SubRun
, Run
, and Results
container-like products. All art::Ptr
creation is done using the same interface for the Event
, SubRun
, Run
, and 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 SubRun
product.
Resolves issues: #4432, #4433.
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 Event
, SubRun
, Run
, or 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:
cout
orstdout
(case-insensitive)cerr
orstderr
(case-insensitive)- Anything else is interpreted to be a file name (
/dev/null
falls in this category)
The information is printed out at the end of the job.
See consumes documentation here.
Resolves issues: #15378, #15379.
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.
In-memory stringstream messagefacility
destination¶
Users can now insert messages into a messagefacility
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.
Improved 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.):
HelloWordsmith_module.so
HelloWorld_module.so
HelloWormhole_module.so
HelloWorld_source.so
HelloWorld_mfPlugin.so
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 HelloWorld_source.so
.
art::PtrMaker
utility¶
The 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.
Breaking changes¶
Please consult the list of breaking changes to determine if/how your code should be modified.
art releases¶
art suite 2.08.03 (integration)
art suite 2.08.02 (integration)