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, the art::ScheduleContext is a class that is not a service.
• CurrentModule: system service that does not support multi-threading concepts.

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

- void()
+ void(ScheduleContext)

- void(Event const&)
+ void(Event const&, ScheduleContext)

- void(Event const&)
+ void(Event const&, ScheduleContext)

- void(Event const&)
+ void(Event const&, ScheduleContext)

- void(ModuleDescription const&)
+ void(ModuleContext const&)

- void(ModuleDescription const&)
+ void(ModuleContext const&)

- void(std::string const&)
+ void(PathContext const&)

- void(std::string const&, HLTPathStatus const&)
+ void(PathContext const&, HLTPathStatus const&)

- void(ModuleDescription const&)
+ void(ModuleContext const&)

- void(ModuleDescription const&)
+ void(ModuleContext const&)

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).

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.

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.

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.

The following program options have been adjusted:

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(...) (before art 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.

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;

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.

• 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. The simple_plugin CMake macro does not yet link against art_Persistency_Provenance, so it must be explicitly included as a library dependency.
  • Any services that call functions from art::Run, art::SubRun, or art::Event may need to link against art_Framework_Principal.
  • Anyone using the TriggerNamesService must link against art_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.

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. The EngineCreator class has moved from the art namespace to the art::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 the EngineCreator 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 an EngineCreator 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 renamed art::detail::Producer. The corresponding header file has moved from 'art/Framework/Core/ProducerBase.h' to 'art/Framework/Core/detail/Producer.h'.