klfitter / klfitter

Repository hosting the KLFitter library – the Kinematic Likelihood Fitter.

KLFitter – The Kinematic Likelihood Fitter

KLFitter is a library for kinematic fitting using a likelihood approach. It is primarily developed for the case of top quark reconstruction, but it can be easily modified to fit other processes. Detailed documentation:

• List of authors and contributors
• What is KLFitter and how does it work?
• Out-of-the-box example
• Frequently Asked Questions

An auto-generated class reference guide for the KLFitter library is also uploaded to https://KLFitter.github.io. The uploaded version always corresponds to the latest version of the master branch.

Licensing terms

KLFitter is licensed under the GNU Lesser General Public License v3.0. For more information about the licensing terms and conditions, please refer to COPYING and COPYING.lesser for the GNU General Public License and the additional terms of the GNU Lesser General Public License, respectively.

Dependencies

KLFitter depends on the ROOT and BAT libraries. For information about ROOT, please consult the ROOT web page. Information about BAT, installation instructions and the latest BAT releases can be found on the library's web page. The following versions have been tested with KLFitter and are working:

• ROOT v5.34.10 or later
• BAT v0.9.3 and v0.9.4.1

Obtaining KLFitter

The KLFitter source code can be obtained from this repository (https://github.com/KLFitter/KLFitter). A list of all releases of KLFitter can be found under KLFitter/releases. To download the source code, you can use the git clone command:

git clone https://github.com/KLFitter/KLFitter.git

and, for checking out a specific release, use the git checkout procedure:

cd KLFitter
git checkout $VERSION_TAG

Before KLFitter was made public, it was maintained in non-public SVN repositories. For completeness we also keep a list of all SVN tags of KLFitter and their associated commits in this file.

Installation via cmake (recommended)

Before proceeding please make sure that you have a valid installation of ROOT on your system and that cmake is correctly configured (version 3.1 or higher is required). As cmake does fully automated configuration, it is possible to build KLFitter and the BAT library simultaneously. BAT will be downloaded during the cmake build process. For doing so, change into the KLFitter directory and then do:

mkdir build && cd build
cmake -DBUILTIN_BAT=TRUE ..
make -j

This will build both BAT and KLFitter in the build sub-folder of the KLFitter directory. If you already have an existing installation of BAT, you can also link the KLFitter library against that version and not download BAT during the cmake build process. For that, make sure that the environment variable $BATINSTALLDIR points to the BAT installation directory and is exported. This variable will be used by FindBAT.cmake, which locates the BAT library. With a local version of BAT, the -DBUILTIN_BAT flag of the cmake command can be omitted, i.e. the KLFitter build procedure becomes:

mkdir build && cd build
cmake ..
make -j

For problems with the cmake configuration, please also refer to the Frequently Asked Questions.

Installation via Makefile (deprecated)

The repository also comes with a Makefile, although using cmake to build KLFitter is the recommended procedure. Compilation via Makefile assumes that you have a working installation of ROOT and BAT. The location of the BAT library is determined with the $BATINSTALLDIR variable, so make sure to set and export it. Then switch to the KLFitter repository directory and call

make -j all && make -j install

to compile KLFitter. The latter command will create a subdirectory build and copy the header and library files into that directory for external usage.

klfitter's Issues

Memory leak in underlying BCEngineMCMC class of BAT

Description

As reported by valgrind, the underlying BAT class BCEngineMCMC has memory leaks in its function BCEngineMCMC::AddParameter. Apparently, this seems to be a known issue since this is noted down in the source code as well.

Possible Fix

We would either have to switch to an updated version of BAT, in which this issue has possibly been addressed. Another chance would be to use the ClearParameters(bool) function, which – when the boolean is set to true – deletes all memory that the pointers in the parameter container point to. This function call could be added to the LikelihoodBase destructor (which would hopefully solve this leak for all likelihood classes).

Your Environment

• KLFitter version used: bb5a4ac
• BAT version used: 0.9.4.1
• ROOT version used: 6.10/04
• Operating System and version: SL6
• Link to your project:

Remove gluon and photon parameter requirements from atlas detector

Description

The classes for the atlas detector require parameter sets for gluons and photons, and also provide functionality for them. As none of those particle types is used in any of the likelihoods, those requirements could be removed. If parameter sets don't include those parameterisations, this causes warnings for missing files.

Expected Behavior

Only require the files that are actually necessary for full functionality.

Actual Behavior

Required files include those for photons and gluons, which are not used anywhere.

Context

Users are confused by warnings issued by the detector classes, when parameter sets do not contain parameterisations for gluons and photons.

Your Environment

• KLFitter version used: 1.0.0
• BAT version used: 0.9.4.1
• ROOT version used: 6.10/04
• Operating System and version: SL6
• Link to your project:

Implementation of kVetoHybridNoFit btagging option

Description

When running btagging options with NoFit the code exists when no permutation is allowed in an event. This requires users to modify their selection for these b-tagging options. Possible workaround for this problem could be to provide a new option that works like kVetoNoFit and when an event with no allowed permutations occurs, the btagging option switches to kVetoLightNoFit which ensures that there are some allowed permutations in the event.

Note: Option with NoFit are desirable because they significantly reduce CPU time

Expected Behavior

New btagging option that saves CPU time by excluding some permutations that work with arbitrary number of btagged jets should be added

Reduce number of public library header files

Description

At the moment, the cmake configuration simply lists all header files as public library header files, i.e. all files are copied to the install directory in the install step. This is (in principal) not necessary as only few of the header files are really needed to implement KLFitter in a software interface. Quite a few of the header files are only used internally.

Expected Behavior

Only mark those files as public library header files that are needed for the implementation of the library into another software framework.

Actual Behavior

All header files included as public library headers.

Possible Fix

Exclude the header files not necessary for interfacing KLFitter. The problem with this is that some of the unnecessary headers are included in other header files, i.e. they are implicitly required when linking software against the library. This needs to be resolved.

Steps to Reproduce

1. Compile package via cmake and do make install.

Context

Easier/less confusing integration into other software.

Your Environment

• KLFitter version used: latest master
• BAT version used: 0.9.4.1
• ROOT version used: 6.12/04
• Operating System and version: Mac OS X 10.13.4
• Link to your project: –

Reduce includes/dependencies on ROOT

Description

Specifically the public header files should only include as little dependencies as possible, as they get included in other libraries as well. It would be nice to remove dependencies on ROOT as much as possible. In particular, quite a lot of classes include TLorentzVector, although this can probably be avoided.

Expected Behavior

Ideally don't include any ROOT classes in the headers, but only use forward declarations. There might be cases, where an include makes more sense, but those should be kept minimal.

Actual Behavior

ROOT classes are currently included in a lot of files, including the ones marked as public headers.

Possible Fix

Use forward declarations as much as possible. Stick to (smart) pointers, when forward declarations would not be possible otherwise, e.g. std::vector<T> needs an include of T, but std::vector<std::unique_ptr<T>> does not.

Your Environment

• KLFitter version used: 5b06d79
• BAT version used: 0.9.4.1
• ROOT version used: 6.10/v4
• Operating System and version: OS X
• Link to your project:

Unexpected different solutions on same events

Description

I am running over ttbar l+jets events with the LH=ttbar, kLeadingFour and KNotag options.
I run KLFitter twice on the same events, once asking for at least one jet to be b-tagged with a specific tagger and a second time applying the same selections but changing the b-tagging algorithm.

Expected Behavior

Since the b-tagging information is not used by KLFitter I would expect its solution to be the same in these two cases.

Actual Behavior

However, I see for a fraction of these events (~5%) this is not the case. Looking at events where this happens I can see that among the 12 permutations most of them have the exact same solution expect made for the best one.
I made sure that the settings are all properly passed to KLFitter and checked that for those events the objects kinematics passed to the algorithm is exactly the same. I went as far back to the Fit() case, where I see the difference arises.

I would like to understand if this is a spurious effect coming from the nature of the fit. It is important to me that the reconstruction is independent from the b-tagger used so it would be nice to assess that this is not the root of the discrepancy.

Move angular detector parameterisations to dedicated atlas detector class

Description

The atlas detector class contains functionality for angular parameterisations, and also requires those files for the parameter sets. However, the angular parameterisations are only used in very few specific likelihoods, and not generally needed. The main detector class should not require them, but instead we could create a dedicated derived detector class with angular information.

Expected Behavior

Only require the files needed for "normal" likelihoods. If angular information is needed, use a dedicated detector implementation with angular information.

Actual Behavior

All parameterisations are included in the standard class, which causes warnings if a parameter set doesn't contain angular parameterisations.

Possible Fix

Create a dedicated class, something like DetectorAtlas_angular, which includes the parameterisations for eta and phi. But don't require them in the normal atlas detector implementation.

Context

Users are confused by warnings issued by the detector classes, when parameter sets do not contain angular parameterisations.

Your Environment

• KLFitter version used: 1.0.0
• BAT version used: 0.9.4.1
• ROOT version used: 6.10/04
• Operating System and version: SL6
• Link to your project:

Reduce number of user-defined constructors/destructors

Description

At the moment, the code uses quite a lot of user-defined constructors/destructors, some of which are empty. With a bit of re-organisation of the code it should be possible to remove these implementations entirely, and instead use the default keyword for quite a lot of the classes' constructors and destructors.

Expected Behavior

Only provide explicit constructors/destructors, if we really need custom behaviour. When raw pointers are removed (see #16), most of the destructors should be unnecessary.

Actual Behavior

All classes have explicit implementations of constructors/destructors, a lot of which are empty.

Possible Fix

Use the default keyword in the class header files. For some classes this might require a few changes for the includes, as for example std::unique_ptr<T> requires inclusion of T, when the destructor is defaulted.

Context

Efforts to reduce the overall size and complexity of the code.

Your Environment

• KLFitter version used: b2579de
• BAT version used: 0.9.4.1
• ROOT version used: 6.10/v4
• Operating System and version: OS X
• Link to your project:

Memory leak reported in Snowmass detector

Description

Using valgrind a memory leak was traced back to the Snowmass detector class:

==23322== 72 (40 direct, 32 indirect) bytes in 1 blocks are definitely lost in loss record 5,579 of 8,146                                                 │
==23322==    at 0x4A085FC: operator new(unsigned long) (vg_replace_malloc.c:298)                                                                          │
==23322==    by 0x40B15D: KLFitter::DetectorSnowmass::DetectorSnowmass(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >) (D│
etectorSnowmass.cxx:45)                                                                                                                                   │
==23322==    by 0x40A3FA: main (test-ljets-lh.cxx:114)

Possible Fix

Add the corresponding delete in the destructor of the detector class – or switch to smart pointers, as suggested in #16. But this will be more of a long-term fix.

Your Environment

• KLFitter version used: bb5a4ac
• BAT version used: 0.9.4.1
• ROOT version used: 6.10/04
• Operating System and version: SL6
• Link to your project:

Full eta check for transfer functions

Add code that checks if all eta regions from transfer functions are provided

Description

Code now only checks that eta 0 transfer function exists, but it is possible that parameters for eta = 0 exist but others are missing, this deals to an unexpected behaviour

Expected Behavior

The code should throw an error and exit if the needed parameters are not provided

Actual Behavior

The code continues normally but gives NAN values

Clean-up of the ATLAS detector classes

Please note: description adjusted following some of the comments below.

Description

Currently, KLFitter contains two classes that serve as a basis to parameterise the ATLAS detector. They are different in terms of the eta binning, and also the used Double-Gaussian parameterisations are different. They're labelled "7TeV" and "8TeV", which is slightly confusing, because both could be used for any energies, just the parameterisation for 7TeV Monte-Carlo samples was done differently.

We should not include energy labels in the detector classes, as they can be used for different centre-of-mass energies without any problems. We could rename them, following a more generic pattern, such as DetectorAtlas_v1. For the specific transfer function parameter sets, we would then have to point out which detector to use.

Possible Fix

Rename both classes. However, this implies a change in the interface for any software using the ATLAS detector classes. To avoid this, we could – for now – rename the two classes, but use aliases to provide compatibility with the old naming convention. Something like

class DetectorAtlas_v1 {
  // First version of the detector, implemented for mc11
   ...
};
class DetectorAtlas_v2 {
  // Second version of the detector, implemented for mc12 and later
  ...
};

using DetectorAtlas_7TeV = DetectorAtlas_v1;
using DetectorAtlas_8TeV = DetectorAtlas_v2;

Context

We have received questions multiple times, as to why the 8TeV detector implementation is used for 13TeV. Using more generic names would avoid that confusion.

Transfer function classes cleanup

Some of the TF classes should inherit from base classes (as is done for most of the TF classes) and should not be derived directly from the base class. This includes ResGaussE, ResGaussPt ResGauss_MET, ResSingleGaussLinear

Description

These classes should have only GetSigma() method different and not the implementation of probability calculation as this is identical

Cmake option to switch off builds of examples

Description

It would be nice to have a cmake option to turn on/off the builds of the example executable(s).

Expected Behavior

The switch should be on by default, but there should be the possibility to turn off the builds of the examples.

Actual Behavior

Examples are always built when using cmake.

Possible Fix

Add a cmake option, such as INSTALL_EXAMPLES.

Context

Problems encountered when including the current KLFitter version into other software. The example is not needed there, so to avoid those issues, it would be nice to just switch it off.

Your Environment

• KLFitter version used: latest (24dab56)

Make angular likelihoods derived classes of l+jets likelihood

Description

The angular likelihoods LikelihoodTopLeptonJets_Angular and LikelihoodTopLeptonJets_JetAngles are essentially modifications of the standard LikelihoodTopLeptonJets, thus, they share a lot of the implementation code. However, all of them are currently derived independently from LikelihoodBase, that is, a lot of the same code is implemented in three different classes. To reduce the code clutter, the two angular likelihoods should derive from the l+jets likelihood and only reimplement, what is actually changed.

Expected Behavior

Modifications of the l+jets likelihood should be derived from it and only reimplement functions that need actual changes.

Actual Behavior

All three classes have the same base class, but are implemented independently. As a consequence, 80%+ of the classes' implementations are identical.

Your Environment

• KLFitter version used: latest (v1.1.0)

Treatment of TFs when the provided path is wrong

Description

KLFitter doesn't stop when the provided TF are invalid. There should be a protection that stops the code when TF are invalid and are needed by the given likelihood.

Expected Behavior

KLFitter should print an error and stop immediately.

Actual Behavior

KLFItter prints warnings that TFs do not exist but continues running and burning CPUs.

Context

This can results in useless runs on the grid that produce non-sense results.

Your Environment

• KLFitter version used: 1.0.0

Make KLFitter::Particles::AddParticle interface (and others) const-correct

Description

At present, KLFitter::Particles::AddParticle requires the user to pass in a non-const TLorentzVector&. This means that if one already has a const TLorentzVector, e.g. from an experiment's EDM, this has to be copied into another TLorentzVector or worse const_cast-ed. Neither of these is elegant, and the former incurs overhead from the copy operation. Furthermore, this leaves open the possibility of accidentally changing the input particles.

If the KLFitter operations do not modify the particles, then the input TLorentzVector parameter ought to be const. This is an interface change, but requires no changes to client code, but would allow cleaner handling.

Fix

Enforce const-correctness in KLFitter::Particles::AddParticle, and in other setter methods (e.g. KLFitter::LikelihoodBase constructor, SetDetector, SetParticlesPermuted, ...)

KLFitter crash for ttbar->jets likelihood

Description

Dear KLFitter developers,
I run KLFitter from AnalysisTop (version 21.2.45) with ttbar->jets likelihood. I require at least 6 jets and at least 1 b-tag. I use following settings of KLFitter:

KLFitterLH ttbar_AllHadronic

KLFitterBTaggingMethod kVeto

KLFitterJetSelectionMode kBtagPrioritySixJets

My config file can be found here
I've experienced crash, with the following error message:

#0 0x00007f176935d89e in waitpid () from /lib64/libc.so.6
#1 0x00007f17692ef4e9 in do_system () from /lib64/libc.so.6
#2 0x00007f176b8534c8 in TUnixSystem::StackTrace() () from /cvmfs/atlas.cern.ch/repo/sw/software/21.2/AnalysisBaseExternals/21.2.46/InstallArea/x86_64-slc6-gcc62-opt/lib/libCore.so
#3 0x00007f176b8559cc in TUnixSystem::DispatchSignals(ESignals) () from /cvmfs/atlas.cern.ch/repo/sw/software/21.2/AnalysisBaseExternals/21.2.46/InstallArea/x86_64-slc6-gcc62-opt/lib/libCore.so
#4
#5 0x00007f17521ec39e in KLFitter::Permutations::InvariantParticleGroupPermutations(KLFitter::Particles::ParticleType, std::vector<int, std::allocator >, std::vector<int, std::allocator >) () at /build2/atnight/localbuilds/nightlies/21.2/AnalysisBase/build/build/AnalysisBaseExternals/src/KLFitter/src/Permutations.cxx:452
#6 0x00007f17521b98f6 in KLFitter::LikelihoodTopAllHadronic::RemoveInvariantParticlePermutations() () at /build2/atnight/localbuilds/nightlies/21.2/AnalysisBase/build/build/AnalysisBaseExternals/src/KLFitter/src/LikelihoodTopAllHadronic.cxx:246
#7 0x00007f175219ea68 in KLFitter::Fitter::SetParticles(KLFitter::Particles*, int) () at /build2/atnight/localbuilds/nightlies/21.2/AnalysisBase/build/build/AnalysisBaseExternals/src/KLFitter/src/Fitter.cxx:64
#8 0x00007f1752445322 in top::KLFitterTool::execute(top::Event const&) () from /cvmfs/atlas.cern.ch/repo/sw/software/21.2/AnalysisTop/21.2.46/InstallArea/x86_64-slc6-gcc62-opt/lib/libTopEventReconstructionTools.so
#9 0x00007f175243bf96 in top::KLFitterRun::apply(top::Event const&) const () from /cvmfs/atlas.cern.ch/repo/sw/software/21.2/AnalysisTop/21.2.46/InstallArea/x86_64-slc6-gcc62-opt/lib/libTopEventReconstructionTools.so
#10 0x00007f176bdac9f5 in top::EventSelection::apply(top::Event const&) const () from /cvmfs/atlas.cern.ch/repo/sw/software/21.2/AnalysisTop/21.2.46/InstallArea/x86_64-slc6-gcc62-opt/lib/libTopAnalysis.so
#11 0x00007f176bdb1053 in top::EventSelectionManager::apply(top::Event&, xAOD::SystematicEvent const&) () from /cvmfs/atlas.cern.ch/repo/sw/software/21.2/AnalysisTop/21.2.46/InstallArea/x86_64-slc6-gcc62-opt/lib/libTopAnalysis.so
#12 0x00000000004263ea in main ()

It seems like there is something wrong with removal of invariant permutations. Could you please look at it and fix, if possible?

Thank you in advance,
Michal

Steps to Reproduce

1. asetup AnalysisTop,21.2.45
2. top-xaod config_at.txt "a list of samples"

Remove all raw pointers from the code

Description

The code still uses raw pointers in many of its classes. Although the memory is probably taken care of correctly (i.e. no memory leaks), it would still be more elegant to either not use pointers at all, when not necessary, or switch to smart pointers that own the pointed-to memory.

In some cases smart pointers might be favoured, when they are used within template specialisations. In that case, smart pointers allow forward declarations of the corresponding class, whereas using an object-type template specialisation requires an explicit include.

Expected Behavior

Avoid pointers as much as possible generally, because we don't need to take care of memory at all then. If not avoidable, or if favourable, use pointers, but stick to smart pointers of the memory should be owned. It is fine to keep using raw pointers for function arguments, or as return types for methods, if there is no intention to transfer ownership.

Actual Behavior

Raw pointers are used at many different places of the code. Particularly, many classes have member variables defined as pointers. This might be useful, when the pointers are of a base class type and then point to a derived-class memory, but it would be more elegant to use smart pointers in that case. In many cases, pointers are not needed at all. In that case, switch to objects, not pointers to objects.

For example, an object of type

std::vector<TLorentzVector*>* vector;

could become a vector of unique pointers (to allow forward declaration of the TLorentzVector class) or a vector of TLorentzVector objects:

// Doesn't need explicit TLorentzVector include, only forward declaration
std::vector<std::unique_ptr<TLorentzVector>> vector;
// Needs explicit TLorentzVector include
std::vector<TLorentzVector> vector;

Context

Removing raw pointers as much as possible from the code would improve overall readability, because new and delete keywords could be avoided. We could also avoid using double pointers in various contexts. Overall, ownership of objects would be a lot clearer, and there would be less reason to worry about memory management.

Wrong Energy Resolution Formula in ResGaussE

The formula for the energy resolution, which was extracted from the Delphes detector card for the Snowmass detector, has a wrong implementation in KLFitter.

Description

The formula in the Snowmass detector card is of the following form:

sigma = sqrt(a^2 * E^2 + b^2 * E + c^2)

but it is implemented with the same parameters in the following form:

sigma = a * E + b * sqrt(E) + c

The difference is not negligible (example for jet resolution for |eta| in [0, 1.7])

Affected file:
https://github.com/KLFitter/KLFitter/blob/master/src/ResGaussE.cxx
Only used by:
https://github.com/KLFitter/KLFitter/blob/master/src/DetectorSnowmass.cxx
(in this repository, could be used in other projects using KLFitter)

Expected Behavior

The formula should be

sigma = sqrt(a^2 * E^2 + b^2 * E + c^2)

as in the delphes detector card from HepSim for the Snowmass detector:
http://atlaswww.hep.anl.gov/hepsim/soft/detectors/delphes_dpf1/card.tcl
resolution formula on lines 289-292

Actual Behavior

Implemented in KLFitter/ResGaussE:

sigma = a * E + b * sqrt(E) + c

KLFitter/src/ResGaussE.cxx

Lines 42 to 44 in 373a4fe

	double KLFitter::ResGaussE::GetSigma(double x) {
	return fParameters[0]*x + fParameters[1]*sqrt(x) + fParameters[2];
	}

Possible Fix

Suggested fix: Change formula implemented in KLFitter/ResGaussE #47

Alternative: Fit parameters of implemented function to original function. This would have to be done for jets and electrons in 3 eta bins each.
Works in principle (fitted function in orange):

Steps to Reproduce

Reproducible with example-top-ljets.cxx or test-ljets-lh.cxx

Context

Your Environment

• KLFitter version used: 1.1.0

Adjust requirements for transfer function parameterisations

Description

I'll use this issue to summarise a set of problems that arises with the current handling of transfer function parameters and detector implementations within the KLFitter package. Some of these are already mentioned in #36 and #37, but for a better discussion, we should continue with this ticket.

We essentially have three levels of dependencies:

1. Parameters provided by the TF parameter set. Naturally, only if parameterisations for a specific object type are available in the TF parameter set, it can be used in a likelihood fit.
2. What's supported by the detector class. Only if the detector has an existing parameterisation for an object type, it can be used in a likelihood, i.e. the detector class needs to explicitly pick up the parameters from the TF parameter set, and know how to handle them.
3. What's needed by the likelihood class to function.

At the moment, (1) and (2) are required to be identical, which is maybe not the way to go. In the end, I think (3) should be the baseline, while (1) and (2) can always provide more than necessary (not less, of course), and also (1) and (2) don't have to match each other. So I would suggest to:

not issue warnings by the detectors, if not all of their supported resolution functions have parameters,
and instead have the likelihoods do the check whether the detector supports everything they need, and whether the TF set provides parameters for that.
Those will require quite a lot of changes, but in the end would be a much more consistent setup, that avoids unnecessary warnings, but issues errors if something is missing. What do you think?

Expected Behavior

The expected behaviour would be that the likelihood defines the baseline: any object type/parameterisation that is used in the likelihood calculation, must be provided for the likelihood to function. For example, if the likelihood includes photons, we must have a detector implementation with a parameterisation of photon transfer functions, and the TF parameter set must include the appropriate parameters for them. Of course the detector implementation may provide more than what is needed for the likelihood, and the TF parameter set may contain more parameters than the needed ones.
Long story short: the code should fail (and should only fail) if the likelihood requires something that is either not implemented in the detector class, or does not have parameters in the TF parameter set. If TF parameter set and detector implementation don't match, e.g. the detector supports photons, but the TF parameter does not include photons, no warnings/errors should be raised, unless the likelihood needs that information.

Actual Behavior

At the moment, (1) and (2) are required to be identical, i.e. the detector class raises warnings when not all parameters are provided by the TF parameter set. Also, if the detector class does not overwrite the base class implementation of a resolution function, e.g. of photons, no error/warning is raised.

Possible Fix

We need to add explicit checks in the detector classes, if certain methods are (dummy) base class implementations or if they were reimplemented in a derived class. We also need checks for the TF parameters, but only if the corresponding resolution functions are actually being called, not when the detector class is initialised.

Context

Users are confused by warnings issued by the detector classes, when parameter sets do not contain parameterisations for certain particle types. Those combinations should be possible without raising warning/errors, as long as the likelihood doesn't need that information.

Your Environment

• KLFitter version used: v1.1.0
• BAT version used: 0.9.4.1
• ROOT version used: 6.10/04