↓Skip to main content
  1. Latest News/

Eradiate Release: v1.1.0

·4 mins

We just released Eradiate v1.1.0! This is the result of 6 months of development, during which we reduced the technical debt induced by our dependency tree. We tried our best to:

  • Rely on mature packages so we can be certain that the integrations we design last long.
  • Minimize the scope of our dependencies to avoid including lots of unused code in the user’s environment.
  • Increase our Python version coverage to allow users to deploy Eradiate in as many different environments as possible.

Cleaning up our dependency tree #

To support NumPy 2, we had to make sure that our code, and all our dependencies, were compatible with its API. The main problem was that we started having issues locking our development environment because our dependencies had contradicting NumPy and Python version requirements: while this issue was affecting only the development team, it was also a sign that something in our dependency management was wrong.

We therefore worked on cleaning up our list of requirements, in which several packages had their versions capped due to critical regressions or locking issues. We notably:

  • Replaced Astropy with Skyfield for astronomical calculations. Skyfield’s scope is much narrower (we do not need Astropy’s astrophysics features), its maintenance status is good, and its Python coverage is broad, which means that it brings very little constraint to the user’s environment.
  • Added support for recent xarray versions (2025 and later). This required working around a critical regression introduced in xarray 2025.1.0 (see below).
  • Updated our kernel to Mitsuba v3.7.1 to add support of Python 3.13.
  • Moved away from the Hamilton library to replace its pipeline framework with an in-house solution that is better scoped to our use case. This also eliminated a source of constraint in our dependency tree, as we had to work around a regression to make sure our postprocessing pipelines would keep working after some advanced features were refactored.

With that done, we could safely upgrade our development environment to Python 3.10 and NumPy 2, and therefore guarantee that users could do so as well.

Upgrading the kernel to Mitsuba v3.7.1 #

Our kernel was based on Mitsuba 3.5.2, and upstream Mitsuba had received two major updates that brought several performance-critical updates. We rebased our fork onto this version to, in particular, take advantage of the refactored scene loading components, essential to minimize the initialization of very large scenes.

Several breaking changes had been introduced in the upstream codebase, some of which (noncritical) could not be worked around entirely. We are however very pleased to upgrade to this version, which also allowed us to easily support Python 3.13.

Making our absorption database interpolation fast #

As mentioned earlier, xarray 2025+ introduced a performance regression that slowed down Eradiate by several orders of magnitude. We decided to externalize the absorption database management components to a new project, named AxsDB. AxsDB allows reading Eradiate’s absorption database format without depending on Eradiate. As part of this change, we wrote high-performance logic using Numba to restore — and even improve — the performance of our absorption database interpolation. A side effect on our dependency tree is that we now depend on Numba: this is a trade-off we decided to be acceptable compared to having to maintain compiled binaries to implement the low-level components we needed to reach the performance we were targeting.

We were impressed by the performance gains we achieved, with at least a speedup of ×2.5 on lookups in the absorption database. With this issue solved, we could support xarray 2025.1.0 and later.

New features #

This release was not only about technical debt and performance! We also added the following features:

  • Few land surface reflection models describe how surfaces interact with polarized light, so we added a polarized surface reflection model based on the work of Maignan et al. (2009).
  • Support for surface response function data in the Eradiate workflow was incomplete, so we made some changes to the BandSRF interface to allow constructing Gaussian SRFs easily and retrieving the band’s central wavelength. The output data now also includes the band central wavelength as a scalar coordinate, when available.

We hope you will enjoy this release which makes Eradiate ready for the future! For more information, see the full release notes.