Non-selective block pulse not playing about pypulseq

[sravan953]

Will attempt to reproduce this next week, and investigate further.

[schuenke]

I know its a really old Issue, but I encountered the same problem at our 3T Verio (VB17, interpreter v1.4, PyPulseq da4568a) when I was trying to implement a saturation pulse train consisting of several block pulses with varying flip angles (realized using different durations) and spoiler gradients.

After a lot of testing and debugging I realized that the problem only occures if at least two block pulses with different durations are used. Using the same duration, but different amplitudes works.

For Gaussian or Sinc pulses no such problem occurs.

However, I am not sure if this is a PyPulseq specific problem. Maybe somebody with Matlab can try ?!

[sairamgeethanath]

Can we please document this behavior somewhere and start testing the compression implementation? Thanks, @patrick for pointing this out to us!

…

On Tue, Jul 5, 2022 at 9:49 AM Patrick Schuenke ***@***.***> wrote: I know its a really old Issue, but I encountered the same problem at our 3T Verio (VB17) when I was trying to implement a saturation pulse train consisting of several block pulses with varying flip angles (realized using different durations) and spoiler gradients. After a lot of testing and debugging I realized that the problem only occures if at least two block pulses with different durations are used. Using the same duration, but different amplitudes works. For Gaussian or Sinc pulses no such problem occurs. — Reply to this email directly, view it on GitHub <#5 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHLQWAPM4H23NHWVVQVWLR3VSQ4PJANCNFSM4IEB442Q> . You are receiving this because you authored the thread.Message ID: ***@***.***>

-- *Sairam Geethanath, Ph.D.* “There are plenty of compelling reasons to push MRI to be more powerful, but that’s one facet of advancing the field. Another is delivering it to the world.”

[schuenke]

I created a minimal sequence/script for debugging that should fail on our scanner in my opinion. I will test it tomorrow morning!

import numpy as np
import pypulseq as pp

seq = pp.Sequence()
sys = pp.Opts(max_grad=30, grad_unit='mT/m', max_slew=120, slew_unit='T/m/s')

rf_1 = pp.make_block_pulse(flip_angle=45/180 * np.pi, duration=2e-3, system=sys)
rf_2 = pp.make_block_pulse(flip_angle=90/180 * np.pi, duration=4e-3, system=sys)
grad = pp.make_trapezoid(channel='x', area=750, duration=2e-3)
adc = pp.make_adc(num_samples=128, delay=0, duration=2e-3)

seq.add_block(rf_1)
seq.add_block(grad)
seq.add_block(rf_2)
seq.add_block(grad)
seq.add_block(adc)

print(seq.test_report())
seq.plot()
seq.write('block_pulse_debug_python')

The plots and the generated seq-file look fine.

Can somebody create the same script with Matlab and post it here or check if the seq-files are identical? This way we can find out if it is a PyPulseq or a pulseq interpreter bug. In my opinion it's the latter.

The generated seq-file created with Python is attached. It's just renamed as *.txt so I can attach it directly.
block_pulse_debug_python.txt

[sravan953]

@sairamgeethanath Thanks for the suggestion! 👍
@schuenke Great experiment, here's the MATLAB version from Pulseq 1.4.0 (commit 9db4bb688d54aad7665494476038962f8c2916f1). The .seq files are identical, so if both Pulseq/PyPulseq files do not run on the scanner, we can open an issue on the Pulseq
MATLAB_block_pulse_debug_python.txt
repository.