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.

Administrative Post: 19 April, 2011 (2/2)

Siemens users may be interested in a user training guide & FAQ that we use at Berkeley to initiate newbies into the ways of the dark side. (Using the Force is often the only way to get an fMRI experiment to work. What, you thought the f stood for functional? Ha!)

The guide is a bit rough - sorry for English-isms and typos - is updated fairly regularly based on popular misconceptions and the like, and is worth exactly what you pay for it. It's free. Use and abuse it however you like. It's a Word document so that you can reorder things, add your own notes, etc. I would appreciate constructive feedback, especially if you find mistakes or have suggestions to improve it, but there's no need to ask permission to use it, change it, replicate it, sell it...

The most recent version of the training guide/FAQ is available from this web page:

http://bic.berkeley.edu/scanning

Locate the file attachment towards the bottom of the page, it's called 3T_user_training_FAQ_19April2011.doc. The most recent contents appears below.

Caveat emptor.

The document is only a component of user training, don't expect to learn how to scan by reading it! Rather, use the tips to extend your understanding, refine your experimental technique and so on. Note also that this document is for a Siemens TIM/Trio (with 32 receive channels) and running software VB15. There may be subtle or not-so-subtle differences for the Verio and Skyra platforms, for software VB17, VD11, etc. so keep your wits about you if you're not on a Trio with VB15!

You may have local differences, e.g. custom pulse sequences, that allow you to do things that contradict what you find in this user guide. Talk to your physicist and your local user group before taking anything you find in this guide/FAQ too literally.

Finally, you wont find many (any?) references in this guide/FAQ. It's for the training of newbies, not a comprehensive literature review! If you are seeking further information on something I mention in the guide and you can't find a suitable reference yourself, shoot me an email and I'll do my best to point you in a useful direction.

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

User guide/FAQ contents (as of 19 April, 2011):

Administrative Post: 19 April, 2011 (1/2)

I have renamed the three posts entitled "Diagnosing artifacts in fMRI data: Part x" to be "Physics for understanding fMRI artifacts: Part x." I am developing new posts in the series and through post seven at least the content is all quite theoretical; I'm not actually discussing artifacts or showing data! (But don't worry, I'm limiting the content to the essential concepts required to understand and differentiate fMRI artifacts. It's not going to be an entire MRI physics course!)

Once I've concluded this background series of physics posts (there are another eight or nine posts to come) I'll start a new series that will be entitled something suitable for actual artifact recognition (with data!), along the lines of the original title of the series. Hopefully this re-categorization will allow future readers to establish suitable paths through the posts, when a strictly chronological path probably won't be the best one.

Shim and gradient heating effects in fMRI experiments

Another week, another tangent. At least this one is directly related to the artifacts that I promise to get back to soon!

In this post I will review the nature and typical magnitudes of heating effects in a scanner being used for fMRI. Ever wondered why you sometimes observe discontinuities, or 'steps,' in a time series comprising the concatenation of multiple blocks of EPI data? What causes these discontinuities? Are they a problem for fMRI? And are there ways to reduce or eliminate these discontinuities at the acquisition stage? To begin with, some background.

Electrical energy in, thermal and vibrational energy out

When you run the gradients to generate images, a lot of heat is produced through vibrations (friction) of the gradient coils - the Lorentz forces that result from putting electrical current through copper wires immersed in a magnetic field - as well as through direct (resistive) electrical mechanisms. Much of that heat is removed via water cooling inside the gradient set. Water typically enters at about 20 C and may exit the scanner as high as 30 C. Modern gradient designs are pretty efficient at removing heat from the gradient coil. (I've done throwaway tests on my Siemens Trio that suggest the steady state temperature of the return cooling water is achieved after about 15 minutes of continuous scanner operation.) But - and this is the crux of this post - the heat imparted to the scanner isn't removed at precisely the same rate that it is being produced. In other words, the scanner is unlikely to be in a truly steady thermal state while you're using it.