Todo List

Module analysis_cbook

Add "tmp" flags to book in standard temporary paths

Module analysis_histopaths

Add "tmp" flags to return /ANA/TMP/foo/bar paths

Module particlebasetutils_pb2bool

Move to FourMomentum functions

Module particlebaseutils_kin

Mostly move to functions on FourMomentum

Add 'all' variants

Module particlebaseutils_pb2dbl

Move to FourMomentum functions

Module particleutils_kin

Or can't it? Try some of the metaprogramming that got closestMatchIndex working...

Module particleutils_pairclass

Make versions that work on ParticlePair?

Module ppair_class

Make versions that work on PdgIdPair?

Member Rivet::add_quad (NUM a, NUM b)

When std::common_type can be used, generalise to multiple numeric types with appropriate return type.

Member Rivet::add_quad (NUM a, NUM b, NUM c)

When std::common_type can be used, generalise to multiple numeric types with appropriate return type.

Member Rivet::Analysis::auxData (const string &dsname, T &rtndata)

Cache loading the H5 files? On MPI?

Member Rivet::Analysis::auxData (const string &dsname)

Cache loading the H5 files? On MPI?

Member Rivet::Analysis::book (Scatter2DPtr &snd, const string &name, const size_t npts, const double lower, const double upper)

Remove this when we switch to BinnedEstimates

Member Rivet::Analysis::book (Scatter2DPtr &snd, const string &name, const std::vector< double > &binedges)

Remove this when we switch to BinnedEstimates

Member Rivet::Analysis::getOption (std::string optname, bool def) const

Make this a template-specialisation... needs to be outside the class body?

Member Rivet::Analysis::refData (unsigned int datasetId, unsigned int xAxisId, unsigned int yAxisId) const

SFINAE to ensure that the type inherits from YODA::AnalysisObject?

Member Rivet::Analysis::refData (const string &hname) const

SFINAE to ensure that the type inherits from YODA::AnalysisObject?

Member Rivet::Analysis::registerAO (const YODAT &yao)

What about if/when we want to make the final objects the Scatter or binned persistent type?

Member Rivet::aspace (double step, double start, double end, bool include_end=true, double tol=1e-2)

Move to HEPUtils

Member Rivet::binIndex (NUM val, const CONTAINER &binedges, bool allow_overflow=false)

Use std::common_type<NUM1, NUM2>::type x = val; ?

Member Rivet::binIndex (NUM1 val, std::initializer_list< NUM2 > binedges, bool allow_overflow=false)

Use std::common_type<NUM1, NUM2>::type x = val; ?

Class Rivet::ChargedLeptons

This is just electrons and muons, unless you set taus stable!

Member Rivet::contains (const std::string &s, const std::string &sub)

Use SFINAE, Boost.Range, or other template trickery for more generic container matching?

Member Rivet::correlation (const vector< NUM > &sample1, const vector< NUM > &sample2)

Support multiple container types via SFINAE

Member Rivet::correlation_err (const vector< NUM > &sample1, const vector< NUM > &sample2)

Support multiple container types via SFINAE

Member Rivet::Correlators::hVec (int n, int m)

In C++14 this can be done much nicer with TMP.

Member Rivet::covariance (const vector< NUM > &sample1, const vector< NUM > &sample2)

Support multiple container types via SFINAE

Member Rivet::covariance_err (const vector< NUM > &sample1, const vector< NUM > &sample2)

Support multiple container types via SFINAE

Member Rivet::CumulantAnalysis::bookECorrelator (const string name, const vector< int > &h, const YODA::Estimate1D &hIn)

Rename to book(ECorrPtr, ...)

Member Rivet::CumulantAnalysis::bookECorrelator (const string &name, const vector< double > &binIn)

Rename to book(ECorrPtr, ...)

Member Rivet::CumulantAnalysis::bookECorrelator (const string name, const vector< int > &h1, const vector< int > &h2, const vector< double > &binIn)

Rename to book(ECorrPtr, ...)

Member Rivet::CumulantAnalysis::bookECorrelator (const string &name, const vector< int > &h1, const vector< int > &h2, const YODA::Estimate1D &hIn)

Rename to book(ECorrPtr, ...)

Member Rivet::CumulantAnalysis::bookECorrelator (const string &name, const YODA::Estimate1D &hIn)

Rename to book(ECorrPtr, ...)

Member Rivet::CumulantAnalysis::bookECorrelator (const string name, const vector< int > &h, const vector< double > &binIn)

Rename to book(ECorrPtr, ...)

Member Rivet::CumulantAnalysis::bookECorrelatorGap (const string &name, const YODA::Estimate1D &hIn)

Rename to book(ECorrPtr, ...)

Member Rivet::CumulantAnalysis::bookECorrelatorGap (const string &name, const vector< int > &h, const YODA::Estimate1D &hIn)

Rename to book(ECorrPtr, ...)

Member Rivet::CumulantAnalysis::ECorrelator::ECorrelator (const vector< int > &h, const vector< double > &binIn)

Implement functionality for this if needed.

Struct Rivet::DeltaRGtr

Define dR and dphi functors w.r.t. multiple ref vectors, with "all" or "any" semantics

Member Rivet::discard (const CONTAINER &c, const FN &f, CONTAINER &out)

Use const std::function<bool(typename CONTAINER::value_type)>... but need polymorphism for ParticleBase

Member Rivet::discard (const CONTAINER &c, const FN &f)

More efficient would be copy_if with back_inserter...

Use const std::function<bool(typename CONTAINER::value_type)>... but need polymorphism for ParticleBase

Member Rivet::DISFinalState::DISFinalState (DISFrame boosttype, const Cut &c)

Add a second optional Cut argument for post-boost cuts.

Member Rivet::DISFinalState::DISFinalState (const Cut &c, DISFrame boosttype)

Add a second optional Cut argument for post-boost cuts.

Member Rivet::DISRapidityGap::emPzX (const DISFrame &f) const

Document

Member Rivet::DISRapidityGap::EpPzX (const DISFrame &f) const

Document

Member Rivet::DISRapidityGap::m2X () const

Document

Member Rivet::DISRapidityGap::m2Y () const

Document

Member Rivet::DISRapidityGap::pX (const DISFrame &f) const

Document

Member Rivet::DISRapidityGap::pY (const DISFrame &f) const

Document

Member Rivet::DISRapidityGap::systemX (const DISFrame &f) const

Document

Member Rivet::DISRapidityGap::systemY (const DISFrame &f) const

Document

Member Rivet::DISRapidityGap::t () const

Document

Member Rivet::DressedLepton::addPhoton (const Particle &p, bool momsum=true)

Deprecate and override add/setConstituents instead?

Member Rivet::ELECTRON_EFF_ATLAS_RUN2_LOOSE (const Particle &e)

What about faking by jets or non-electrons?

Member Rivet::ELECTRON_EFF_CMS_RUN1 (const Particle &e)

Add charge flip efficiency?

Member Rivet::ELECTRON_EFF_CMS_RUN2 (const Particle &e)

Currently just a copy of Run 1: fix!

Member Rivet::ELECTRON_RECOEFF_ATLAS_RUN1 (const Particle &e)

Include reco eff (but no e/y discrimination) in forward region

Member Rivet::ELECTRON_SMEAR_ATLAS_RUN2 (const Particle &e)

Currently just a copy of the Run 1 version: fix!

Member Rivet::ELECTRON_SMEAR_CMS_RUN2 (const Particle &e)

Currently just a copy of the Run 1 version: fix!

Member Rivet::Event::applyProjection (PROJ &p) const

Can make this non-templated, since only cares about ptr to Projection base class

Member Rivet::FastJets::areaDef () const

Care needed re. const shared_ptr<T> vs. shared_ptr<const T>

Member Rivet::FastJets::clusterSeq () const

Care needed re. const shared_ptr<T> vs. shared_ptr<const T>

Member Rivet::FastJets::clusterSeqArea () const

Care needed re. const shared_ptr<T> vs. shared_ptr<const T>

Member Rivet::FillCollector< Cutflow >::fill (typename YAO::FillType &&fillCoords, const double weight=1.0, const double fraction=1.0)

Do we need to deal with users using fractions directly?

Class Rivet::FillCollector< T >

Do we really want this inheritance from YODA::AOs??

Member Rivet::FillCollector< YODA::BinnedDbn< 1, AxisT > >::fill (typename YAO::FillType &&fillCoords, const double weight=1.0, const double fraction=1.0)

Do we need to deal with users using fractions directly?

Member Rivet::FillCollector< YODA::BinnedDbn< 2, AxisT > >::fill (typename YAO::FillType &&fillCoords, const double weight=1.0, const double fraction=1.0)

Do we need to deal with users using fractions directly?

Member Rivet::FillCollector< YODA::BinnedDbn< 2, AxisT1, AxisT2 > >::fill (typename YAO::FillType &&fillCoords, const double weight=1.0, const double fraction=1.0)

Do we need to deal with users using fractions directly?

Member Rivet::FillCollector< YODA::BinnedDbn< 3, AxisT1, AxisT2 > >::fill (typename YAO::FillType &&fillCoords, const double weight=1.0, const double fraction=1.0)

Do we need to deal with users using fractions directly?

Member Rivet::FillCollector< YODA::BinnedDbn< 3, AxisT1, AxisT2, AxisT3 > >::fill (typename YAO::FillType &&fillCoords, const double weight=1.0, const double fraction=1.0)

Do we need to deal with users using fractions directly?

Member Rivet::FillCollector< YODA::BinnedDbn< 4, AxisT1, AxisT2, AxisT3 > >::fill (typename YAO::FillType &&fillCoords, const double weight=1.0, const double fraction=1.0)

Do we need to deal with users using fractions directly?

Member Rivet::FillCollector< YODA::BinnedDbn< DbnN, AxisT... > >::fill (typename YAO::FillType &&fillCoords, const double weight=1.0, const double fraction=1.0)

Do we need to deal with users using fractions directly?

Member Rivet::FillCollector< YODA::Counter >::fill (const double weight=1.0, const double fraction=1.0)

Do we need to deal with users using fractions directly?

Member Rivet::FinalState::accept (const Particle &p) const

Rename to _accept or acceptFinal?

Member Rivet::fnspace (size_t nbins, double start, double end, const std::function< double(double)> &fn, const std::function< double(double)> &invfn, bool include_end=true)

Move to HEPUtils

Class Rivet::FourVector

Add composite set/mk methods from different coord systems

Member Rivet::getDatafilePath (const string &papername)

Also provide a Scatter3D getRefData() version?

Member Rivet::getEnvParam (const std::string name, const T &fallback)

Should the param name have to be specific to an analysis? Can specialise as an Analysis member fn.

Member Rivet::getONNX (const string &analysisname, const string &suffix=".onnx")

: If ONNX is ever fully integrated into rivet, move to analysis class.

Class Rivet::HeavyHadrons

This assumes that the heavy hadrons are unstable... should we also look for stable ones in case the decays are disabled?

Namespace Rivet::HepMCUtils

Use MCUtils?

Member Rivet::HTT::InputParameters::W_mass

Take from a central set of constants

Member Rivet::idiscard (CONTAINER &c, const FN &f)

Use const std::function<bool(typename CONTAINER::value_type)>... but need polymorphism for ParticleBase

Member Rivet::iselect (CONTAINER &c, const FN &f)

Use const std::function<bool(typename CONTAINER::value_type)>... but need polymorphism for ParticleBase

Member Rivet::isortBy (MOMS &pbs, const CMP &cmp)

Add sorting by phi [0..2PI]

Member Rivet::JET_BTAG_ATLAS_RUN1 (const Jet &j)

This form drops past ~100 GeV, asymptotically to zero efficiency... really?!

Member Rivet::JET_BTAG_PERFECT (const Jet &j)

Need to be able to pass a tag pT threshold? -> functor struct

Member Rivet::JET_CTAG_PERFECT (const Jet &j)

Need to be able to pass a tag pT threshold? -> functor struct

Member Rivet::JET_SMEAR_ATLAS_RUN1 (const Jet &j)

Also need a JES uncertainty component?

Is this the best way to smear? Should we preserve the energy, or pT, or direction?

Member Rivet::JET_SMEAR_ATLAS_RUN2 (const Jet &j)

Just a copy of the Run 1 one: improve!!

Member Rivet::JET_SMEAR_CMS_RUN1 (const Jet &j)

Just a copy of the suboptimal ATLAS one: improve!!

Member Rivet::JET_SMEAR_CMS_RUN2 (const Jet &j)

Just a copy of the suboptimal ATLAS one: improve!!

Member Rivet::JET_SMEAR_IDENTITY (const Jet &j)

Modify constituent particle vectors for consistency

Set a null PseudoJet if the Jet is smeared?

Member Rivet::JET_TAUTAG_PERFECT (const Jet &j)

Need to be able to pass a tag pT threshold? -> functor struct

Struct Rivet::JetEffSmearFn

Include tagging efficiency functions?

Member Rivet::JetEffSmearFn::sfn

Ambiguity re. whether reco eff or a tagging efficiency...

Member Rivet::JetFinder::jets (const JetSorter &sorter, const Cut &c=Cuts::open()) const

Will the vector be efficiently std::move'd by value through this function chain?

Member Rivet::JetFinder::jets (const JetSelector &selector, const JetSorter &sorter) const

Will the vector be efficiently std::move'd by value through this function chain?

Member Rivet::JetFinder::jets (const Cut &c, const JetSorter &sorter) const

Will the vector be efficiently std::move'd by value through this function chain?

Member Rivet::JetShape::project (const Event &e)

Provide int and diff jet shapes with some sort of area normalisation?

Member Rivet::LeptonFinder::LeptonFinder (const FinalState &leptonfs, const FinalState &photonfs, double dRdress, const Cut &cut=Cuts::OPEN, DressingType dressing=DressingType::CONE)

Convert the "bare" arg to a general ParticleFinder rather than an FS, to allow clustering of unstables, e.g. taus via TauFinder when that becomes a PF. Complicated by the clustering version relying on MergedFinalState and FastJets' current restriction to FinalState inputs. Requires widespread redesign.

Member Rivet::LeptonFinder::LeptonFinder (const FinalState &leptonfs, const FinalState &photonfs, const Cut &cut, double dRdress, DressingType dressing=DressingType::CONE)

Convert the "bare" arg to a general ParticleFinder rather than an FS, to allow clustering of unstables, e.g. taus via TauFinder when that becomes a PF. Complicated by the clustering version relying on MergedFinalState and FastJets' current restriction to FinalState inputs. Requires widespread redesign.

Member Rivet::linspace (size_t nbins, double start, double end, bool include_end=true)

Move to HEPUtils

Member Rivet::logspace (size_t nbins, double start, double end, bool include_end=true)

Move to HEPUtils

Class Rivet::LorentzTransform

Review the active/passive convention choice. Seems counterintuitive now...

Class Rivet::MC_JETS_BASE

Could reduce duplication by inheriting this from MC_ParticleAnalysis, with minor tweaking

Class Rivet::MC_pPbMinBiasTrigger

Move into Projections?

Class Rivet::MC_SumETFwdPbCentrality

Move into Projections?

Member Rivet::mean (const vector< NUM > &sample)

Support multiple container types via SFINAE

Member Rivet::mean_err (const vector< NUM > &sample)

Support multiple container types via SFINAE

Member Rivet::median (const vector< NUM > &sample)

Support multiple container types via SFINAE

Class Rivet::MergedFinalState

Extend to merging many FS projections

Member Rivet::MET_SMEAR_ATLAS_RUN2 (const Vector3 &met, double set)

Allow smearing function to access the whole event, since Njet also affects? Or assume encoded in SET?

Member Rivet::METFinder::vectorPt () const =0

Currently equivalent to vectorEt

Member Rivet::MissingMomentum::missingMomentum (double mass=0 *GeV) const

Change to return a 3-vector with no argument, a 4-vector if a mass arg given

Member Rivet::MissingMomentum::visibleMomentum (double mass=0 *GeV) const

Change to return a 3-vector with no argument, a 4-vector if a mass arg given

Class Rivet::Multiplexer< T >

Some things are not really well-defined here. For instance: fill() in the finalize() method and integral() in the analyze() method. Should we throw?

Member Rivet::Multiplexer< T >::collapseEventGroup (const vector< std::valarray< double > > &weights, const double nlowfrac=0.0)

If we don't multiplex (Binned)Estimates, perhaps we can get rid of this protection?

Member Rivet::Multiplexer< T >::collapseSubevents (const vector< std::valarray< double > > &weights, const double nlowfrac)

Do we really need the transposing??

Class Rivet::MultiplexPtr< T >

Provide remaining functionality that shared_ptr has (not needed right now).

Member Rivet::MUON_EFF_CMS_RUN2 (const Particle &m)

Currently just a copy of Run 1: fix!

Member Rivet::MUON_SMEAR_ATLAS_RUN1 (const Particle &m)

Add muon loose/medium/tight ID efficiencies? All around 95-98%... ignore?

Member Rivet::MUON_SMEAR_CMS_RUN2 (const Particle &m)

Currently just a copy of the Run 1 version: fix!

Member Rivet::operator+ (const ThreeMomentum &a, const Vector3 &b)

Mixed-arg operators: better via SFINAE??

Member Rivet::P4_SMEAR_E_GAUSS (const FourMomentum &p, double resolution)

Also make jet versions that update/smear constituents?

Member Rivet::Particle::children (const Cut &c=Cuts::OPEN) const

isDecayed? How to restrict to physical particles?

Member Rivet::Particle::closestApproach () const

Check that this works with all angles

Member Rivet::Particle::stableDescendants (const Cut &c=Cuts::OPEN) const

Use recursion through replica-avoiding MCUtils functions to avoid bookkeeping duplicates

Insist that the current particle is post-hadronization, otherwise throw an exception?

Member Rivet::Percentile< T >::operator+= (const Percentile< T > &rhs)

should this also add the Counter?

Member Rivet::PercentileProjection::PercentileProjection (const SingleValueProjection &sv, const Histo1D &calhist, PercentileOrder pctorder=PercentileOrder::DECREASING)

Use mkScatter to pass this to the Scatter2D-calibrated version?

Member Rivet::PHOTON_EFF_ATLAS_RUN1 (const Particle &y)

Allow electron misID? What about jet misID?

Member Rivet::PHOTON_EFF_ATLAS_RUN2 (const Particle &y)

Allow electron misID? What about jet misID?

Member Rivet::PHOTON_EFF_CMS_RUN1 (const Particle &y)

Currently from Delphes

Allow electron misID? What about jet misID?

Member Rivet::PHOTON_EFF_CMS_RUN2 (const Particle &y)

Allow electron misID? What about jet misID?

Currently just a copy of Run 1: fix!

Member Rivet::PHOTON_SMEAR_ATLAS_RUN1 (const Particle &y)

Use real photon smearing

Member Rivet::PID::charge3 (int pid)

Is this sufficiently general? Why only gluino in g+q+qbar? Better to recurse to the related SM hadron code?

Member Rivet::PID::isBaryon (int pid)

This is more correct by the definition, but the PDG's entries 1212, 1214, 1216, 1218 and 2122, 2124, 2126, 2128 come out as invalid

Why this special case with nJ = 0? What are these? Not listed in RPP MC doc...

Member Rivet::PID::isCharged (int pid)

What if PID = 0? Applies to everything... should we throw an exception?

Member Rivet::PID::isDarkMatter (int pid)

Give a more explicit name to clarify that this does not cover all DM particles, e.g. LSP?

Member Rivet::PID::isGraviton (int pid)

isSUSYHiggs?

Member Rivet::PID::isMeson (int pid)

Remove special-casing for EvtGen

Member Rivet::PID::isResonance (int pid)

Also include SUSY, technicolor, etc. etc.? Maybe via a isStandardModel(pid) function, but there are stable BSM particles (in principle)

Member Rivet::PID::isTransportable (int pid)

Should exclude neutrinos/LSP, since the ATLAS G4 interface deletes them immediately?

What about long-lived particles... could be BSM but need to be transported

Member Rivet::powdbnspace (size_t nbins, double start, double end, double npow, bool include_end=true)

Move to HEPUtils

Member Rivet::powspace (size_t nbins, double start, double end, double npow, bool include_end=true)

Move to HEPUtils

Class Rivet::PrimaryHadrons

Also be able to return taus? Prefer a separate tau finder.

This assumes that the primary hadrons are unstable... should we also look for stable primary hadrons?

Member Rivet::ProjectionApplier::declare (const PROJ &proj, const std::string &name) const

Add SFINAE to require that PROJ inherit from Projection

Member Rivet::ProjectionApplier::declare (const std::string &name, const PROJ &proj) const

Add SFINAE to require that PROJ inherit from Projection

Member Rivet::ProjectionApplier::get (const std::string &name) const

Add SFINAE to require that PROJ inherit from Projection

Member Rivet::ProjectionApplier::getProjection (const std::string &name) const

Add SFINAE to require that PROJ inherit from Projection

Member Rivet::ProjectionApplier::setProjectionHandler (ProjectionHandler &projectionHandler) const

AB: Add Doxygen comment, follow surrounding coding style

Class Rivet::PromptFinalState

Use enums for tau, mu, brem

Decide how to treat brem photons off prompt leptons – are they also prompt? "Decay" does not change the lepton PID...

Member Rivet::PseudoJets

Make into an explicit container with conversion to Jets and FourMomenta?

Member Rivet::safediv (double num, double den, double fail=0.0)

When std::common_type can be used, generalise to multiple numeric types with appropriate return type.

Member Rivet::select (const CONTAINER &c, const FN &f)

More efficient would be copy_if with back_inserter ... but is that equally container agnostic?

Use const std::function<bool(typename CONTAINER::value_type)>... but need polymorphism for ParticleBase

Member Rivet::select (const CONTAINER &c, const FN &f, CONTAINER &out)

Use const std::function<bool(typename CONTAINER::value_type)>... but need polymorphism for ParticleBase

Class Rivet::SmearedJets

Allow applying a pre-smearing cut so smearing doesn't need to be applied to below-threshold micro-jets

Member Rivet::SmearedJets::project (const Event &e)

As above... ?

Or could use the/an actual clustered b-quark momentum?

Member Rivet::SmearedJets::RIVET_DEFAULT_PROJ_CLONE (SmearedJets)

How to include tagging effs?

Variadic eff/smear fn list?

Add a trailing Cut arg cf. SmearedParticles? – wrap into an eff function

Member Rivet::SmearedJets::SmearedJets (const JetFinder &ja, const JetSmearFn &smearFn, const JetEffFn &bTagEffFn=JET_BTAG_PERFECT, const JetEffFn &cTagEffFn=JET_CTAG_PERFECT)

Add a tau-tag slot

Member Rivet::SmearedJets::SmearedJets (const JetFinder &ja, const JetEffFn &bTagEffFn, const JetEffFn &cTagEffFn, Args &&... effSmearFns)

Add a tau-tag slot

Member Rivet::SmearedMET::vectorPt () const

Currently equivalent to vectorEt

Member Rivet::SmearedParticles::project (const Event &e)

Is this a good idea?? What if raw particles are requested?

Member Rivet::SmearedParticles::SmearedParticles (const ParticleFinder &pf, const Cut &c, Args &&... effSmearFns)

Wouldn't it be nice if the Cut could also go after the parameter pack?

Member Rivet::TAU_EFF_CMS_RUN1 (const Particle &t)

Needs work; this is just a copy of the Run 2 version in Delphes 3.3.2

Member Rivet::TAU_EFF_CMS_RUN2 (const Particle &t)

Needs work; this is the dumb version from Delphes 3.3.2

Member Rivet::TAU_SMEAR_ATLAS_RUN1 (const Particle &t)

Also need a JES uncertainty component?

Currently a copy of the jet smearing

Is this the best way to smear? Should we preserve the energy, or pT, or direction?

Member Rivet::TAU_SMEAR_ATLAS_RUN2 (const Particle &t)

Currently a copy of the Run 1 version

Member Rivet::TAU_SMEAR_CMS_RUN1 (const Particle &t)

Currently a copy of the crappy ATLAS one

Member Rivet::TAU_SMEAR_CMS_RUN2 (const Particle &t)

Currently a copy of the Run 1 version

Class Rivet::TauFinder

Convert to a general ParticleFinder, but this has many knock-on effects and requires e.g. FastJets to also be generalised.

Member Rivet::TauFinder::TauFinder (TauDecay decaymode=TauDecay::ANY, const Cut &cut=Cuts::open())

What about directness/promptness?

Member Rivet::Taus

Make this the canonical name in future?

Member Rivet::transform (const CONTAINER1 &in, CONTAINER2 &out, FN &&f)

Make the function template specific to ParticleBase or introduce C++20 concepts

Member Rivet::transform (const CONTAINER1 &in, const std::function< RTN(typename CONTAINER1::value_type::ParticleBase)> &f)

Make the function template polymorphic... or specific to ParticleBase

Class Rivet::TriggerCDFRun0Run1

Should really inherit from TriggerProjection!

Class Rivet::TriggerCDFRun2

Should really inherit from TriggerProjection!

Member Rivet::TRK_EFF_ATLAS_RUN2 (const Particle &p)

Currently just a copy of Run 1: fix!

Member Rivet::TRK_EFF_CMS_RUN2 (const Particle &p)

Currently just a copy of Run 1: fix!

Class Rivet::UnstableParticles

Convert to a general ParticleFinder since this is explicitly not a final state... but needs care

Add a FIRST/LAST/ANY enum to specify the mode for uniquifying replica chains (default = LAST)

Member Rivet::Vector3::azimuthalAngle (const PhiMapping mapping=ZERO_2PI) const

Would it be better to return NaN in the null-perp case? Or throw?!

Member Rivet::VetoedFinalState::addDecayProductsVeto (PdgId pid)

Need HepMC to sort themselves out and keep vector bosons from the hard vtx in the event record before this will work reliably for all pdg ids

Member Rivet::weighted_shuffle (RandomAccessIterator first, RandomAccessIterator last, WeightIterator fw, WeightIterator lw, RandomNumberGenerator &g)

Move to utils?

Module Specialised

Get rid of this, make it all work via the base class definitions and template matching