Support for Pulseq v1.5.0

[btasdelen]

Missing functionality to support new interpreter features:

• RF storage now includes RF center position, also supports frequency/phase offsets in PPM.
• ADC also supports frequency/phase offsets in PPM.
• Arbitrary gradients include first and last points.
• Soft delay extension (See Implement soft delay extension #264 ).

Some functions/functionality that are not crucial for support but nice to have to catch up with Matlab Pulseq Toolbox.

• Demo sequences that use above features.
• calcMomentsBtensor()
• paperPlot() or simply improved plotting.
• Oversampling of arbitrary gradients.
• Scale gradients checks for system limits.

Missing functionality for v1.5.1:

• Rotation extension.
• RF shim extension.

[Tooine]

Hi,

I'm using pypulseq to develop MR Fingerprinting sequences. While I was using those sequences only with the KomaMRI simulator until very recently (without problem), I can now access a real MR scanner to test them. Yet, the scanner interpreter is up to date and only accepts pulseq 1.5 sequences...

So I was wondering when we might expect pypulseq to be compatible with pulseq 1.5? Depending on the availability, perhaps I should translate my code into Matlab.

Also, I'm just curious to know if there exists a way to modify "by hand" a 1.4 pulseq sequence file to make it compatible for 1.5?

Thanks!

[schuenke]

Hi @Tooine

In principle the Pulseq 1.5 interpreter should be compatible with Pulseq 1.4.x files. However, there is/was a bug in the code prohibiting the execution of older seq-files (including the gre_example sequence provided with the 1.5.0 interpreter code btw). Here is the corresponding Issue (pulseq/pulseq#104) in the Pulseq repo. Maxim provided a fix in one of the comments: pulseq/pulseq#104 (comment)

and if you are interested in MRF, you might want to check our public repo for cardiac MRF: https://github.com/PTB-MR/cMRF
The paper should (hopefully) be published soon.

EDIT:
@Tooine: Initializing every label that you use with "0" at the beginning of each sequence might also be enough, but I didn't verify this on my own yet.

[Tooine]

Thanks for the quick reply @schuenke!

I have seen this issue on Pulseq but I though it was only fix in Matlab ... To what I understand now, the file Arbitrary.cpp in which we should make the modification is a file of the interpreter, not the (py)pulseq code, right? Can you confirm that? (sorry I don't have access to the interpreter myself so I'm just guessing as I did not find the file elsewhere)

[fzimmermann89]

Yes, it is part of the interpreter.

[fzimmermann89]

I think as a work around, maxim mentioned setting all used labels to zero in the beginning of the sequence?
This could be done with pypulseq without modifying the interpreter

[Tooine]

Sure, gonna try both possibilities! Many thanks :-)

[btasdelen]

So I was wondering when we might expect pypulseq to be compatible with pulseq 1.5? Depending on the availability, perhaps I should translate my code into Matlab.

Among the essential 4 features, I implemented the soft delay, but it is not tested at all. The rest still needs to be implemented. Since there are substantial changes to the file format, I anticipate bugs, especially related to reproducibility (i.e. generating the same .seq file given the same inputs as the Matlab pulseq).

The other 3 features look less involving, but we will see. Personally, I can most likely start working on this again late May. Depending on who else wants to work on this, we can release during the summer, hopefully.

[mcencini]

So I was wondering when we might expect pypulseq to be compatible with pulseq 1.5? Depending on the availability, perhaps I should translate my code into Matlab.

Among the essential 4 features, I implemented the soft delay, but it is not tested at all. The rest still needs to be implemented. Since there are substantial changes to the file format, I anticipate bugs, especially related to reproducibility (i.e. generating the same .seq file given the same inputs as the Matlab pulseq).

The other 3 features look less involving, but we will see. Personally, I can most likely start working on this again late May. Depending on who else wants to work on this, we can release during the summer, hopefully.

Hi,
I would be happy to help. I also wanted to include rotation extension (currently under development on MATLAB repo, version 1.5.1). Would that be ok? Thanks again for this package :D
Matteo

[btasdelen]

@mcencini feel free to test #264. I added rotation extension to TODO, but it might be a better idea to merge previous changes first to avoid conflicts.

[mcencini]

@btasdelen following conversation in #264, I would be totally in favor of splitting the #288 PRs in multiple smaller and easier to review PRs (e.g., #289). As these smaller PRs would likely not be functional (not compatible with any interpreter), I would prefer not to open PRs to the current master branch. Would it be possible for the maintainers to create a v1.5.0 branch starting from master that I could use for this? Is that a good idea?

[btasdelen]

@mcencini I think that is a good idea. I created a branch called v1.5.0_dev, we can use that one.