PyPulseq-Star: relationship-aware, multi-backend sequence programming from a PyPulseq-style workflow

[sairamgeethanath]

Hi everyone,

I wanted to share something I have been working on over the past few months that grew directly out of our experience developing and using PyPulseq.

One challenge we kept running into is that writing an open-source sequence and exporting a .seq file is only part of the path toward making it practical on the scanner. In a real experiment, we still need to change things such as FOV position and orientation, TE/TR, resolution, echo-train parameters, averages, and other protocol settings—ideally without manually rebuilding the sequence or losing the relationships that define how those parameters affect RF, gradients, ADCs, delays, and timing.

I got around to developing PyPulseq-Star, an experimental extension of the familiar PyPulseq-style programming workflow that retains protocol parameters, symbolic dependencies, sequence hierarchy, and explicit relationships through the sequence-development process.

Repository:
https://github.com/imr-framework/pypulseq-star

A key goal was to avoid forcing the sequence programmer to choose an execution representation at the beginning of development. The same source-level sequence definition can currently generate:

• a conventional Pulseq .seq file with resolved numerical events and timing; and
• a gammaSTAR .seq.json representation that can retain hierarchy, loops, protocol-facing controls, and live dependencies where supported.

So the basic idea is:

PyPulseq-style source → protocol + relationships → multiple execution representations

For example, rather than calculating TE-dependent delays once and losing that dependency (or intrdoducing soft delays that may be tricky) when the sequence is constructed, the protocol can retain the relationship between TE, RF timing, ADC timing, and the relevant fill delay until the sequence is explicitly resolved or exported.

The first publication-oriented alpha release, v0.2.0a1, includes four reference sequence workflows:

• FID
• spoiled GRE
• EPI
• TSE

I have used these to exercise changes in parameters including timing, FOV/phase encoding, orientation, ETL, RF behavior, and other sequence-specific controls while checking consistency between the local representation and the two output paths. The first PyPulseq-Star software manuscript was submitted to SoftwareX. The next step for us is practical scanner validation across Siemens, Philips, and GE, including testing how these protocol-level changes translate through different available execution backends.

I would especially value feedback from the PyPulseq developer/user community on three things:

1. Are there sequence parameters or relationships that are particularly painful to change once you get to the scanner?
2. Are there existing PyPulseq sequences that would make good stress tests for this relationship-aware model?
3. Does the separation between a common source-level protocol and backend-specific .seq / .seq.json realization seem useful for your workflows?

This is still research software, and generated sequences of course require independent timing, safety, and scanner validation. Our intention is to augment PyPulseq or Pulseq, and to explore how the familiar PyPulseq programming model can evolve toward more practical, editable, and multi-backend scanner workflows.

Comments, criticism, examples, and contributions would all be very welcome.

Sairam