Tactical approaches to (re)shimming

In an earlier post I looked at the effects of heating on the temporal stability of EPI data. Particular attention was given to the translations in the phase encoding dimension that arise whenever the scanner drifts off resonance during imaging, through the heating and subsequent cooling of the gradient coil (rapid time constants) as well as of the passive iron shims between the gradient coil and the magnet cryostat (slow time constants). These frequency shifts are most apparent between blocks of EPI as discontinuities, or steps, in a concatenated time series, because of the on-resonance adjustment that precedes the start of each EPI block.

Fortunately, for a typical modern scanner there is little detrimental effect on the temporal SNR (and statistical power) of the total time series once it has been corrected for motion using a standard rigid-body realignment algorithm. But the outstanding question is this: must we rely so heavily on the realignment algorithm to fix what is really a hardware limitation? Surely, fixing it in software is a hack? (Save the jokes, I've almost certainly heard them! See Note 1, below.) And, as pointed out by El-Sharkawy et al., if the magnetic field is being perturbed sufficiently by heating to cause components with a Z spatial dependence to change, what about all the other spatial dependencies? If the shim is being compromised, why not do something about it?

The standard fMRI protocol

Let's start by reviewing what happens in a standard protocol. On Siemens scanners, at least, the usual approach to an fMRI experiment is to shim at the start of the session and then not re-shim unless there is a substantial change in the prescribed imaging volume (the stack of EPI slices). Shimming is initiated by the first scan that's not a localizer. (See Note 2.) So, if a 3D anatomical, such as an MP-RAGE, is acquired after the localizer and before the first EPI, say, there will be no further shimming during the session (unless requested by the operator).

Assessing the problem

Now, we could continue to investigate shimming as a means to mitigate the effects of heating using experiments on phantoms. That would be a full study in and of itself. To keep this post shorter and more relevant to you, I'm going to jump straight to brain data. That's because when we are talking about shimming (or re-shimming), we are going to mix the effects of scanner heating with our old chum, subject movement. We're going to lump everything together and look at the resultant. Put another way, there's no point in coming up with a putative solution to the heating issue if it could exacerbate the movement issue.

Experimental verification

Very briefly, as part of a vision experiment, shimming was performed (or not) between blocks of 150 volumes of EPI, TR=2 seconds. (Siemens users: See Note 3.) During the first session, shimming was performed between blocks for the first five blocks, then shimming was omitted between blocks for the next five. The time gaps between blocks weren't controlled rigorously; it was whatever was required to set up a new stimulus script plus, when appropriate, the 30-odd seconds to re-shim. A typical inter-block gap was between one and two minutes. In a second session on the same subject the ordering was reversed: shimming was omitted for the first five blocks, then performed between blocks for the final five blocks.

In the two figures below are the motion parameters generated by the FSL realignment algorithm, courtesy of Ariel Rokem.

Session 1 - shimming performed between the first five blocks of EPI

 Session 2 - shimming performed between the last five blocks of EPI

It's evident that re-shimming tends to reduce the inter-block stepped translations in the phase encoding axis (green traces in the top parts of both figures), although it should be noted that the variations within blocks are the same whether shimming is performed or not. But eliminating the discontinuities isn't the most important consideration for real data. What's happening to the statistical power in the entire concatenated time series? To assess that we can look at the temporal SNR (TSNR).

The effect of re-shimming on TSNR

Given that this was a visual experiment, TSNR was evaluated in visual cortex only. For each of the two sessions, two sets of five blocks of EPI were concatenated and motion-corrected before TSNR was determined in a region of interest in visual cortex (left V1):

Similar results were obtained for right V1. Note that the TSNR for the first session was somewhat lower than for the second session. This is presumably because the subject moved more during the first session. Compare the two motion parameter figures above and you'll see there is more "high frequency" motion in the first session; the red traces show the effects most noticeably.

Clearly this is a case study, and a limited one at that. The single subject was someone with extensive fMRI experience, i.e. she was a "ringer," and not prone to move as much as a naive subject might. But it strongly suggests that re-shimming between blocks can offset the effects of gradient heating and/or subject motion. I've made no attempt to discern here which effect was biggest, all I wanted to know was whether re-shimming made things better or not. (I was especially interested to know if re-shimming made things worse! It didn't!) My guess would be that motion dominates the heating effects. I have two anecdotal pieces of evidence to offer. Firstly, the inter-block steps were larger for the brain data than for the earlier phantom data, though the possibility remains that the inter-block gaps were longer here. Secondly, the difference in TSNR between sessions is consistent with the first session having more motion than the second, i.e. that the motion dominated the heating effects. Together, we might conclude that re-shimming provides a major benefit of correcting the magnetic field effects of head movement, as well as a minor benefit of correcting (to a crude approximation) some of the gradient/shim heating effects.

Other issues to consider

To prove whether motion dominates heating or vice versa would take a large study that is way beyond what I wanted to show in this post, which was merely to suggest that re-shimming can provide a tactical advantage to your experiment. A full study would need to look at the effects of parameter selection on heating, different types of motion, different inter-block gaps, etc. It's a very large, multi-dimensional problem!

Let's suppose, then, that re-shimming appears to generate a benefit (not fully quantified) to fMRI experiments. We might suppose that subjects who move more might benefit more from repeated shimming, and we might predict that the discontinuities generated by variable (or long) inter-block gaps would also be reduced by repeated shimming. But are there any down sides? In particular, if you have a good subject who hasn't moved, your scripts run one after the other perfectly and your scanner is in a thermal steady state, might re-shimming mess things up?

In a separate test I tried moving during the shimming acquisition itself, to see if the algorithm would fail to converge or otherwise put out weird values. I wiggled my head in a manner that a poorly compliant subject might, especially lots of chin-to-chest movement. I then held still for subsequent EPI scans. Fortuitiously, the ghost level and TSNR of EPI time series weren't particularly affected by my movement during the preceding shim! I obtained almost identical results with or without deliberate head movements during shimming. This would suggest that the field map shim used on a Siemens Trio scanner is spatially quite smooth; it is robust to head movements of a few millimeters, particularly in the chin-to-chest direction. And to date I've yet to see the shimming algorithm outright fail, leaving highly ghosted EPIs.

Final thoughts and advice

As far as I can tell, the only real down side to shimming between EPI blocks is the additional time it takes. It's a trade-off. If you have your stimulus scripts set up in such a way that the gap between blocks is just a few seconds, and further assuming that you don't need to check on your subject ("Are you still awake?") then it may be best to just carry on as quickly as possible. Based on the data above, I'd have to say that as soon as your gap is approaching a minute you're probably better off "wasting" an additional 37 seconds (for the Siemens "Standard" phase map shim) having checked that your subject is still with you. Of course, if you run into a problem getting your next stimulus script running such that several minutes elapse, you should definitely re-shim. Likewise, you should re-shim any time you suspect that your subject may have moved his head. And if you have sufficient time to scan between every single EPI block regardless, it shouldn't hurt and may well help.

If anyone has experience with (re)shimming strategies I'd be interested to hear about it, especially if you have run into situations where re-shimming introduced a problem that wouldn't have happened otherwise.

Acknowledgments:

Thanks again to Ariel Rokem for acquiring a lot of the data discussed in this as well as the last post, and for processing all of it and more besides. And thanks to Daniel Sheltraw for being an excellent sounding board!

------------------------------

Notes:

(1)  Okay, fine, you win. Just the one joke about software fixes, here.

(2)  Siemens users, I won't go into exactly how the scanner "decides" when to shim, just know that by default the first anatomical or functional scan that occurs after the localizer scan will trigger a shim. Shimming is the low buzzing noise lasting approximately 25 seconds that happens near the start of your scan session. There is an advanced shim mode, and it would also be possible (but is not advisable) to disable shimming entirely. More on the different shim modes another day.

(3)  Siemens users, to instigate a shim at any point during a protocol:

1. The scanner must not already be running or have scans that are queued, ready to acquire automatically.
2. In the exam window (where you start/stop scans) open the next exam (i.e. the scan you're about to run) so that you see the small black tab to the left of the protocol number. (Doing this also shows the slice prescription in yellow on the three image display windows.)
3. Now that the current protocol is open, select the Adjustments pull-down from the Options menu at the top of the screen.
4. On the window that opens, find the tab labeled Show towards the bottom-right. It's the last in a row of five tabs.
5. On the Show tab, click the Invalidate All button and then close the window. You'll see a green highlight turn red and the shim status will change to Not Adjusted.
6. Now start your scan as normal, using the Apply button above the protocol window. You should hear the scanner shim (low buzzing for 20 seconds and a message in the bottom-left corner of the screen telling you it's shimming).

 Simply repeat this procedure whenever you want to force a new shim.