uncoherent slices distortion

[romainVala]

Dear all

First of all, many thanks for providing the sequences

We are running the multiband diffusion on our PRISMA VE11C.

I notice an artefact on many diffusion protocol running with multiband factor (2 or 3). There is a distortion in the phase direction but only every two other slice which is diferent every two other volume

The best description is to loock at the data. Here is a screen shot of the siemens slices view for the first four b=0 volumes (but the same trend is seens on the direction, although more difficult to see, since it mixt with eddy curent)

it is not eddy curent since it is on the B0 volumes this can not be a subject motion since it is very regulare and it repeat every two volume. and we see it on different subject

It seems to me that this appear with the recent upgrade to VE11C. (but I have to check)

I notice on different protocol setting but here is the one use for the screenshot

MBep2d_diff_175iso_B2k_d60.pdf

Many thanks for your help

Romain Valabregue

CENIR, ICM, paris

[romainVala]

Sorry for the screen shot with a lot of white. It may be easier to see directly on a .gif file

[BenInglis]

Hi Romain, I've seen similar behavior very rarely on my Trio, and from memory it was an early indication of a gradient control problem. IIRC we ended up finding a gradient cable whose resistance was changing with heating, leading to further change in resistance, more heating, etc. Had all the gradient cables replaced. So I would suggest first testing the stability of product EPI, or product DW-EPI, and try to emulate the duty cycle that leads to the alternating distortion patterns. Does it happen only when the scanner is cold? Only after heavy usage? By best guess from afar is that the DW-MB-EPI sequence just happens to be maximally sensitive (due to the blipped CAIPI, most likely) to an underlying hardware problem. My advice: check that next.

Cheers!

[BenInglis]

PS do these tests on a phantom :-)

[eauerbach]

I don't know what the problem is, but I agree that to look into it further the best thing would be to use a phantom. And then try to reproduce it using a product sequence. At that point it can be a Siemens service issue.

I don't think it is a specific MB or CAIPIRINHA issue since although there is some change in all of the slices, it is very strongly worse every 2 slices. For MB acceleration of 3 with a PE shift of 1/3 I would expect to see something in groups of 81/3.

What is grouped by 2 (or 4) within a TR by default is the interleaved slice acquisition order. So another thing to try would be to change the slice acquisition order from Interleaved to Ascending or Descending.

[romainVala]

thanks for the response, You are right this is indeed not related to the sequence, since I get similar distortion with the siemens multi-slice DTI. (Although the deformation was much smaller for the water phantom)

We just had a siemens maintenance, but unfortunately they did not discover any gradient malfunction. I do not know which test would be relevant for them ...

Many thanks for your help and sorry for the slightly off topic

[BenInglis]

Hi Romain, The gradient cables are air-cooled, as in, not intentionally cooled at all. The gradient filter box generally gets cooled air from the equipment room, so it can handle the high duty cycle scans marginally better than the cables themselves, but not much more. You've reminded me to write a blog post on simple temp monitoring of gradient cables and filters. I will try to get that together in the next few days. In the mean time, I suggest you run back to back DTI scans until everything is warmed up nicely, then see if the distortions become more frequent. You may need 30+ min of DTI to see the effect. Siemens doesn't use high gradient duty cycles in their routine testing, and they don't have a specification for gradient cable or filter temp with use, so you may need to recreate heavy usage to trigger this sort of problem. Final note in closing: my bet is that it's either your gradient cables or the gradient filters that are the root cause, rather than the gradient set itself.

[romainVala]

Dear all

After several Siemens checking and different test, we conclude that this is not due to over heating of the gradient cable.

Thanks to BenInglis we follow his recommendation (https://practicalfmri.blogspot.com/2018/03/monitoring-gradient-cable-temperature.html). We measure an increase in temperature up to 50 C in the gradient cable axis that was used (unique diffusion direction in the same direction as the reading axis, 30 mn with X then Y and Z). Note that the sequence stop several times with a warning message of Gradient temperature too high. So there is an internal check of the gradient cable temperature. We never saw this stop with routine acquisition, this mean that the elevation in temperature was specific to this experiment. (due to the repetition of diffusion direction of (1 0 0))

The deformation we saw on the phantom data was not getting bigger after increase of temperature. I then also did the standard acquisition in this morning after a WE of rest. (so no temperature issue at all) And I see the exact same distortion.

With in vivo acquisition I see also distortion for the diffusion weighted acquisition. but with the water phantom the diffusion acquisition are too noisy to see something. So I only report here deformation on the B0 images.

If all b=0 acquisition occur at the beginning of the scan I do not see any deformation, they all look like that

if b=0 acquisition occurred after a diffusion weighted acquisition (like each every 10) they all show a distortion (except the first one) similar to this one :

As Eddie suggested I change the slice ordering with ascending. the artifact looks different (just because the slice order is different) but it is the same distortion

I then reproduce the same acquisition parameter with the siemens SMS sequence, and I do see the same distortion. But even if it is not specific to the cmrr sequence this does not mean there is a possible improvement ... ?

Many thanks for your help

[xjqian]

Maybe transient eddy currents with long decay constant from the previous diffusion weighted frame? Please see #68 . Could you add "Delay in TR" to test whether this is the case?

[romainVala]

Thanks, that make sense ! You are wright if I increase the delay in TR I get less and less artifacts.

The bad new is that it is quite expensive in acquisition time. In order to do not see the effect I had to increase the TR of 1.5 s (which is 1 mn 40 s extra scan-time). May be 1 s is enough, but 500 ms is not at least in my case.

in you post you propose to add a delay of 300 to 500 ms, which is clearly not enough here. Is there some scanner imperfection that would increase those transient eddy currents ?

My diffusion sequence is not particularly excessive : MB 3 / 1.75 isotropic resolution / b=2000

[BenInglis]

Hi Romain, perhaps you have a bum preemphasis setting or a bad control board. Did Siemens run full eddy current checks? In your initial report the distortion was intermittent, which would be consistent with a malfunctioning control board rather than a systematically incorrect preemphasis setting.

[julfou81]

Hi all, Thank you Romain for pointing this out! And thank you all for your quick and very thougthful answers. I am running a 3T Prisma in VE11B in another site and tried the same protocol as Romain mentioned and observed the same effects. Following the suggestion to use a delay in TR was able to solve the problem but at a high cost in acquisition time. A quick check showed residual effects even with a delay in TR of 1500ms and no effect at all at 5000ms. Obviously using bipolar gradients solved the problem but at the expense of longer TE and TR. We also reproduced a similar behavior with the Siemens product Siemens ep2d_diff sequence which has no slice slice acceleration implemented. We re going to check also Siemens eddy current tests.

[julfou81]

Hi all, Here are an abstract from the last ISMRM and a publication explaining the origin of this issue and proposing some ways to tackle it on the hardware and on the preprocessing side:

http://indexsmart.mirasmart.com/ISMRM2018/PDFfiles/3194.html https://arxiv.org/abs/1704.00494

The origin seems to be the short TR of these multi-band acquisitions combined with high b-values required for HARDI schemes and a sub-optimal eddy current compensation from Siemens. I wonder if the other constructors are doing a better job on this aspect?

[xjqian]

I almost forgot that we've put in an ISMRM abstract a few years ago as well: http://archive.ismrm.org/2015/2931.html