Project

General

Profile

History

Wiki ยป

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::Ptrs 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 or stdout (case-insensitive)
  • cerr or stderr (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