Research software engineer, HPC · Paris-Saclay · engineering degree 2026 · available from January 2027

I build research software that measures what scientific computing costs.

Energy-measurement tooling for Kokkos, built at Oak Ridge National Laboratory, and three years of performance tooling for a nuclear reactor simulation code at EDF.

GitHub LinkedIn ORCID Google Scholar CV (PDF)

One run of each ArborX DBSCAN implementation on an NVIDIA H100 NVL, same result. The shaded area is the energy of the DBSCAN computation. Over 64 runs each, the dense one takes 19% less time and 25% less energy (medians). How it was measured

Work

Oak Ridge National Laboratory · CSEDGraduate Research Fellow (GRO program) · Summer 2025

Measuring where the energy goes on the GPU

Energy-measurement tooling for Kokkos, the C++ performance-portability library behind many US Department of Energy codes. I wrote a power-sampling profiler for Kokkos Tools, with NVML and Variorum back ends, whose sampling daemon is merged upstream, and energy-dashboard-for-kokkos, the open-source analysis tool I rewrote in September 2026.

The problem

Kokkos runs one C++ source on NVIDIA, AMD, and Intel GPUs, and the same kernel draws different power on each. Kokkos Tools could only estimate a kernel’s energy from two power readings, at its start and end, which NVML’s 100 ms refresh makes unreliable; nothing integrated a continuous power trace per region, on DOE machines where power is now a first-class constraint.

How it is built

The tools attach at run time through Kokkos Tools, so an application is measured without a rebuild or a patch. The connectors I submitted upstream (#301, #302) read power through NVML or Variorum; an AMD path through ROCm SMI, not public yet, is the version I ran on Frontier. energy-dashboard-for-kokkos, rewritten in Rust in September 2026, has a documented trace format, tests on a real GPU trace, and CI-built releases archived on Zenodo with a DOI. The traces and script behind the DBSCAN figures are public, and CI recomputes them.

Where it stands

The rest of the profiler is three open pull requests I wrote: the core and timing export (#299), the NVML connector (#301, with changes requested), and the Variorum connector (#302, a draft of about 2,700 lines that includes unit tests). Its sampling daemon (#300) was merged into kokkos-tools in March 2026, after my ORNL mentor, Jakob Bludau, reworked it through review once my stay had ended. Nine pull requests to kokkos-tools and LAMMPS in all, some later split into smaller ones; three merged: the daemon and two build fixes. One poster, with Daniel Arndt, Jakob Bludau and Damien Lebrun-Grandié, presented at SMC 2025 and at an ORNL internal session, and cited in the S4PST 2024–2025 project report.

Stack C++ · Kokkos · CUDA · NVML · ROCm SMI · Variorum · Slurm · Rust

EDF Lab Paris-Saclay · ASICS groupApprentice engineer · 2023 to 2026

Making a nuclear simulation code measurable

A three-year apprenticeship on COCAGNE, EDF’s reactor-core simulation platform of more than 500,000 lines of C++: the tools that measure its performance, a prototype of its next architecture, and the pipeline that packages it.

The context

EDF’s ASICS group develops the scientific computing behind nuclear simulation. I worked inside the team that develops the platform: weekly group meetings, code reviews given and received through GitLab merge requests, five internal technical notes, and support for the tools' users; the memory profiler pinned down a memory blow-up the team had been chasing for days.

What I built

Two C++ performance-analysis tools: a memory profiler that intercepts allocation through LD_PRELOAD, and a hierarchical timer with Python bindings (PyBind11) that loads at run time, so production builds stay untouched. With them I benchmarked the prototype I developed for a new modular architecture of the core computation (Ports and Components); the three figures in this section are its results. I also built the Debian packaging pipeline on GitLab CI/CD and Jenkins, and documented the tools in Sphinx so the team can keep using them.

The work above is cleared for public mention; the rest stays under confidentiality.

Stack C++17 · Python · PyBind11 · CMake · GitLab CI/CD · Jenkins · Sphinx

identical results to the reference: bit for bit
compute time, best case: −12%
peak memory: −38%

Writing

Write-ups on HPC, GPU computing, infrastructure, and the projects behind them.

Read all posts

Background

Ethan PuyaubreauParis-Saclay, France

I write research software for high-performance computing: tools that make scientific codes measurable, and the engineering around them (tests, packaging, CI/CD, releases, documentation) that lets other people rely on them. I graduated from Polytech Paris-Saclay in September 2026 with an engineering degree, equivalent to an M.Eng., and I am looking for a research software engineer role from January 2027, at a national lab, a university, or a research institute, in the US or in France.

Languages: C++17 daily, Python (NumPy, pandas) for analysis and bindings, Rust, CUDA. Build, test and delivery: CMake, GitLab CI/CD, GitHub Actions, Jenkins, Debian packaging, Sphinx. Batch jobs with Slurm, on Frontier and at EDF. English: professional working language (TOEIC 970/990); French native.

Contact

Open to research software engineer roles from January 2027

HPC and scientific computing, at a national lab, a university, or a research institute, in the US or in France. For US roles I need visa sponsorship (J-1 or H-1B).

ethan.puyaubreau@gmail.com