pythontps

How a researcher uses it

1. Load a case.Import CT and RTSTRUCT data, or start with a committed open phantom such as TG-119.
2. Define the planning problem.Select targets, organs, prescription, beam geometry, and measurable dose objectives.
3. Optimize and inspect.Run fluence optimization, compare DVHs, and navigate trade-offs rather than accepting a single opaque answer.
4. Make it deliverable.Sequence fluence into MLC apertures and check leaf, gantry, MU, and timing rules on the virtual machine.
5. Challenge the result.Recalculate with an independent Monte Carlo experiment and export research DICOM objects for inspection.

The question

Can the important pieces of a radiotherapy treatment-planning system be reproduced in a form that a researcher can read, rerun, challenge, and extend—not merely view through a vendor interface?

What I built

The stack imports CT and RTSTRUCT data, optimizes fluence with pyRadPlan, explores multi-criteria trade-offs, converts fluence into MLC apertures, checks machine rules on a virtual linac, and exports research RTPLAN and RTDOSE objects. Separate CPU and CUDA experiments model photon/electron transport and proton and carbon Bragg peaks.

Reproducible evidence

Committed scripts cover water-phantom buildup and PDD, proton and carbon range, HU-to-stopping-power calibration, TG-119 optimization, VMAT aperture experiments, breast-cohort comparisons, and a TOPAS cross-check. The purpose is not to claim clinical equivalence; it is to expose exactly which result came from which model and script.

The boundary matters

This is research software, not a medical device or a clinical TPS. The dose grid and several physics models remain simplified; the virtual machines have not been commissioned against a physical linac; measured profiles, end-to-end patient QA, carbon fragmentation, and biological weighting remain outside the validated scope.