|
|
Rivet 4.0.0
|
- 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
|