Editorial spotlight

Paul Romano.

Computational scientist at Argonne National Laboratory; project lead of OpenMC; curator of Awesome Nuclear

Computational Scientist, Argonne National Laboratory (source)

The email button opens your own mail client with no pre-filled text. The address is promano@anl.gov, published by an official page and rechecked on 2026-10-10. Published by Argonne as the contact address for the 2025 OpenMC tokamak neutronics meeting he organised, listed as his corresponding-author address on a 2024 EPJ Nuclear Sciences & Technologies article, and set as the public email on his GitHub account. Contacting a researcher is a courtesy, not a Morton Labs service, and no reply is promised. For help with a piece of software, use the project's own support channel on its library entry.

Monte Carlo particle transportFusion and fission neutronicsNuclear dataHigh-performance computingSimulation workflows
About

Paul Romano describes himself as a computational scientist at Argonne National Laboratory working on nuclear energy applications, Monte Carlo particle transport and high-performance computing. He is the project lead of OpenMC, the open-source Monte Carlo transport code that began at MIT in 2011, and he curates Awesome Nuclear, a widely used list of open-source projects in nuclear science and engineering.

His recent public work centres on fusion neutronics with OpenMC: shutdown dose rate methods, conversion and analysis of tokamak models, and the 2025 OpenMC tokamak neutronics meeting at Argonne that he organised with colleagues from ENEA and EUROfusion.

He is first author of the WATTS workflow toolkit paper and the author of endf-python, a reader for ENDF-6 and ACE nuclear data files. He holds a PhD in nuclear science and engineering from MIT.

Contributions, with evidence
Awesome NuclearCuratorCurrent · 2019–

The list lives under his GitHub account and he authored 74 of its commits; ten other accounts contributed between one and seven changes each. The README carries no explicit curator line, so the credit rests on ownership and history.

Evidence: github.com · checked 2026-10-10
CardinalCore developerCurrent

Listed among the current Cardinal development team on the project's contact page, which does not assign individual titles.

Evidence: cardinal.cels.anl.gov · checked 2026-10-10
endf-pythonOriginal authorHistorical · 2023–

Sole author named in the package metadata; the licence file carries his copyright for 2023–2025.

Evidence: github.com · checked 2026-10-10
endf-pythonMaintainerCurrent

Repository owner; published the latest release (v0.1.12, February 2026) and almost all commits.

Evidence: github.com · checked 2026-10-10
OpenMCOriginal authorHistorical · 2011–

OpenMC was begun at the MIT Computational Reactor Physics Group in 2011; he is first author of the recommended 2015 citation and the first listed software author in the repository's CITATION.cff.

Evidence: docs.openmc.org · checked 2026-10-10
OpenMCProject leadCurrent

The OpenMC developer guide names him Project Lead and a Technical Committee member. He also published every OpenMC release from v0.15.0 (2024) to v0.16.0 (August 2026).

Evidence: docs.openmc.org · checked 2026-10-10
WATTSAuthorHistorical · 2022–

First and corresponding author of the 2022 Journal of Open Source Software paper describing WATTS.

Evidence: joss.theoj.org · checked 2026-10-10
WATTSMaintainerCurrent

Inferred from activity rather than a stated title: top committer, publisher of the v0.5.2 release (April 2025) and the account that merged the most recent change (July 2026). No official page names a maintainer.

Evidence: github.com · checked 2026-10-10

Each card names one relationship: author, maintainer, project lead, curator or contributor, and whether it is current or historical. A paper byline or a GitHub pin alone never becomes a current maintainer claim.

Selected publications and talks
In the Simulation Library
Multiphysics · Particle transport · CFD & heat transfer

Cardinal

Cardinal is an open-source MOOSE application that embeds the GPU spectral-element CFD code nekRS and the Monte Carlo code OpenMC inside the MOOSE framework, so they exchange temperatures, densities, heat fluxes and tallied power with MOOSE and other MOOSE-based solvers through in-memory transfers rather than files. It targets high-resolution coupling on CSG or CAD geometry for fission and fusion component analysis.

What is the coupled neutronics–thermal steady state of a component when Monte Carlo transport is iterated with heat conduction or CFD?

Upstream exampleHub integration planned
Nuclear data

endf-python

endf-python, published on PyPI as `endf`, is a Python library with a compiled extension that opens ENDF-6 evaluated nuclear data files and ACE continuous-energy tables and exposes their contents as Python objects. It offers a raw view of the MF/MT sections in a material and an interpreted incident-neutron view in which reactions, cross sections, Q-values and emitted products can be queried, interpolated and plotted.

What is the cross section for a specific reaction on a nuclide at a given energy in a particular evaluated library?

ListedReference listing
Particle transport · Nuclear data · Activation & inventory

OpenMC

OpenMC is an open-source Monte Carlo code that tracks neutrons and photons through models built from constructive solid geometry or CAD (through DAGMC), using continuous-energy or multigroup nuclear data, in fixed-source, eigenvalue and subcritical modes with MPI and OpenMP parallelism. Its Python API drives model building, depletion and activation workflows (including R2S and D1S shutdown dose rate), nuclear-data processing and tally analysis.

What neutron flux, nuclear heating, tritium breeding ratio or damage-driving reaction rates does a blanket, divertor or shield see for a given fusion source?

Morton reproducedRuns in the Hub
Workflow & orchestration

WATTS

WATTS (Workflow and Template Toolkit for Simulation) is a small MIT-licensed Python library from Argonne for driving simulation codes from a script: it fills Jinja placeholders in a code's text input from a parameters mapping, runs the code in an isolated temporary directory, and files inputs, outputs and parameters into a local results database. Code-specific plugins add unit conversion and light post-processing.

How does a result change when sweeping a geometry or material parameter across many runs without hand-editing input files?

ListedReference listing
Collections
Related reference workflows

Editorial profile. Written by Morton Labs from public sources on 2026-10-10. Paul Romano has not reviewed this profile and has no relationship with Morton Labs. Last checked 2026-10-10. Nothing here implies endorsement of Morton Labs or its implementations. To request a correction, an update or removal, email zach@mortonlabs.ai with this page's address; we aim to act on removal requests promptly.

Sources checked for this page (11)