NOROT flag causes FOV shift direction to be wrong

[dabosch]

Hi,

I observed some funny/strange behavior on our Siemens Prisma Fit system. Background: I want gradients operating with my RF pulse, and the orientation of these gradients should not change with FOV orientation.

I used pulseq 1.4.2, the example GRE3D, added labels to it, and did ICE3D recon. I compared it to the product 3D GRE and make sure all directions and shifts are right.

Once I had a 3D GRE sequence that ran and reconstructed correctly, I added the NOROT flag to a block that is not related to encoding (here the non-selective RF pulse). I added SET NOROT 0 to the following block.

Now, FOV shift is wrong: when I measure in COR-RL orientation and shift the FOV to posterior, the image will be measured with the FOV shifted in Feet direction. Once I remove the SET NOROT 1 part from the RF pulse the FOV shift is correct again.

Any idea where in the code I can test modifications? I've been staring at the Siemens interpreter source code and don't understand why this is happening.

Best, Dario

[dabosch]

FYI: Here's how I added the NOROT flag to the writeGRE3D.m:

        % RF spoiling
        rf.phaseOffset = mod(117*(iY^2+iY+2)*pi/180,2*pi);
        adc.phaseOffset = rf.phaseOffset;

        % Excitation
        seq.addBlock(rf,rfDelay,mr.makeLabel('SET','NOROT', 1));
        % Encoding
        seq.addBlock(gxPre,gyPre(iY),gzPre,mr.makeLabel('SET','NOROT', 0));
        seq.addBlock(dTE);

I also tested adding mr.makeLabel('SET','NOROT', 0) as separate block right after the RF pulse, but that made no difference.

Edit: This is the writeGRE3D.m file I'm using. Basically I added labels to it. writeGRE3D.zip

[m-a-x-i-m-z]

Interesting... I have to very carefully think about this problem and how to solve it, or whether there is a solution... it is probably related to the fact that currently phase/frequency objects are only added to the blocks containing RF pulses or ADC events. So changing the setting for the excitation pulse but not the ADC creates an inconsistency. We need more experience to understand how to handle these, but this is what the "experimental features" are about, isn't it ;-)

In a mean time: could you please explain why do you want to set NOROT flag to the block what contains no gradients? The rotation matrix of the block has no effect on the RF pulses, so physically it doesn't seem to make any sense to me...

--Maxim

P.S.: the envisioned use of the NOROT option was the diffusion-weighting gradient module, e.g. such that contains no ADC or RF but only gradients, but with your example I actually need to check whether it would work even in that case...

[dabosch]

Hi Maxim,

using the NOROT flag on a block without gradients is just the minimal working example, to show that the problem really comes from the NOROT flag and not from my gradients. I've been optimizing gradient and RF waveforms for homogeneous excitation and want to play those out. So in the real use case there will be gradients played out together with RF. I was able to successfully measure this, but the FOV shift becomes hard to predict. So far I've avoided this by moving the phantom until the ROI is in the isocenter. This workflow is inefficient though. I believe Setting the NOROT flag for the ADC event will not work in my case, since that would mean the read gradient will be along the wrong axis.

Best, Dario