Synopsis

On the example of PulSeq, an open-source platform independent sequence programming framework, we consider advantages of the hardware-abstraction in pulse sequence programming as well as the associated challenges.

INTRODUCTION

Implementing new MR sequences often involves extensive programming on vendor-specific platforms, which can be time-consuming and costly. Even more so if research sequences need to be implemented on several platforms simultaneously, for example, at different field strengths or in heterogeneous hardware environments. We have recently presented an alternative programming environment [1] that is hardware-independent, open-source, and promotes rapid sequence prototyping. The core of our approach is the file format which allows for the efficient description of hardware events and timing information required for an MR pulse sequence. Platform-dependent interpreter modules convert this file to appropriate instructions to run the sequence on MR hardware. The design of sequences is done in high-level programming languages such as MATLAB (The Mathworks, Natick, MA), Python or with a graphical interface (i.e. JEMRIS [2] or GPI [3]).

PulSeq is a highly-flexible pulse sequence programming environment, which allows for a decoupling between the sequence design (hardware independent) and the sequence execution (hardware dependent) steps. Furthermore, a close link to JEMRIS can be used to simulate spin physics, allowing for comparison between real and virtual experiments. However, being truly platform-agnostic presents a number of substantial challenges, especially if optimal performance needs to be achieved.

METHODS

Based on our experience with the PulSeq approach we discuss advantages and challenges of hardware abstraction in MR pulse sequence development.

The main components of the PulSeq environment are illustrated in Fig. 1. The high-level sequence can be described directly in MATLAB or Python using functions from a custom toolbox. Alternatively, sequences can be programmed using the graphical interface of the JEMRIS simulation packages or the GPI toolbox. Regardless of the choice of high-level interface, a sequence file is created containing low-level sequence instructions such as RF pulses, gradients, ADC events and delays. This sequence file can then be executed on various platforms through hardware-dependent interpreter modules.

A complete developer framework is presented in Fig. 2. In addition to the design tool, PulSeq file and the scanner-specific interpreter module, it also shows relations between the various data handling components, which all together allow for the integrated image reconstruction. An essential element of the chain is the transfer of the encoding trajectory to the image reconstruction server, which needs to be solved for future fully open-source implementations of the framework.

RESULTS AND DISCUSSION

Up to now, PulSeq is fully supported on Siemens and GE platforms. A prototype implementation of the interpreter module is available for Bruker and is being extended to remove some of the current limitations.

Our experience shows that a number of compromises required for the PulSeq format to achieve hardware independence also present a challenge during the sequence execution. For instance, PulSeq avoids loops and represents its event table as a plain list of events. This was needed due to a great variability on exact details how the loops are implemented on various platforms. However, it also represents a challenge, because the exceedingly large PulSeq files that are generated for some sequences, e.g. for 3D imaging. Another known challenge is the implementation of the time-optimized gradient shapes. For the sake of portability PulSeq separates the sequence timing series non-overlapping blocks. This is a limitation if for instance a temporal overlap of the read-out gradient ramping up and the slice refocusing gradient is required.

Despite of the present challenges PulSeq approach has readily shown its utility, in particular for rapid prototyping of MR sequences. We are currently working on the extensions of the approach to allow for more flexible sequences and new applications. The audience is invited to participate in the process by providing feedback and ideas, contributing code for PulSeq modules and sequences.

Acknowledgements

References

[1] K. J. Layton, S. Kroboth, F. Jia, S. Littin, H. Yu, J. Leupold, J.-F. Nielsen, T. Stoecker, and M. Zaitsev, “Pulseq: A rapid and hardware-independent pulse sequence prototyping framework,” Magnetic Resonance in Medicine, 2016. http://dx.doi.org/10.1002/mrm.26235

[2] T. Stoecker, K. Vahedipour, D. Pflugfelder, and N. J. Shah, “High-performance computing MRI simulations,” Magnetic Resonance in Medicine, vol. 64, no. 1, 186–93, 2010. http://dx.doi.org/10.1002/mrm.22406

[3] 3. N. R. Zwart and J. G. Pipe, "Graphical programming interface: a development environment for MRI methods." Magnetic Resonance in Medicine vol. 74,no.5, 1449-60, 2015.