Wiki » Series 300 »
Breaking changes for art series 3.00¶
- Table of contents
- Breaking changes for art series 3.00
art
¶
Changes to services¶
Removed servicesRemoved services
The following services have been removed either from disuse among experiments and projects or because the services do not comport with multi-threading concepts:
MemoryAdjuster
: optional service that could be restored if experiments find it useful.ScheduleContext
: system service internal to art. In art 3, theart::ScheduleContext
is a class that is not a service.CurrentModule
: system service that does not support multi-threading concepts.
Service callbacksService callbacks
The signatures for functions that can be registered (via the "watch
" function call) with the ActivityRegistry
have changed. See the following table to determine how you should modify your function signatures. Should you need them, the headers files are here:
art/Persistency/Provenance/ScheduleContext.h
art/Persistency/Provenance/ModuleContext.h
art/Persistency/Provenance/PathContext.h
Signal | Signature change for registered function |
sPreSourceEvent |
|
sPostSourceEvent |
|
sPreProcessEvent |
|
sPostProcessEvent |
|
sPreWriteEvent |
|
sPostWriteEvent |
|
sPreProcessPath |
|
sPostProcessPath |
|
sPreModule* |
|
sPostModule* |
|
RandomNumberGenerator::getEngineRandomNumberGenerator::getEngine
The RandomNumberGenerator
service no longer has any notion of the "current" module. Because of that, it is necessary for users to specify the appropriate schedule ID and module label values when calling getEngine
:
ServiceHandle<RNG> rng;
- rng->getEngine();
+ rng->getEngine(scheduleID, moduleLabel);
- rng->getEngine("the_other_one");
+ rng->getEngine(scheduleID, moduleLabel, "the_other_one");
If you are unsure of how to do this, please contact artists@fnal.gov. Note that in almost all circumstances, explicit calls to getEngine
are unnecessary as createEngine
, called in a user's module constructor, returns a non-const
reference to the same engine. In a future version of art, the getEngine
function will be deprecated and then removed.
For MixFilter
detail classes that must call getEngine
, retrieving the correct engine can be done using pattern:
ServiceHandle<RandomNumberGenerator> rng;
rng->getEngine(ScheduleID::first(),
pset.get<std::string>("module_label"),
"optional_engine_label");
A feature request has been made to expose the createEngine
interface to detail classes so that calling getEngine
will not be necessary (see issue #20063).
Changes to modules¶
Modules calling createEngineModules calling createEngine
Any EDProducer
and EDFilter
modules that would like to call createEngine(...)
must call the non-default base class constructors:
RNGProducer(Parameters const& p) :
+ art::EDProducer{p},
dist_{createEngine(p().seed())}
{}
Parameters
above can be replaced by the type fhicl::ParameterSet
for those modules that do not enable configuration validation.
getProductID function templategetProductID function template
In the past, the getProductID
function template has been a member of the module's base class. To better support multi-threading, this is no longer the case--it is now a function supplied by the data-level object (Event
, SubRun
, Run
, or Results
). Please make the following change:
void MyProducer::produce(art::Event& e)
{
- auto pid = getProductID<MyProduct>("myInstance");
+ auto pid = e.getProductID<MyProduct>("myInstance");
// ...
}
This means, in principle, that any getProductID
function cannot be called in the constructor of the class, since there is no object at that time for which it can be invoked. We anticipate, however, that this change is unlikely to affect many people.
Miscellaneous changes¶
Product-lookup behaviorProduct-lookup behavior
The product-lookup behavior has changed for producers and filters. Starting with art 3.00.00, only products that were (a) created by modules on the same trigger path or (b) provided by the input source will be retrievable via any of the Event::get*
facilities. This has the consequence that any workflows that relied on illegal path dependencies will no longer work in art 3. Please see the Allowed product lookups page for more information.
Program optionsProgram options
The following program options have been adjusted:
From | To |
--nomemcheck |
--no-memcheck |
--notiming |
--no-timing |
--notrace |
--no-trace |
Removal of global access to product metadataRemoval of global access to product metadata
The metadata of data products are represented as art::BranchDescription
and other C++ objects. In former art
versions, those objects have been globally accessible by various means (e.g.):
art::ProductMetaData::instance()
art::ProductMetaData::productList()
art::get_BranchDescription(...)
(beforeart
2.08.00)art::get_ProductDescription(...)
(art
2.08.00 and newer)
Such global access presents problems in a multi-threaded environment. Because of that, these utilities are removed for art
3.00.00, which also includes the removal of the ProductMetaData
class. If access to a BranchDescription
is required, it is accessible via the data-level object (e.g.):
void MyAnalyzer::analyze(art::Run const& r)
{
auto const pid = r.getProductID<MyProduct>("myInstance");
if (auto pd = r.getProductDescription(pid)) {
std::cout << "Input tag for product corresponding to ProductID " << pid << ": "
<< pd->inputTag() << '\n'
}
}
For those who have more specific needs (e.g. artdaq), please contact the artists.
SourceHelper makeEventPrincipal interfaceSourceHelper makeEventPrincipal interface
The ownership semantics of art::History
have changed from shared ownership to unique ownership:
EventPrincipal* makeEventPrincipal(EventAuxiliary const& eventAux,
- std::shared_ptr<History>&& history)
+ std::unique_ptr<History>&& history)
const;
art::PtrMaker constructorart::PtrMaker constructor
The art::PtrMaker
template constructor no longer requires a reference to the module that produces the collection whose elements are referred to be the art::Ptr
(e.g.):
- art::PtrMaker<A> maker{event, *this};
+ art::PtrMaker<A> maker{event};
Unfortunately, the comments at the top of the header file (art/Persistency/Common/PtrMaker.h
) are out of date, and they will be fixed in a subsequent release of art.
Additional dependenciesAdditional dependencies
- To avoid code bloat, some functions that have been inlined in the past are no longer inlined. This means that additional library dependencies will be required. Known changes include:
- All modules that retrieve products must now link against
art_Persistency_Provenance
. Thesimple_plugin
CMake macro does not yet link againstart_Persistency_Provenance
, so it must be explicitly included as a library dependency. - Any services that call functions from
art::Run
,art::SubRun
, orart::Event
may need to link againstart_Framework_Principal
. - Anyone using the
TriggerNamesService
must link againstart_Framework_Services_TriggerNamesServices_service
. - If you get an "invalid use of incomplete type 'class art::Event'" error, make sure that the
'art/Framework/Principal/Event.h'
header has been included in the relevant file.
- All modules that retrieve products must now link against
art-internal breaking changesart-internal breaking changes
Many changes internal to art's infrastructure occurred for this release. Although most people are not using this internal infrastructure, because some of it is publicly accessible, implementation details end up getting used anyway by art users. In this section, we document some of the internal breaking changes that have been known to affect art users who use the internal infrastructure. Such users should migrate away from using such infrastructure as soon as possible: such infrastructure is not guaranteed to persist from one release to the next. If you have questions as to what code falls in this category, please contact artists@fnal.gov.
art::EngineCreator
is no longer an accessible base class. TheEngineCreator
class has moved from theart
namespace to theart::detail
nested namespace. In addition, it is no longer an accessible base--i.e. engine-creating modules now inherit from it privately. This change was made because theEngineCreator
class exists to restrict the scope in which engine creation can occur; it is not intended to provide interface outside of art plugins. Any functions that have taken an argument as anEngineCreator
reference will need to be rewritten, possibly using a templates to represent the module type.art::MasterProductRegistry
has been removed. This is likely to only affect the artdaq project.art::ProducerBase
has been renamedart::detail::Producer
. The corresponding header file has moved from'art/Framework/Core/ProducerBase.h'
to'art/Framework/Core/detail/Producer.h'
.
canvas
¶
Many internal changes have occurred within canvas. However, only those noted below should be of relevance to users:
- The
art::BranchDescription
constructor signature has been changed so that it no longer depends onart::ModuleDescription
. - The
art::ModuleDescription
class has moved to art. - The
art::ModuleDescriptionID
andart::BranchMapper
classes have been removed. - Please note the following header file changes:
- #include "canvas/Persistency/Provenance/BranchID.h" + #include "canvas/Persistency/Provenance/Compatibility/BranchID.h" - #include "canvas/Persistency/Provenance/ModuleDescription.h" + #include "art/Persistency/Provenance/ModuleDescription.h"