MUX EPI - Revision history

imported>Huawu at 17:56, 30 March 2021

2021-03-30T17:56:36Z

@@ Line 150: / Line 150: @@
              fp.write("%.4f\n" % acq)
-==Offline Reconstruction==
 The standalone reconstruction package is shared via a private GitHub repository. Our recon should run on any modern linux system. However, it may be pretty slow (hours per fMRI scan), unless you have a beefy Intel CPU (e.g., a 12-core Sandy Bridge will get you down to 30 minutes or so) and/or good GPU cards (a Sandy Bridge CPU with three Nvidia Titan-X cards will get the recon down to a few minutes and allow it to run in real-time). We have spec'ed a linux workstation that will cost under $8k to build and can do real-time recons. All components are available on Amazon and NewEgg:
@@ Line 169: / Line 176: @@
 * A smaller case could also be used (again, we got this one to allow for an upgrade with an an extended ATX motherboard). Just be sure there is enough room between the motherboard and the power supply to intall the third GPU card.
 * Do NOT populate the Ultra M.2 socket on this ASRock motherboard, as doing so disables the third PCIe 3.0 x16 slot. (This is mentioned in the manual, but we didn't read that until after many hours of frustrated debugging!)

imported>Huawu at 17:55, 30 March 2021

2021-03-30T17:55:00Z

← Older revision		Revision as of 17:55, 30 March 2021
Line 150:		Line 150:
	fp.write("%.4f\n" % acq)		fp.write("%.4f\n" % acq)

	=~~Sharing=~~		==Offline Reconstruction==
	We are happy to share our SMS-EPI pulse sequences (and associated reconstruction code) with other GE research sites running a compatible platform (e.g., MR750 and related variants). We have two versions, one for BOLD fMRI and one for diffusion imaging. To request access to the pulse sequence (PSD) binaries and associated image reconstruction software, please send a note to Bob Dougherty (bobd@stanford.edu). You will also need to complete the [[Media:CNI_PSD_sharing_agreement.pdf \| sharing agreement]] and verify that you have an active research agreement with GE. Once the paperwork is out of the way, we will share the PSDs and recon code via a private [https://github.com/cni Github] repo, so you will need to send us your Github username and we will grant you access to the current code and future updates. The current versions of the PSDs run on both DV24 and DV25.

	Please note that this is very much "research grade" software and as such, it is not a polished "turn-key" package. You will need someone with experience installing research PSDs on a GE platform to get the sequences working, and will also need to set a mechanism for collecting the raw data files from the scanner and configuring the off-line reconstruction software on a Linux machine.

	=Offline Reconstruction=
	The standalone reconstruction package is shared via a private GitHub repository. Our recon should run on any modern linux system. However, it may be pretty slow (hours per fMRI scan), unless you have a beefy Intel CPU (e.g., a 12-core Sandy Bridge will get you down to 30 minutes or so) and/or good GPU cards (a Sandy Bridge CPU with three Nvidia Titan-X cards will get the recon down to a few minutes and allow it to run in real-time). We have spec'ed a linux workstation that will cost under $8k to build and can do real-time recons. All components are available on Amazon and NewEgg:		The standalone reconstruction package is shared via a private GitHub repository. Our recon should run on any modern linux system. However, it may be pretty slow (hours per fMRI scan), unless you have a beefy Intel CPU (e.g., a 12-core Sandy Bridge will get you down to 30 minutes or so) and/or good GPU cards (a Sandy Bridge CPU with three Nvidia Titan-X cards will get the recon down to a few minutes and allow it to run in real-time). We have spec'ed a linux workstation that will cost under $8k to build and can do real-time recons. All components are available on Amazon and NewEgg:

Line 174:		Line 169:
	* A smaller case could also be used (again, we got this one to allow for an upgrade with an an extended ATX motherboard). Just be sure there is enough room between the motherboard and the power supply to intall the third GPU card.		* A smaller case could also be used (again, we got this one to allow for an upgrade with an an extended ATX motherboard). Just be sure there is enough room between the motherboard and the power supply to intall the third GPU card.
	* Do NOT populate the Ultra M.2 socket on this ASRock motherboard, as doing so disables the third PCIe 3.0 x16 slot. (This is mentioned in the manual, but we didn't read that until after many hours of frustrated debugging!)		* Do NOT populate the Ultra M.2 socket on this ASRock motherboard, as doing so disables the third PCIe 3.0 x16 slot. (This is mentioned in the manual, but we didn't read that until after many hours of frustrated debugging!)

			=Sharing=
			We are happy to share our SMS-EPI pulse sequences (and associated reconstruction code) with other GE research sites running a compatible platform (e.g., MR750 and related variants). We have two versions, one for BOLD fMRI and one for diffusion imaging. To request access to the pulse sequence (PSD) binaries and associated image reconstruction software, please send a note to Bob Dougherty (bobd@stanford.edu). You will also need to complete the [[Media:CNI_PSD_sharing_agreement.pdf \| sharing agreement]] and verify that you have an active research agreement with GE. Once the paperwork is out of the way, we will share the PSDs and recon code via a private [https://github.com/cni Github] repo, so you will need to send us your Github username and we will grant you access to the current code and future updates. The current versions of the PSDs run on both DV24 and DV25.

			Please note that this is very much "research grade" software and as such, it is not a polished "turn-key" package. You will need someone with experience installing research PSDs on a GE platform to get the sequences working, and will also need to set a mechanism for collecting the raw data files from the scanner and configuring the off-line reconstruction software on a Linux machine.

imported>Huawu: /* Offline Reconstruction Hardware */

2021-03-30T17:54:00Z

Offline Reconstruction Hardware

← Older revision		Revision as of 17:54, 30 March 2021
Line 155:		Line 155:
	Please note that this is very much "research grade" software and as such, it is not a polished "turn-key" package. You will need someone with experience installing research PSDs on a GE platform to get the sequences working, and will also need to set a mechanism for collecting the raw data files from the scanner and configuring the off-line reconstruction software on a Linux machine.		Please note that this is very much "research grade" software and as such, it is not a polished "turn-key" package. You will need someone with experience installing research PSDs on a GE platform to get the sequences working, and will also need to set a mechanism for collecting the raw data files from the scanner and configuring the off-line reconstruction software on a Linux machine.

	=Offline Reconstruction ~~Hardware~~=		=Offline Reconstruction=
	The standalone reconstruction package is shared via a private GitHub repository. Our recon should run on any modern linux system. However, it may be pretty slow (hours per fMRI scan), unless you have a beefy Intel CPU (e.g., a 12-core Sandy Bridge will get you down to 30 minutes or so) and/or good GPU cards (a Sandy Bridge CPU with three Nvidia Titan-X cards will get the recon down to a few minutes and allow it to run in real-time). We have spec'ed a linux workstation that will cost under $8k to build and can do real-time recons. All components are available on Amazon and NewEgg:		The standalone reconstruction package is shared via a private GitHub repository. Our recon should run on any modern linux system. However, it may be pretty slow (hours per fMRI scan), unless you have a beefy Intel CPU (e.g., a 12-core Sandy Bridge will get you down to 30 minutes or so) and/or good GPU cards (a Sandy Bridge CPU with three Nvidia Titan-X cards will get the recon down to a few minutes and allow it to run in real-time). We have spec'ed a linux workstation that will cost under $8k to build and can do real-time recons. All components are available on Amazon and NewEgg:

imported>Huawu at 17:53, 30 March 2021

2021-03-30T17:53:35Z

← Older revision		Revision as of 17:53, 30 March 2021
Line 83:		Line 83:

	=Reconstruction=		=Reconstruction=
			==Reconstruction on Flywheel==
	The mux epi recon is started automatically on [https://cni.flywheel.io Flywheel] at the end of a mux scan. It can take anywhere from a few minutes to an hour per scan, depending on the resolution and number of TRs acquired. The default reconstruction method is 1D-GRAPPA for fMRI scans and split-slice-GRAPPA plus SENSE1 coil combination for diffusion scans. For a more detailed discussion on the difference between these methods, please also refer to this [http://cni.stanford.edu/updates-for-multiband-reconstruction CNI blog post]. The reconstruction on Flywheel also generates a metadata file (.json) for each mux scan. The file contains many useful parameters about the scan, such as acquisition parameters, timing information, calibration method, etc. Many of these information are not available in the nifti header, so it is often very useful to refer to this file.		The mux epi recon is started automatically on [https://cni.flywheel.io Flywheel] at the end of a mux scan. It can take anywhere from a few minutes to an hour per scan, depending on the resolution and number of TRs acquired. The default reconstruction method is 1D-GRAPPA for fMRI scans and split-slice-GRAPPA plus SENSE1 coil combination for diffusion scans. For a more detailed discussion on the difference between these methods, please also refer to this [http://cni.stanford.edu/updates-for-multiband-reconstruction CNI blog post]. The reconstruction on Flywheel also generates a metadata file (.json) for each mux scan. The file contains many useful parameters about the scan, such as acquisition parameters, timing information, calibration method, etc. Many of these information are not available in the nifti header, so it is often very useful to refer to this file.

Line 154:		Line 155:
	Please note that this is very much "research grade" software and as such, it is not a polished "turn-key" package. You will need someone with experience installing research PSDs on a GE platform to get the sequences working, and will also need to set a mechanism for collecting the raw data files from the scanner and configuring the off-line reconstruction software on a Linux machine.		Please note that this is very much "research grade" software and as such, it is not a polished "turn-key" package. You will need someone with experience installing research PSDs on a GE platform to get the sequences working, and will also need to set a mechanism for collecting the raw data files from the scanner and configuring the off-line reconstruction software on a Linux machine.

	=Reconstruction Hardware=		=Offline Reconstruction Hardware=
	Our recon should run on any modern linux system. However, it may be pretty slow (hours per fMRI scan), unless you have a beefy Intel CPU (e.g., a 12-core Sandy Bridge will get you down to 30 minutes or so) and/or good GPU cards (a Sandy Bridge CPU with three Nvidia Titan-X cards will get the recon down to a few minutes and allow it to run in real-time). We have spec'ed a linux workstation that will cost under $8k to build and can do real-time recons. All components are available on Amazon and NewEgg:		The standalone reconstruction package is shared via a private GitHub repository. Our recon should run on any modern linux system. However, it may be pretty slow (hours per fMRI scan), unless you have a beefy Intel CPU (e.g., a 12-core Sandy Bridge will get you down to 30 minutes or so) and/or good GPU cards (a Sandy Bridge CPU with three Nvidia Titan-X cards will get the recon down to a few minutes and allow it to run in real-time). We have spec'ed a linux workstation that will cost under $8k to build and can do real-time recons. All components are available on Amazon and NewEgg:

	* ASRock X99 Extreme6 LGA 2011-v3 Intel X99 SATA 6Gb/s USB 3.0 ATX Intel Motherboard		* ASRock X99 Extreme6 LGA 2011-v3 Intel X99 SATA 6Gb/s USB 3.0 ATX Intel Motherboard

imported>Huawu at 17:48, 30 March 2021

2021-03-30T17:48:25Z

Show changes

imported>Huawu at 17:42, 30 March 2021

2021-03-30T17:42:18Z

@@ Line 5: / Line 5: @@
 =Overview=
 The CNI, in collaboration with GE, has implemented [http://www.sciencedirect.com/science/article/pii/S1090780713000311 simultaneous multi-slice EPI] (also known as multiband EPI, multiplexed EPI, or, as we like to call it, "mux EPI"). We have functioning sequences for both gradient-echo (GRE) and spin-echo (SE) EPI. GRE-EPI is useful for BOLD imaging and SE-EPI is useful for diffusion imaging and other quantitative anatomical methods.
 ==Calibration Images==

imported>Huawu at 18:51, 30 March 2020

2020-03-30T18:51:49Z

← Older revision		Revision as of 18:51, 30 March 2020
Line 48:		Line 48:

	===Translating to BIDS parameters===		===Translating to BIDS parameters===
	* TotalReadoutTime: EffectiveEchoSpacing * (ReconMatrixPE - 1). EffectiveEchoSpacing is the "ec" in the "descrip" field of NIFTI header. You can get it by running "fslhd NIFTI \| grep ec=". ReconMatrixPE is the y resolution.		* TotalReadoutTime: EffectiveEchoSpacing * (ReconMatrixPE - 1). EffectiveEchoSpacing is the "ec" in the "descrip" field of NIFTI header. You can get it by running "fslhd NIFTI \| grep ec=". ReconMatrixPE is the y resolution. You can also look for "effective_echo_spacing" and "acquisition_matrix" in the json file for these parameters.
	* MultibandAccelerationFactor: "num_bands" in the json file.		* MultibandAccelerationFactor: "num_bands" in the json file.
	* DwellTime: 1/bandwidth. Bandwidth is the "pixel_bandwidth" in the json file, in kHz.		* DwellTime: 1/bandwidth. Bandwidth is the "pixel_bandwidth" in the json file, in kHz.

imported>Huawu: /* Scan parameters */

2019-09-16T23:30:13Z

Scan parameters

← Older revision		Revision as of 23:30, 16 September 2019
Line 29:		Line 29:

	==Useful Parameters==		==Useful Parameters==
	===~~Scan~~ parameters===		===Advanced scan parameters===
	* CV3 - Inplane acceleration (arc factor): determines the ky undersampling. Currently limited to an integer. E.g., 2 will acquire every other ky line.		* CV3 - Inplane acceleration (arc factor): determines the ky undersampling. Currently limited to an integer. E.g., 2 will acquire every other ky line.
	* CV9 - Phase encoding gradient polarity: determines the acquisition direction in ky, usually labelled as pe0 and pe1 in series description.		* CV9 - Phase encoding gradient polarity: determines the acquisition direction in ky, usually labelled as pe0 and pe1 in series description.

imported>Huawu: /* Scan parameters */

2019-09-16T23:29:35Z

Scan parameters

← Older revision		Revision as of 23:29, 16 September 2019
Line 31:		Line 31:
	===Scan parameters===		===Scan parameters===
	* CV3 - Inplane acceleration (arc factor): determines the ky undersampling. Currently limited to an integer. E.g., 2 will acquire every other ky line.		* CV3 - Inplane acceleration (arc factor): determines the ky undersampling. Currently limited to an integer. E.g., 2 will acquire every other ky line.
			* CV9 - Phase encoding gradient polarity: determines the acquisition direction in ky, usually labelled as pe0 and pe1 in series description.
	* CV17 - Number of mux calibration scans: how many internal calibration cycles to include at the beginning of the mux scan, i.e. num_mux_cycle explained above.		* CV17 - Number of mux calibration scans: how many internal calibration cycles to include at the beginning of the mux scan, i.e. num_mux_cycle explained above.
	* CV22 - Number of simultaneously-acquired bands (mux factor): how many slices to acquire simultaneously.		* CV22 - Number of simultaneously-acquired bands (mux factor): how many slices to acquire simultaneously.

imported>Huawu: /* Scan parameters */

2019-09-16T23:21:22Z

Scan parameters

← Older revision		Revision as of 23:21, 16 September 2019
Line 31:		Line 31:
	===Scan parameters===		===Scan parameters===
	* CV3 - Inplane acceleration (arc factor): determines the ky undersampling. Currently limited to an integer. E.g., 2 will acquire every other ky line.		* CV3 - Inplane acceleration (arc factor): determines the ky undersampling. Currently limited to an integer. E.g., 2 will acquire every other ky line.
	* CV17 - Number of mux calibration scan ~~cycles~~, i.e. num_mux_cycle explained above.		* CV17 - Number of mux calibration scans: how many internal calibration cycles to include at the beginning of the mux scan, i.e. num_mux_cycle explained above.
	* CV22 - Number of simultaneously-acquired bands (mux factor): how many slices to acquire simultaneously.		* CV22 - Number of simultaneously-acquired bands (mux factor): how many slices to acquire simultaneously.
	* CV23 - Slice separation (mm): for a contiguous set of slices, this must equal (slice_thickness + gap) * num_slices. (Note that setting this to zero will automatically compute the separation needed for contiguous slices.)		* CV23 - Slice separation (mm): for a contiguous set of slices, this must equal (slice_thickness + gap) * num_slices. (Note that setting this to zero will automatically compute the separation needed for contiguous slices.)