MR Protocols

Gradwarp

• By default, the scanner applies a correction for nonlinearities in the gradients, called gradwarp. Presumably, the correction will make your images more spatially accurate. It is not clear exactly what is the nature of the correction.
• Currently, Atsushi's spiral sequence does not take the gradwarp into account; thus, spiral images may be (slightly) misregistered with respect to images from stock GE sequences.

"Silent" Partial Fourier

• In EPI, if you increase the acquisition time too much (e.g. by having a large matrix size or a short TE), the pulse sequence will be unable to acquire the requisite half of k-space before the TE value. When this happens, the scanner silently decides to simply drop that half of k-space and acquire a default of 8 lines of k-space for that half. This is potentially quite bad, as you lose a lot of SNR. Moreover, there will be wasted dead time after the RF pulse up until the beginning of the 8 lines. The safest way to see whether the silent dropping of k-space happens is to check the plotter (to do that, start scanning, pause the scan, and then run plotter from a command window). An easier (but unverified) way is to monitor the Relative SNR number in the console. It appears that once you go over the limit, the relative SNR jumps way down.
  • There is weird buggy behavior in the console concerning the relative SNR number. If you violate the limit and the number of slices that can be acquired is less than the current number of slices (resulting in # acqs being set to 2), you need to reset the number of slices to a lower number within the limit. Then, the # acqs will go back to 1, as desired.
  • Regarding using the relative SNR as a index for whether the silent partial fourier occurs, for some reason, you need at least 20 volumes prescribed. I have found that if you prescribe less volumes, then the big jump in relative SNR does not occur.
• To deal with the "silent" partial Fourier issue, one strategy is to ensure that you always get full coverage of k-space. This may be preferable simply due to the reason that partial Fourier strategies may result in data that have problems in the reconstruction process.
• A different strategy is to ensure that you get the maximal number of lines of k-space (not the default 8 lines). It is not clear how to do this (perhaps CV variable num_overscan?)

Fermi filtering

• The reconstruction code applies a Fermi low-pass filter by default(!). To turn this off, set CV var rhfermr to the matrix size and set CV var rhfermw to 1.

Reconstructed image size

• By default, images are reconstructed at matrix sizes that are powers of two (presumably for speed). However, this wastes disk and memory space. To change the reconstructed image size, set CV variables rhrcxres,rhrcyres,rhimsize. For example, if I acquire a 70 x 70 matrix size, I would set rhrcxres=70, rhrcyres=70, rhimsize=70, and then I would get 70x70 images instead of 128x128.
• But be careful --- it appears that one you set these CV vars, they will no longer default to the next highest power of two if you change parameters of the sequence. For example, in one instance, I was increasing the matrix size but forgot to change the CV vars, and the resulting reconstructed images were totally corrupted.

Precise values

• The GUI tends to round values that you enter. For example, if you enter 1605.242 for the TR, the GUI will round the value displayed to 1605.2, but the value that actually will get used is the precise one. You can check this via the CV vars (e.g. optr), which you can take to be the actual value used.
• If you enter in a precise value, and copy and paste the entire sequence, usually I find that the precise value is also copied.
• If you enter in a precise value, and then save the protocol, I have found that (at least in some cases) the wrong, rounded value is saved. You should re-enter the precise value every time you load in the saved protocol.
• If you have a precise FOV size (e.g. 14.24 cm FOV) entered, and you copy that slice prescription to another sequence, I have found that the rounded FOV is copied (e.g. 14.2 cm FOV). You should re-enter the value to get it right.

CV variables

Many variables that control scanner behavior are not accessible via the usual GUI interface. To access these variables, press Save Rx and then Research->Download. Then, select Display CVs.

Here is a list of CV vars that Kendrick has run across. Atsushi might know about more of them.

 YOU MAY VERY WELL WANT TO USE THESE:
 map_deltaf [frequency for echo time difference (for Atsushi's spiral fieldmap)]
 rhfermr [Fermi radius (in matrix units I think)]
 rhfermw [Fermi width (in matrix units I think)]
 rhrcxres [transform size (x)]
 rhrcyres [transform size (y)]
 rhimsize [image size]
 pepolar [phase encoding polarity (direction)]

 YOU PROBABLY DON'T WANT TO USE THESE:
 opslquant [number of slices]
 optr [TR]
 opfphases [number of TRs]
 opte [TE]
 opflip [flip angle]
 opfov [field-of-view]
 opxres [frequency-encode resolution]
 opyres [phase-encode resolution]
 opslthick [slice thickness]
 opphasefov [fraction of the FOV in the phase-encode direction]
 avminte [minimum TE, same as in GUI]
 opnex [number of excitations]
 nograd [no gradwarp, default is 0]
 rhferme [Fermi eccentricity??]

 UNKNOWN/UNTESTED:
 nframes [number of frames?]
 opti [?]
 num_overscan [default is 0?]
 rhmethod [default is 1?]
 esp [echo spacing?]
 autolock [autolock raw files, default is 0]
 rhrcctrl [controls what data are saved; 4-bit mask: imaginary, real, phase, magnitude; 3 means phase+magnitude]
 rhexecctrl [?]

Fieldmaps

One of the major problems that affects EPI data is spatial distortion. It is possible to correct for distortions in EPI data posthoc using fieldmap measurements. Kendrick has developed some MATLAB code that handles spatial distortion and other pre-processing procedures relevant to EPI fMRI data.

The process can be divided into two basic parts. The first part is getting the fieldmap acquisition right. The second part is using the code to process the EPI and fieldmap data.

Note that the information presented in this section is not yet complete (e.g. one big missing part is how to actually run the MATLAB code, and another missing part is the conceptual background of all this fieldmap stuff).

Fieldmap strategy

The higher-order shim (HOShim) is quite important and massages the field to be as homogenous as possible. (It's best to get the field right up front instead of relying on postprocessing!). In the HOShim, you should probably prescribe an ellipse that is liberal, i.e. covers all parts of the brain that are within your slice prescription. Covering some air outside the brain is fine. After the HOShim, make sure the Shim setting is OFF on all subsequent scans.

Normally, a pre-scan is run before each GE sequence. One of the things that the pre-scan does is to re-measure the peak frequency corresponding to water. This in effect compensates for drift in the overall magnetic field strength (which may be due to heating which in turn is dependent on what pulse sequences you run). But change in the magnetic field is exactly what we are trying to track using fieldmaps. So, some fancy footwork is necessary to avoid re-measuring the peak frequency.

The strategy that Kendrick likes is this:

1. After completing the localizer, ASSET calibration, higher-order shim, and in-planes, we are ready to proceed to the actual functional data.
2. Set up the EPI sequence and prescribe only one volume. Then hit SCAN as usual. This will trigger the pre-scan and acquire one volume. We want to trigger the pre-scan because the pre-scan includes other calibration routines that reduce ghosting, etc.
3. Then, proceed to collect your actual data by sandwiching EPI runs within fieldmap acquisitions, like F1 / E1 / F2 / E2 / F3 / E3 / F4. This ensures that you have a good estimate of the field throughout all of the EPI data.
4. Importantly, when starting each EPI and each fieldmap, click Save Rx, then click Research->Download, then Manual Prep Scan. This will open up a window. Don't do anything and just click DONE. Then click Prep Scan. Then press the green button on the console keyboard to start the scan. By using this procedure to start the scan, we avoid the pre-scan and therefore avoid the re-calibration of the peak frequency.

If for some reason, later in the session, you decide to acquire sequences other than fieldmaps and EPIs, you should allow the pre-scan to run as usual (by just hitting the SCAN button to scan). Of course, this will change the global constant describing the field strength.

Also, if you for some reason change parameters of the EPI sequence (such as TR, TE, phase direction), you need to allow the pre-scan to run so that proper calibration can be done. However, certain EPI parameters do not necessitate a pre-scan, like number of volumes to acquire and the phase-encode polarity (which is controlled through the CV variable pepolar).

Admittedly, sandwiching every EPI run between fieldmaps is an aggressive (and paranoid) strategy --- each fieldmap takes about a minute to acquire. If you like, it may be okay to space the fieldmaps more sparsely, e.g. F1 / E1 / E2 / F2 / E3 / E4 / F3, depending on how long your EPI runs are. Of course, this comes at the expense of having sub-optimal tracking of the field.

As an even less aggressive strategy, it is also conceivable to acquire only a single fieldmap (indeed, it appears that that's what most laboratories do, if anything at all) and also allow each EPI run to do the pre-scan (which avoids the cumbersome Manual Prep Scan procedure). The hope here is that the bulk of the drift in the magnetic field can be captured by just a change in a global constant. (To a first approximation, it does appear that the overall DC in the field is the biggest effect, but in data that I have looked at, there are additional components that can't be described by just a constant.)

Spiral fieldmap acquisition

Atsushi has developed a spiral-based sequence for measuring fieldmaps, and the quality is quite good. Here are the parameters that Kendrick recommends for optimal quality:

1. First, set slice thickness.
2. Then copy slices from the EPI (or in-plane) sequence.
3. 16-shot (16 spiral interleaves). The purpose is to minimize the readout time so as to minimize distortion and dropout (in combination with an appropriately short TE).
4. 700 ms TR. You could try to reduce this value to speed up acquisition. If the other parameters necessitate a longer TR, the sequence will silently use a longer TR and the scanner will scan past the on-screen time countdown. This is okay, just wait a few seconds.
5. 54° flip. This is the Ernst angle for the 700 ms TR (assuming a T1 constant of 1333.33 ms).
6. no SAT. In regions of bad field inhomogeneity, water will be off-resonance. So if you were to use a fat saturation pulse, you could destroy the water signal in these regions. That is bad. So, leave SAT off.
7. 256 x 256. This is a fairly high matrix size which will ensure high-resolution, high-quality field maps.
8. 2 NEX. Get two repetitions to ensure that the fieldmaps will have high SNR. If time is a consideration, you might try going down to 1 NEX.
9. 24.0 FOV. This is a large FOV to ensure that the entire head is completely covered in the in-plane dimensions. You could reduce, but be careful.
10. 6 dummies to ensure we reach a steady-state.
11. 4.545 ms TE. This is 1/440Hz * 2. It is unclear whether saved protocols will save the precise TE value. So it is recommended that you manually type in 4.545 in each scan session. (After typing it in, copying and pasting that sequence does preserve the precise value.)
12. map_deltaf 440. You must edit this CV variable after saving and downloading the spiral sequence. (The purpose of the TE and map_deltaf values is to choose echo times that are matched to the difference between the precession frequencies of water and fat, so that the resulting fieldmaps will have minimal artifacts.)
13. Note: it is very important that you get the TE and map_deltaf values right! Otherwise, there will be fat-related artifacts in your fieldmaps.
14. You will have to transfer the raw fieldmap data yourself (they do not get converted to DICOM format like data from the stock GE sequences). The files are named like P39936.7.

Pre-processing code

See preprocessfmri for details on how to process EPI data using fieldmaps.