ROOT Version 6.40 Release Notes

2026-5

Introduction

For more information, see:

http://root.cern

The following people have contributed to this new version:

Bertrand Bellenot, CERN/EP-SFT,
Jakob Blomer, CERN/EP-SFT,
Lukas Breitwieser, CERN/EP-SFT,
Philippe Canal, FNAL,
Olivier Couet, CERN/EP-SFT,
Marta Czurylo, CERN/EP-SFT,
Florine de Geus, CERN/EP-SFT and University of Twente,
Andrei Gheata, CERN/EP-SFT,
Jonas Hahnfeld, CERN/EP-SFT and Goethe University Frankfurt,
Fernando Hueso Gonzalez, IFIC (CSIC-University of Valencia),
Stephan Hageboeck, CERN/EP-SFT,
Aaron Jomy, CERN/EP-SFT,
David Lange, CERN and Princeton,
Sergey Linev, GSI Darmstadt,
Lorenzo Moneta, CERN/EP-SFT,
Vincenzo Eduardo Padulano, CERN/EP-SFT,
Giacomo Parolini, CERN/EP-SFT,
Danilo Piparo, CERN/EP-SFT,
Jonas Rembser, CERN/EP-SFT,
Silia Taider, CERN/EP-SFT,
Devajith Valaparambil Sreeramaswamy, CERN/EP-SFT,
Vassil Vassilev, Princeton,
Sandro Wenzel, CERN/EP-ALICE,
Ned Ganchovski, Proektsoft EOOD,

Deprecations

Removals

Build System

Moving from builtin dependencies to system-provided packages

Core Libraries

// Print the list
gInterpreter->Print("autoparsed");
// Get the list/set:
((TCling*)gInterpreter)->GetAutoParseClasses();

Geometry

Extensible color schemes for geometry visualization

ROOT now provides an extensible mechanism to assign colors and transparency to geometry volumes via the new TGeoColorScheme strategy class, used by TGeoManager::DefaultColors().

This improves the readability of geometries imported from formats such as GDML that do not store volume colors. The default behavior now uses a name-based material classification (e.g. metals, polymers, composites, gases) with a Z-binned fallback. Three predefined color sets are provided: * EGeoColorSet::kNatural (default): material-inspired colors * EGeoColorSet::kFlashy: high-contrast, presentation-friendly colors * EGeoColorSet::kHighContrast: darker, saturated colors suited for light backgrounds

Users can customize the behavior at runtime by providing hooks (std::function) to override the computed color, transparency, and/or the Z-based fallback mapping.

Usage examples:

gGeoManager->DefaultColors(); // default (natural) scheme

TGeoColorScheme cs(EGeoColorSet::kFlashy);
gGeoManager->DefaultColors(&cs); // select a predefined scheme

Override examples (hooks):

TGeoColorScheme cs(EGeoColorSet::kNatural);
cs.SetZFallbackHook([](Int_t Z, EGeoColorSet) -> Int_t {
   float g = std::min(1.f, Z / 100.f);
   return TColor::GetColor(g, g, g); // grayscale fallback
});
gGeoManager->DefaultColors(&cs);

A new tutorial macro demonstrates the feature and customization options: tutorials/visualization/geom/geomColors.C.

See: https://github.com/root-project/root/pull/21047 for more details

Accelerated overlap checking with parallel execution

The geometry overlap checker (TGeoChecker::CheckOverlaps) has been significantly refactored and optimized to improve performance and scalability on large detector geometries.

Overlap checking is now structured in three explicit stages:

  1. Candidate discovery Potentially overlapping volume pairs are identified using oriented bounding-box (OBB) tests, drastically reducing the number of candidates to be examined.

  2. Surface point generation and caching Points are generated on the surfaces of the candidate shapes (including additional points on edges and generators) and cached per shape. The sampling density can be tuned via:

  1. Overlap and extrusion checks The actual geometric checks are performed using navigation queries. This stage is now parallelized and automatically uses ROOT’s implicit multithreading when enabled.

Only the final stage is currently parallelized, but it dominates the runtime for complex geometries and shows good strong scaling.

For large assembly-rich detector descriptions such as the ALICE O² geometry, the new candidate filtering reduces the number of overlap candidates by roughly three orders of magnitude compared to the legacy implementation. Combined with multithreaded execution, this reduces the total runtime of a full overlap check from hours to minutes on modern multi-core systems.

Usage example

ROOT::EnableImplicitMT();        // enable parallel checking
gGeoManager->SetNsegments(40);  // increase surface resolution if needed
gGeoManager0->SetNmeshPoints(2000); // increase resolution of points on surface-embedded segments if needed
gGeoManager->CheckOverlaps(1.e-6);

Performance and scaling plots for the CMS Run4 and ALICE aligned geometry are included in the corresponding pull request.

See: https://github.com/root-project/root/pull/20963 for implementation details and benchmarks

I/O

ROOT now respects the system umask when creating files, following standard Unix conventions.

Previous behavior: Files were created with hardcoded 0644 permissions (owner read/write, group/others read-only), ignoring the system umask.

New behavior: Files are created with 0666 permissions masked by the system umask (0666 & ~umask), consistent with standard Unix file creation functions like open() and fopen().

Impact: - Users with default umask 022 (most common): No change - files are still created as 0644 - Users with stricter umask values (e.g., 0077): Files will now be created with more restrictive permissions (e.g., 0600 - user-only access) - Users with permissive umask values (e.g., 0002): Files may be created with slightly more open permissions (e.g., 0664 - group-writable)

Note: If you require specific file permissions regardless of umask, you can set umask explicitly before running ROOT (e.g., umask 022) or use chmod after file creation.

This change affects the following classes: TFile, TMapFile, TMemFile, TDCacheFile, TFTP, and TApplicationServer.

TTree

RNTuple

Math

Migration from VecCore/Vc to std::experimental::simd for Vectorization

We have migrated the vectorized backends of TMath and TFormula from VecCore/Vc to std::experimental::simd, where available.

On Linux, std::experimental::simd is assumed to be available when ROOT is compiled with C++20 or later, which in practice corresponds to sufficiently recent GCC and Clang compilers. To keep the build system simple and robust, ROOT does not explicitly check compiler versions: users opting into C++20 are expected to use modern toolchains.

Impact on Linux users

ROOT builds with C++17 on Linux no longer provide vectorized TMath and TFormula. This is an intentional and accepted trade-off of the migration. These vectorized features were rarely used, while maintaining them significantly complicated the codebase and build configuration.

Users who rely on vectorized TMath or the vectorized TFormula backend are encouraged to build ROOT with C++20. Doing so restores vectorization through std::experimental::simd, providing a more robust and future-proof implementation.

Windows and Apple silicon users are unaffected

VecCore/Vc did not work on Windows previously, and Vc never provided production-ready support for ARM/Neon, so Apple silicon did not benefit from vectorization before this change.

Build system changes

As part of this migration, the following build options are deprecated. From ROOT 6.42, setting them will result in configuration errors.

Added Modified Anderson-Bjork (ModAB) root-finding algorithm

This is new and efficient bracketing root-finding algorithm. It combines bisection with Anderson-Bjork’s method to achieve superlinear convergence (e.i. = 1.7-1.8), while preserving worst-case optimality. According to the benchmarks, it outperforms classical algorithms like ITP, Brent and Ridders. It is implemented as the ROOT::Math::ModABRootFinder class.

RooFit

New implementation of RooHistError::getPoissonInterval

RooHistError::getPoissonInterval was reimplemented to use an exact chi-square–based construction (Garwood interval) instead of asymptotic approximations and lookup tables.

Previously:

Now:

Results may differ from previous ROOT versions for n > 100 or nSigma != 1. The new implementation is statistically consistent and recommended.

Removal of global expensive object caching in RooFit

The global “expensive object cache” used in RooFit to store numeric integrals and intermediate histogram results has been removed.

While originally intended as a performance optimization, this mechanism could lead to incorrect results due to cache collisions: cached integrals or histograms created in one context (e.g. during plotting) could be reused unintentionally in a different context, even when the underlying configuration had changed.

Given the risk of silently incorrect physics results, and the absence of known workflows that depend critically on this feature, this global caching mechanism has been removed. If you encounter performance regressions in workflows involving expensive integrals or convolutions, we encourage you to report your use case and performance regression as a GitHub issue, so that targeted and robust optimizations can be developed,

RDataFrame

Python Interface

Change in memory ownership heuristics

In previous ROOT versions, if a C++ member function took a non-const raw pointer, e.g.

MyClass::add(T* obj)

then calling this method from Python on an instance

my_instance.add(obj)

would assume that ownership of obj is transferred to my_instance.

In practice, many such functions do not actually take ownership. As a result, this heuristic caused several memory leaks.

Starting with ROOT 6.40, the ROOT Python interfaces no longer assumes ownership transfer for non-const raw pointer arguments.

What does this mean for you?

Because Python no longer automatically relinquishes ownership, some code that previously relied on the old heuristic may now expose:

These issues must now be fixed by managing object lifetimes explicitly.

Dangling references

A dangling reference occurs when C++ holds a pointer or reference to an object that has already been deleted on the Python side.

Example

obj = ROOT.MyClass()
my_instance.foo(obj)
del obj  # C++ may still hold a pointer: dangling reference

When the Python object is deleted, the memory associated with the C++ object is also freed. But the C++ side may want to delete the object as well, for instance if the destructor of the class of my_instance also calls delete obj.

Possible remedies

  1. Keep the Python object alive

    Assign the object to a Python variable that lives at least as long as the C++ reference.

    Example: Python lifeline

    obj = ROOT.MyClass()
my_instance.foo(obj)
# Setting `obj` as an attribute of `my_instance` makes sure that it's not
# garbage collected before `my_instance` is deleted:
my_instance._owned_obj = obj
del obj  # Reference counter for `obj` doesn't hit zero here

    Setting the lifeline reference could also be done in a user-side Pythonization of MyClass::foo.

  2. Transfer ownership explicitly to C++

  3. Rely on Pythonizations that imply ownership transfer

    If the object is stored in a non-owning collection such as a default-constructed TCollection (e.g. TList), you can make the collection owning before adding any elements:

    coll.SetOwner(True)

    This will imply ownership transfer to the C++ side when adding elements with TCollection::Add().

Note on TCollection Pythonization

TCollection-derived classes are Pythonized such that when an object is added to an owning collection via TCollection::Add(), Python ownership is automatically dropped.

If you identify other cases where such a Pythonization would be beneficial, please report them via a GitHub issue. Users can also implement custom Pythonizations outside ROOT if needed.

Double deletes

A double delete indicates that C++ already owns the object, but Python still attempts to delete it.

In this case, you do not need to ensure C++ ownership, as it already exists. Instead, ensure that Python does not delete the object.

Possible remedies

  1. Drop Python ownership explicitly: Python ROOT.SetOwnership(obj, False)

  2. Pythonize the relevant member function to automatically drop ownership on the Python side (similar to the TCollection Pythonization described above).

Temporary compatibility option

You can temporarily restore the old heuristic by calling:

ROOT.SetHeuristicMemoryPolicy(True)

after importing ROOT.

This option is intended for debugging only and will be removed in ROOT 6.44.

Drop support for calling C++ functions with non-const pointer references

From now on, we disallow calling C++ functions with non-const pointer references (T*&) from Python. These allow pointer rebinding, which cannot be represented safely in Python and could previously lead to confusing behavior. A TypeError is now raised. Typical ROOT usage is unaffected.

In the rare case where you want to call such a function, please change the C++ interface or - if the interface is outside your control - write a wrapper function that avoids non-const pointer references as arguments.

For example, a function with the signature bool setPtr(MyClass *&) could be wrapped by a function that augments the return value with the updated pointer:

ROOT.gInterpreter.Declare("""
    std::pair<bool, MyClass*> setPtrWrapper(MyClass *ptr) {
       bool out = setPtr(ptr);
       return {out, ptr};
    }
""")

Then, call it from Python as follows:

# Use tuple unpacking for convenience
_, ptr = cppyy.gbl.setPtrWrapper(ptr)

UHI

Backwards incompatible changes

h.values(writable=True)[0] = 42

New features

h = ROOT.TH1D("h", "h", 10, -5, 5)
h[...] = np.arange(10)

json_str = json.dumps(h, default=uhi.io.json.default)

h_from_uhi = ROOT.TH1D(json.loads(json_str, , object_hook=uhi.io.json.object_hook))

Removed TCollection.count() Pythonization

The Python-only TCollection.count() method has been removed. The meaning of the underlying comparison was ambiguous for C++ objects: depending on the element class, it might have counted by matching by value equality or pointer equality. This behavior can vary silently between classes and lead to inconsistent or misleading results, so it was safer to remove the count() method.

Users who need to count occurrences in a TCollection can explicitly implement the desired comparison logic in Python, for example:

sum(1 for x in collection if x is obj)   # pointer comparison
sum(1 for x in collection if x == obj)   # value comparison (if defined for the element C++ class)

ROOT executable

Command-line utilities

JavaScript ROOT

Experimental features

Versions of built-in packages

The version of the following packages has been updated:

Items addressed for this release