CMS 3D CMS Logo

All Classes Namespaces Files Functions Variables Typedefs Enumerations Enumerator Properties Friends Macros Modules Pages
List of all members | Public Member Functions | Private Attributes
MonitorElementCollection Class Reference

#include "DataFormats/Histograms/interface/MonitorElementCollection.h"

Public Member Functions

auto begin () const
 
auto end () const
 
bool mergeProduct (MonitorElementCollection const &product)
 
void push_back (std::unique_ptr< const MonitorElementData > value)
 
void swap (MonitorElementCollection &other)
 

Private Attributes

std::vector< std::unique_ptr< const MonitorElementData > > data_
 

Detailed Description

Description: Product to represent DQM data in LuminosityBlocks and Runs. The MonitorElements are represented by a simple struct that only contains the required fields to represent a ME. The only opration allowed on these objects is merging, which is a important part of the DQM functionality and should be handled by EDM.

Usage: This product should only be handled by the DQMStore, which provides access to the MEs inside. The DQMStore will wrap the MonitorElementData in real MonitorElements, which allow various operations on the underlying histograms, depending on the current stage of processing: In the RECO step, only filling is allowed, while in HARVESTING, the same data will be wrapped in a MonitorElement that also allows access to the ROOT objects.

Currently, the product types are not used as products and all data is passed through the edm::Service<DQMStore>.

Definition at line 281 of file MonitorElementCollection.h.

Member Function Documentation

◆ begin()

auto MonitorElementCollection::begin ( void  ) const
inline

Definition at line 293 of file MonitorElementCollection.h.

References data_.

293 { return data_.begin(); }
std::vector< std::unique_ptr< const MonitorElementData > > data_

◆ end()

auto MonitorElementCollection::end ( void  ) const
inline

Definition at line 295 of file MonitorElementCollection.h.

References data_.

Referenced by Types.LuminosityBlockRange::cppID(), and Types.EventRange::cppID().

295 { return data_.end(); }
std::vector< std::unique_ptr< const MonitorElementData > > data_

◆ mergeProduct()

bool MonitorElementCollection::mergeProduct ( MonitorElementCollection const &  product)
inline

Definition at line 297 of file MonitorElementCollection.h.

References cms::cuda::assert().

297  {
298  // discussion: https://twiki.cern.ch/twiki/bin/view/CMSPublic/SWGuidePerRunAndPerLumiBlockData#Merging_Run_and_Luminosity_Block
299  assert(!"Not implemented yet.");
300  return false;
301  // Things to decide:
302  // - Should we allow merging collections of different sets of MEs? (probably not.) [0]
303  // - Should we assume the MEs to be ordered? (probably yes.)
304  // - How to handle incompatible MEs (different binning)? (fail hard.) [1]
305  // - Can multiple MEs with same (dirname, objname) exist? (probably yes.) [2]
306  // - Shall we modify the (immutable?) ROOT objects? (probably yes.)
307  //
308  // [0] Merging should increase the statistics, but not change the number of
309  // MEs, at least with the current workflows. It might be convenient to
310  // allow it, but for the beginning, it would only mask errors.
311  // [1] The DQM framework should guarantee same booking parameters as long
312  // as we stay within the Scope of the MEs.
313  // [2] To implement e.g. MEs covering blocks of 10LS, we'd store them in a
314  // run product, but have as many MEs with same name but different range as
315  // needed to perserve the wanted granularity. Merging then can merge or
316  // concatenate as possible/needed.
317  // Problem: We need to keep copies in memory until the end of run, even
318  // though we could save them to the output file as soon as it is clear that
319  // the nexe LS will not fall into the same block. Instead, we could drop
320  // them into the next lumi block we see; the semantics would be weird (the
321  // MEs in the lumi block don't actually correspond to the lumi block they
322  // are in) but the DQMIO output should be able to handle that.
323  }
assert(be >=bs)

◆ push_back()

void MonitorElementCollection::push_back ( std::unique_ptr< const MonitorElementData value)
inline

Definition at line 285 of file MonitorElementCollection.h.

References cms::cuda::assert(), data_, eostools::move(), and relativeConstraints::value.

285  {
286  // enforce ordering
287  assert(data_.empty() || data_[data_.size() - 1] <= value);
288  data_.push_back(std::move(value));
289  }
assert(be >=bs)
std::vector< std::unique_ptr< const MonitorElementData > > data_
Definition: value.py:1
def move(src, dest)
Definition: eostools.py:511

◆ swap()

void MonitorElementCollection::swap ( MonitorElementCollection other)
inline

Definition at line 291 of file MonitorElementCollection.h.

References data_, and trackingPlots::other.

291 { data_.swap(other.data_); }
std::vector< std::unique_ptr< const MonitorElementData > > data_

Member Data Documentation

◆ data_

std::vector<std::unique_ptr<const MonitorElementData> > MonitorElementCollection::data_
private

Definition at line 282 of file MonitorElementCollection.h.

Referenced by begin(), end(), push_back(), and swap().