Archive for the ‘Data Acquisition’ Category

Recent advances in in-vivo spectroscopy methods and applications at CNI

July 6th, 2023

Recent advances in In-vivo spectroscopy methods at the CNI

Background

A growing number of people at the CNI are interested in measuring metabolic changes in the brain using in-vivo spectroscopy (MRS) techniques.  Often, they combine this information with functional MRI measurements. The special interest spectroscopy group at CNI  develops and supports new MRS data acquisition and data analysis capabilities, following the recommendations of the at-large MRS community. This message describes the initiatives for education, support of experimental design, guided analyses, and interpretation of MRS data.

Recent spectroscopy results were shared in a poster that we presented at the 64th ENC, the premier conference for nuclear magnetic research (April 16 – 20, 2023). Examples of studies at the CNI using in-vivo spectroscopy techniques include characterization of biomarkers following transcranial magnetic stimulation, and metabolite characterization for conditions such as addiction, pain, depression, and various forms of dementia. Published, collaborative studies performed at CNI include

  • method applications (DeSouza DD, Stimpson K, Baltusis L, Sacchet MD, Gu M, Hurd R, Wu H, Yeomans DC, Williams N, Spiegel D. Association between anterior cingulate neurochemical concentration and individual differences in hypnotizability. Cerebral Cortex, Volume 30, Issue 6, June 2020, Pages 3644–3654),
  • new method developments (Gu M, Hurd R, Noeske R, Baltusis L, Hancock R, Sacchet MD, Gotlib IH, Chin FT, Spielman DM (2018) GABA editing with macromolecule suppression using an improved MEGA-SPECIAL sequence, Magnetic Resonance in Medicine 79:41-47),
  • participation in multi-site spectroscopy studies (Hui et al. Frequency drift in MR spectroscopy at 3T, NeuroImage 241(2021) 118430), and
  • a recent paper regarding voxel placement method development (James H. Bishop, Andrew Geoly, Naushaba Khan, Claudia Tischler, Ruben Krueger, Poorvi Keshava, Heer Amin, Laima Baltusis, Hua Wu, David Spiegel, Nolan Williams, Matthew D. Sacchet Real-Time Semi-Automated and Automated Voxel Placement using fMRI Targets for Repeated Acquisition Magnetic Resonance Spectroscopy, Journal of Neuroscience Methods 392 (2023) 109853.

Technical notes

Here is a description of the specific methods we now support.  If you are interested in learning more about these methods, or using them, please consult with Laima Baltusis.

  1. Experimental spectroscopy data acquisition methods continue to evolve. Currently the semi-LASER sequence is the ISMRM (International Society for Magnetic Resonance in Medicine) consensus method, particularly for multi-site 3T MRS studies. We have, therefore, transitioned studies at CNI to the semi-LASER sequence (a GE WIP (Works-in-Progress)) for both single voxel and to MRSI studies. The ENC poster presents both single voxel and new focal 2D MRSI results using the semi-LASER sequence in challenging and therefore less well studied but important areas of the human brain such as the basal ganglia regions. This region is often studied by investigators trying to understand movement, cognition, and emotion, and the single voxel data in this region has been of lower quality. To improve the data quality, and measure small metabolite differences in subregions of interest, we optimized a focal 2D MRSI data acquisition method (presented in the poster). The improvements for focal 2D MRSI and single-voxel MRS includes B0 shimming, encoding and acceleration methods, spatial selection, water suppression, extracranial lipid suppression, and RF (Radio Frequency) performance.
  2. In addition, current basic data reconstruction and visualization can employ SAGE, a GE proprietary analysis and visualization tool with LCModel used as a separate module for data fitting. The next phase of this particular research project will continue to explore additional optimizations of data collection but will focus more on data processing for optimal quantification of metabolites. Areas of study will include improvements in data analysis using LCModel by (1) mitigation of baseline and macromolecular contributions for data analysis with LCModel and (2) improvement of the accuracy of the LCModel basis set by the addition and validation of experimental lower concentration metabolites (glutathione and ascorbate, as examples) to an otherwise synthetic LCModel basis set. The use of Bayesian analysis will also be explored as a technique to remove the broad baseline and macromolecule content without bias. We anticipate presenting these findings at the 2024 ENC conference.

 

UHP Upgrade Update (Continued)

November 8th, 2020

1. Introduction

Good news — after a lot of hard work over the weekend by the CNI staff, we are most of the way back to normal operation with our upgrade to GE’s RX28 release.  The significant accomplishments over the weekend include solving the issues with the research SMS sequences as well as the spiral fieldmap sequence.  These are all operational again and the new sequences are fully integrated with Flywheel.

There are a few minor changes to the user interface with this revision of the scanner operating system and we describe these below.

2. Coil Selection

The tab for receiver coil selection has changed in RX28. Instead of a list of connected coils and checkmarks for indicating which coils are selected to be used, the new interface shows each port of the coil connection and highlights which ports are active. By default the Nova 32ch Head coil will have both Port P1 and Port P2 selected (as shown in the screenshot below).

3. Product Hyperband Updates

The Hyperband sequences on RX28 now have built-in calibration scans. The calibration can be integrated into the prescan of each Hyperband scan, so there is no need to do a separate ASSET Calibration before the Hyperband scans. The integrated calibration scan is turned on by default (as shown in the screenshot). If it is turned off, a separate calibration scan (named “Cal: [original series description]“) will be created automatically once the Scan button is pressed.  The Hyperband BOLD sequence also no longer requires an even number of slices / band to be acquired so it will improve the efficiency of some prescriptions over that in RX27.  In addition, the slice timing is correctly calculated and stored in the DICOMs. We will work with the developer of the dcm2niix utility to extract these timings and save them to the accompanying JSON file – a fix was needed because the developer had disabled this feature for GE Hyperband DICOMs given the erroneous timing values that were present for versions earlier than RX28.

RX28 UI Hyperband

4. High-Order Shim

GE has switched from a spiral-based acquisition for their high-order shim (HOS) process to a 3D fast gradient echo acquisition.  Users will need to replace their existing HOS series in their protocols with the new HOS template.  This can be accessed by first choosing Add Task, then selecting the GE protocol library, choose Adult->Other in the lefthand tabs and then select the hosGE entry.  We suggest using the GE HOS FOV28 template as this will most likely include all of your subject’s brain while still providing reasonable resolution. This new 3D FGRE approach may have modest benefits when subjects have significant B0 inhomogeneity due to orthodontics or large sinuses.

5. Remaining Tasks

As mentioned in our previous post, we will try to get the new coil configuration format for the NOVA16 research coil next week.  We are also working with Gary Glover on getting his spiral in/out (sprlio) pulse sequence installed.  The “show” system in the corner of the CNI scan room near the large TV screen is still running RX27 but we hope to update to RX28 in the next couple of weeks.

Thanks for your patience as we worked through this upgrade. We expect future s/w upgrades to be simpler now that the UHP is more closely integrated into GE’s standard product software.  Please don’t hesitate to contact us if you have any questions when using the new system.

Thanks and stay safe!

The CNI Team 

Update on Physiological Data Association in Flywheel

October 23rd, 2020

Dear CNI Users,

In August we wrote to you regarding a problem we found within the CNI Flywheel instance (cni.flywheel.io). In some cases the physiological data (respiratory and cardiac waveforms) from the scanner were not matched to the correct acquisition in Flywheel, or were not uploaded at all. We have determined that such failures occurred most often when a scan ended prior to the prescribed acquisition duration, The matching logic within the reaper used the duration information.  In some cases the mis-match led the reaper to associate the wrong physiological data with an acquisition; in other cases no match was found and thus no physiological data were uploaded.

We maintain backups of the physiological data, and this is enabling us to correct the association of the physiological data with its proper acquisitions. The restoration has been ongoing in the background for some time, and we expect to complete the process within the next couple of weeks.

Incorrectly associated physiological data in an acquisition will remain within the acquisition and be renamed using the following convention:

 <exam>_<series>_<acquisition>_original.gephysio.zip

Projects in which we found one or more acquisitions containing incorrect or missing physiological data will have a CSV file attached to the project. The files will be named using the following convention:

physio_fix_<group_name>-<project_name>.csv

Those ‘fix’ files will contain detailed information describing each acquisition that had physiological data associated with it. The contents of the file are described at the end of this message.

Please note that physiological data is only automatically associated for EPI-type sequences. If you store physiological data for other sequence (e.g. T2 spin-echo, T1-weighted fast gradient-echo, etc.) then you will need to manually upload the physiological data to Flywheel if you’d like it kept with your acquisition.  Please contact us directly if you have questions about this process.

We appreciate your patience as we work through this issue. If you have any questions regarding this process, or concerns about the data that have been restored to your sessions, please reach out and let us know either via email or Slack.

Contents of the ‘fix’ file

The ‘fix’ file is a text description (CSV) about the corrected physiological data.  It includes:

  • Session ID – A string representing the Flywheel Session ID
  • Acquisition ID – A string representing the Flywheel Acquisition ID
  • Flywheel Path - A human readable string showing the path to the acquisition in Flywheel
  • FIX Status – A string indicating whether the new data were ‘found’ or ‘replaced’
  • Message – describing the action performed, or an errors during execution.
  • Exam – Exam Number
  • Series – Series Number
  • TR – A number defining the TR of the acquired data in milliseconds
  • NTP – An integer defining the  number of temporal samples in the physiological data file
  • RAW NTP Number of temporal positions (from the DICOM or PFile header),
  • Scan Duration – Calculated scan duration
  • PPG_Samples - the number of Physio Samples
  • PPG_Lines_Expected – the number of lines we expected in the PPG file
  • PPG_Lines – the number in samples found in the PPG file found in Flywheel (if applicable)
  • PPG_Lines_Fix – Number of sample found in the Matched/Fixed data,
  • DELTA_FIX_EX – the difference between the fixed data and what was expected
  • DELTA_FW_EX – the difference between what was in Flywheel and what we expected
  • Date and Time – of the acquisition
  • FIX Time Delta Difference between expected timestamp and FIX file timestamp in Sec
  • FW Time Delta Difference between expected timestamp and FW file timestamp in Sec
  • FW File Base Base file name of data found in Flywheel
  • Regx – The regular expression used to find the matched data

Thanks and stay safe!

The CNI Team

Hyperband Transition

September 14th, 2020

Executive Summary

The GE product Hyperband BOLD and diffusion sequences are a result of close collaboration between GE scientists and engineers with the CNI staff.  The CNI SMS implementation, which we called the “MUX” research sequence, served as a resource and a benchmark for the GE Hyperband product.  Over the last several months Adam and Hua worked with our partners at GE to resolve a limitation of the initial Hyperband implementation. We are glad to report that the two sequences now have the same SNR (signal-to-noise ratio).  We describe the testing that convinced us and the benefits below.  With this improvement, we plan to move CNI users to the Hyperband sequence, which will offer many benefits. Specifically, we ask all users of the UHP system to migrate any protocols using the research MUX sequence to the product Hyperband sequence.  We do not plan to support the research MUX sequence in future releases of the GE platform.  Instead, we will coordinate with GE on improvements to their Hyperband product.

Advantages

The main benefit for researchers moving to the Hyperband product sequences is that GE’s product releases are fully integrated with other system improvements. The CNI cannot achieve the same level of integration when we port the MUX research sequences.  For example, GE’s product Hyperband sequences are fully integrated with the reconstruction engine.  For this reason unaliased images show up in the mini-viewer and are stored in the image database which makes it possible for operators to immediately detect image quality issues.   Second, CNI’s resources for testing and migrating research sequences each GE system update is limited.  GE’s product sequences go through rigorous in-house acceptance testing with each new release.  Third, by moving to the product users will also benefit from all other system developments for the baseline EPI product (higher-order eddy current correction, bug fixes, etc.).  Fourth, the product sequence includes seamless integration with the User Interface so users simply prescribe whole-volume slices as normally.  Fifth, the product delivers near real-time reconstruction, rather than the slower reconstruction used by the research MUX sequence.

Image quality

We did not recommend using Hyperband until now because testing showed that the GE product SNR was 30% lower than the MUX performance.  The reasons for this SNR drop have been determined by CNI staff, and these corrections are now incorporated into GE’s future product releases.  We also incorporated these fixes into the CNI versions of the base sequences on our system, namely cni_epi and cni_epi2 which correspond to the Hyperband BOLD and diffusion sequences.  These improvements are why we now recommend shifting to the Hyperband sequence.  The shift will enable users to take advantage of integration with the other features of the GE platform.

Our assessment is based on several sets of SMS BOLD and diffusion data across multiple GE systems, including phantom and human subject data.  We acquired on the previous CNI MR750 scanner and the new CNI UHP scanner, as well as on the product sequences compared to our research sequences.  These data are all available on the CNI Flywheel site in the scanner_comparison project which is accessible by all CNI flywheel users.  A brief summary is provided here.

The figure below shows the detrended SNR determined across 50 timepoints for a region at the center of a phantom image acquired on our UHP scanner using the Nova 32-channel coil with both research and product SMS sequences.   The Hyperband sequence shows slightly improved for all non-unity SMS acceleration factors except for the SMS factor 8.  We hypothesize that these variations may be due to the different approach used between CNI and GE SMS sequences in acquiring calibration data to determine how to unalias the data.  CNI sequences generally acquire calibration data at the beginning of the BOLD acquisitions while GE uses a fast separate calibration sequence to acquire this data.  We will continue to investigate the source of this SNR drop at SMS 8, but given the performance at the normal acceleration factors that are used we are not concerned.  The SNR is also still quite high from an absolute perspective, and it is likely physiological noise would be of more concern in an in vivo experiment.

 

The following figure shows results acquired using the MUX research sequence across multiple platforms at Stanford.  The data were acquired using different Nova 32 channel coils that were available at each site.  As a result only data acquired at CNI used the same receive array, and this shows a substantial increase in detrended SNR when moving from the CNI MR750 system to the CNI UHP.  The Lucas 3T Premier system has higher SNR, and we hypothesize this is due to the receive array.  We will be following up with a future experiment to using the CNI coil on the Lucas Premier system.These SNR values are all quite high however, and likely data will be dominated by physiological noise for in vivo data.  Even so, we are considering recalibrating or purchasing a new coil.

 

We also evaluated the Hyperband diffusion sequence in terms of baseline SNR and artifact.  The following figure shows compares the research and product SMS sequences when using a whole-volume acquisition of an agar phantom with an SMS factor of 3 and no inplane acceleration.  A nominal b-value of 2800 was prescribed but the diffusion tensor file hand-edited to acquire 50 b0 images that were used to calculate the SNR.  We measured using a peak gradient amplitude of 50mT/m for the diffusion encoding lobes and for the product Hyperband sequence we also measured with a peak gradient amplitude limit that takes advantage of the UHP capabilities, at 100 mT/m.  In this last instance the echo time (TE) for the acquisition is significantly reduced due to the shorter diffusion encoding lobe durations that are required. As shown below, the Axial, Sagittal and Coronal reformats of the data all show good unaliasing and no noticeable banding artifacts.  The SNR for instances when the gradient amplitudes are limited to 50 mT/m are comparable across the MR750 and UHP regardless of whether our research or product SMS sequence is used.   The last measurement with the peak gradient at the UHP limit of 100 mT/m shows an appreciable SNR gain due to the shorter TE.

CNI staff are engaged with GE scientists to investigate different reconstruction approaches that will improve the product Hyperband sequence and reconstruction.  The current product uses a reconstruction method analogous to 1D-GRAPPA;  we are investigating a method analogous to split-slice-GRAPPA.  This latter reconstruction method shows no benefits as of yet, and requires considerably more computation and is not available for real-time reconstruction on the scanner.  Given the performance of the existing product reconstruction method we are confident in recommending its adoption.  At the same time, we will continue to work with GE to investigate possible improvements.

The scanner_comparison project on Flywheel has more data analysis than we’ve reproduced here, and raw data is also available should users be interested. While there is undoubtedly more comparisons that could be performed, there is evidence that the performance matches our research sequence performance, and there are other benefits offered to researchers by moving to the product Hyperband sequences which are significant.  These data and the general considerations are why we now recommend researchers switch to Hyperband.

Transition Assistance

CNI staff will be available to help with transitioning protocols to using the Hyperband product. Given the full integration of these sequences with the user interface and reconstruction we’re sure that users will find it a very easy transition to make.  If warranted we’ll add a channel to our Slack workspace for Hyperband to help with common questions (and yes, if you’re not on the CNI Slack workspace, please sign up now — see https://cni.stanford.edu/slack-and-volunteers for details).

CNI upgrade planning

July 2nd, 2019

Planning for an MRI scanner upgrade at the CNI

The MRI scanner we have (GE DVMR 750) is about 8 years old. There have been advances over the years that we incorporated through compute infrastructure and software. It is now time for us to consider the opportunity for a hardware upgrade.

In anticipation of the hardware upgrade, we participated in GE’s ‘Evergreen’ program. This is a technology non-obsolescence agreement.  The path we were on was to upgrade to the GE Premier 3.0T, a system that you can see in Lucas as 3T2.  That system has some computational upgrades, more receiver channels, and a wider bore.

A second option has emerged that the CNI staff believes is preferable.   GE is marketing this upgrade as the DVMR 750 Connectome plus Edition*.  The Connectome plus includes most of the computational elements of the Premier.   In addition the upgrade replaces the gradient coils and drivers with a new system that has better performance in two ways. The coils generate a higher gradient (50 mT/m for the DVMR 750 and 100 mT/m for the Connectome plus), and the coils are more stable with respect to heating.

The CNI team thinks that the Connectome plus will be a better technology choice for our community. We also believe that the Connectome plus upgrade will help PIs justify the equipment infrastructure when they write grants, enabling them to correctly claim that the GE equipment is competitive with the best Siemens products.

The same decision is being faced by our colleagues in other departments; it is our understanding that other groups also are planning to install Connectome plus systems.

Hardware down time planning

We are planning to be closed for data acquisition from January 6, 2020 to the end of February, about six months hence.  Stanford’s financial rules and the contract with GE leaves us with very little flexibility in when the upgrade can take place.  We will try hard to get the system online by February 21, 2020 for protocol testing.  Please remember that this is a major install and there is always some uncertainty about timing.

You may remember that this timing differs from what we anticipated during our community meeting last fall.  At that time we hoped to do the upgrade during the winter closure.  That turns out to be impossible because, well, people want to visit with their families.  We fully understand and hope you do, too.

During the next six months we will help labs plan for the down time and transition to the new system. We will send additional messages that describe how we will collaborate with the Lucas Center to make it possible for some studies to be carried out there; and, we  will collaborate with GE to quantify the system performance to help understand how to best extend longitudinal studies.

* Some people refer to this system as the Ultra High Performance (UHP) system

 

Flywheel: Part Four

August 29th, 2018

Flywheel

We are on track to switch over to Flywheel on Saturday, September 1.  As of that day, new data collected at CNI will not be placed in NIMS.  New data will be sent  to Flywheel directly (https://cni.flywheel.io).  NIMS will be kept online as legacy only.

Logins for the Flywheel site is managed by Stanford authentication, via Google. So to login click the ‘Sign in with Google’ button.

 

Login page of the Flywheel data management system

Login page of the Flywheel data management system

 

Freezing NIMS

Users often make changes to NIMS after data are uploaded, so we will permit edits (e.g., notes) until Saturday, Sept. 8th.  However, any edits made after August 31 will not be automatically carried over to Flywheel (which we have been doing).  After Sept. 8th we plan to freeze the NIMS database and make it read-only.

Data from October 1 2018 are already in the new Flywheel system.  NIMS contains about 7 years worth of legacy data.  Over the next year we plan to migrate all the NIMS data into Flywheel as well. If you would like specific Projects in NIMS integrated sooner, please let us know.

NIMS-FS

People who use NIMS-FS (through the CNI Linux Containers) should note that no new data will be accessible through that mechanism. Those wishing for “command line access” to CNI data will need to use a different technology.  The Flywheel CLI (command line interface) is an option for those of you who have used the features in NIMS-FS.  The CLI has methods for importing and exporting data from your authorized projects, and it runs on multiple platforms.  The CLI can be downloaded from your profile page within Flywheel. If you’re interested, please contact Michael Perry for instructions about how to install and use the Flywheel CLI.

- The CNI Team

 

Flywheel: Part Three

August 6th, 2018

Thanks to all of you who have started to take a look at the Flywheel data management system. A few notes and reminders.

1.  We are still on track for a September 1 change over.  Having said this, Michael is considering transitioning a little bit sooner.  The reason is that the very heavy use of the scanner this month is stressing the limits of our NIMS storage.  But we may be able to make it to September 1st with both NIMS and Flywheel running.

2. Starting this week, Michael will join Laima for a portion of the new user training to explain the Flywheel interface .  Knowledge is viral around this place – so check with new users, Michael, and Laima if you have questions.  And pass on what you learn.  There is also a plan to step up the documentation by mid-September.

3.  A number of people have asked us about the Flywheel technology.  Here are a few principles.

Cloud. The Flywheel system (https://cni.flywheel.io) is on the Google Cloud Platform.  This is an advantage to the CNI because we no longer have to maintain computers and back up the data.  In the cloud we can leverage (and pay for) more computing power for a short time if there is a big or rush job.  So far, our experience with pricing is good.

Data storage. The CNI has more than seven years of data including more than a 100,000 acquisitions.  The size of the data has increased dramatically with the new SMS sequences that many of you use (ask me why when you take my class). We have always worried about the cost of storing the data.  The largest files (e.g., the P-files) comprise almost 80% of our storage and these data are rarely used.  The Flywheel system uses ‘object storage’, which is the least expensive type of storage. Rarely accessed files drift off into ‘cold storage’, which is particularly inexpensive. This should prove to be cost effective for us while still allowing us to reconstruct data that was collected even a few years ago.  Which we have done for some users!

Computation.  The computations performed by the Center Edition run in  a simple framework that Flywheel calls a Utility Gear; this is a Docker Container coupled with a format for setting the program parameters.  Flywheel jobs, such as reconstructing SMS scans, or converting a file from DICOM to NIfTI, are carried out by Utility Gears.  In the cloud, we can invoke multiple Gears at once on many machines that are  provided temporarily (cloud scaling).  We pay for the machines only for the few minutes or hours they are in use.  Cloud-scaling is useful when we have to run a lot of jobs – such as re-running multiple recons to fix an error or improve an analysis. This functionality provides us with greater scalability and performance than we could provide through the computers we purchased with grant funding.

4. To install Flywheel, the CNI team had to keep NIMS running and develop a system to convert seven years of prior data; Michael has done a great job with those tasks. CNI is not the first site to run Flywheel on the Google Cloud because those sites had no legacy storage.  When we fully switch over, the CNI installation will be the largest by far, and we are determined to be the best! Go Cardinal!

 

NIMS transition to Flywheel: Part Two

July 17th, 2018

Main point

The Flywheel data management system has been running smoothly for several months at the CNI.  The main purpose of this message is to encourage you to explore Flywheel (https://cni.flywheel.io). A number of groups have already switched from NIMS to take advantage of Flywheel’s features. After Michael completes further testing, which we anticipate to be around September 1, we will stop sending new MRI data to NIMS and instead send data directly to Flywheel (see note). So this is a good time to learn about the new system.

During the Fall we will hold informal sessions at the CNI to explain the system and its features. We will also write more blog posts to explain the system and what motivated us to make the transition.

About Flywheel

Flywheel offers two levels of service, the Center and Lab Editions; the CNI runs the Center Edition. This version does all  the things that NIMS does, including automatically uploading data (e.g., P-files (raw data), DICOM data, and Physio data) and converting data to NIfTI format, which is what most users download.

The Center edition also has features that exceed what NIMS could do. Below is a partial list of Flywheel features that are relevant to CNI users.

  • Session Templates – For each project you can set up rules that automatically check that the expected data were collected, and flag sessions with missing data
  • Notes - Add notes about a session or acquisition (e.g., subject moved; life is good; buy milk)
  • Elastic Search – Find specific types of data, notes, and more
  • Visualization – Flywheel includes viewers for many types of data (NIfTI, DICOM, EEG, OBJ,  CSV, etc.)
  • Collections – Gather data from multiple projects to form a Collection of data
  • Permissions – Adding and removing access to users is simpler, and there are different permission levels available
  • Upload – You can add behavioral data, say from REDCap or or your own notes, to an existing session
  • Gears – Users can run one of a set of Utility Gears (Analysis Gears are available in the Lab Edition)
  • Gear Rules – Users can determine which set of Utility Gears are run on their data. For example, want to use dcm2niix for your DICOM data? Simply setup a Gear Rule to execute dcm2niix for all DICOM data coming in to a given project (ask Michael to show you how, or have a look at the doc).

There are many other features we think CNI users will benefit from. Please explore the interface and browse the documentation available in the UI.

Finally, please reach out to Michael Perry (lmperry@stanford.edu) if you have any questions or experience issues with the platform. In this early phase we expect things to come up and we welcome the opportunity to help navigate through this transition.

Note:  During this testing phase there is a delay before the data appear in Flywheel. Most data are uploaded first to NIMS, where we start most reconstructions and data processing. When testing is completed, in September, Flywheel will handle all reconstructions and data processing while NIMS will switch over to an archival mode.

The CNI Team

NIMS Transition to Flywheel: Part One

February 9th, 2018

BACKGROUND

When planning the CNI we committed to providing the community with data management services. As many of you know, most MRI centers do little more than hand the user a DVD at the end of the session, and wish them well. CNI users are supported much more extensively. Data acquired on our scanner are immediately transferred to the Neurobiological Image Management System (NIMS). Once in NIMS, the data can be reconstructed and converted into the formats that most of our community uses (e.g., NIfTI). These are the data that most users download and use in their research.

Over the years the CNI community has accumulated a great deal of data. NIMS contains the work of about 900 researchers. These data comprise more than 15,000 sessions from more than 6,000 subjects. There are more than 45,000 fMRI scans, nearly 100,000 anatomical scans, around 5000 diffusion scans and over 500 spectroscopy scans.

The CNI remains committed to supporting the research of its user community by providing state-of-the art data management. To this end we are excited about transitioning from NIMS, our home-grown data management system, to Flywheel.

THE ISSUES

Over the years there have been a series of updates to NIMS to accommodate the growing data set. In addition to updates to the NIMS software itself there have been several hardware upgrades over the last few years, including both increased storage and increased computational power; we were fortunate receive grants to support improvements from the Neurosciences Institute. At present NIMS is comprised of a 200TB main file server and a 200TB off-site backup file server, three compute servers (with more than 80 cores, 2TB of RAM, and 14TB of SSD scratch), and a powerful web server, all interconnected by a 10 Gigabit network. The NIMS hardware and associated software are maintained by Michael and the CNI staff.

The support, both physical and financial, of this system is a burden on the CNI. Some of you have may have experienced the limitations of NIMS with regard to data reconstructions, or the limited feature set around search, sharing, and permissions, or downloading bulk datasets, or other missing features that fall into the “Wouldn’t it be nice if…” category.

THE SOLUTION

Over the last few years a number of us (Wandell, Schaefer, Dougherty, Perry, and others) were supported by the Simons Foundation to design the next generation of NIMS. This project (The Project on Scientific Transparency) has also been supported by and integrated with the work being done by Russ Poldrack and Chris Gorgolewski (OpenfMRI) – supported by the Arnold Foundation. This joint effort culminated in the development of an open-source framework to support the next generation of data management – SciTran.

Flywheel has adopted SciTran and engineered a modern user interface and infrastructure that makes it easy to use, maintain, and scale. Flywheel has a multitude of new features over NIMS; runs on Google Cloud Platform; and has a sustainable support strategy.

We will be describing Flywheel more fully in the coming weeks, first reaching out to lab managers and individual groups with the goal of rolling it out to the user community broadly in the coming months. We look forward to working with all of you to make the transition smooth and to help you take advantage of new opportunities that are enabled by the next generation system.

 

See you around the magnet!
- The CNI Team

CNI scanner upgrade to DV26

November 9th, 2017

After weeks of testing, the CNI will upgrade the scanner’s software to DV26 on Monday, Nov 12, 2017. All existing protocols will be migrated to the new platform, and we fully expect they will perform as they do on the current platform. Data will continue to be stored in NIMS as they are now as we continue to make progress on migrating NIMS to our new data management platform, Flywheel (more on that soon). Please contact us if you notice any issues with your protocol or data.

The DV26 interface will feel a whole lot like the current platform (DV25), so we don’t expect any of you to be disoriented when we switch. There are, however, some very minor differences that we want you to be aware of.

SAR limit settings. What follows are step-by-step instructions for setting the SAR limit in DV26 — note that these changes don’t affect most sequences:

  1. When starting an exam, in the dialog window for selecting operating mode the first level dB/dt and SAR limit are selected by default: you can click the “Accept” button directly to enter the exam unless you want to change the operating mode.
    dv26_start_exam
  2. By default the system will automatically run a “SAR Scout” scan for SAR limit calculation before the localizer in each exam. This scan will show up in the list of Task as series 0. The Scout is 6s long and doesn’t generate images.
    dv26_SARscout

Spectroscopy. If you are using spectroscopy sequences, please refer to the CNI wiki for a description of how to prescribe a rotated voxel acquisition. GE has committed to working on a solution which does not require this workaround, but we don’t yet have an expected date for when this will be available.

SMS BOLD and DTI. Our current SMS BOLD and DTI sequences (muxarcepi and muxepi2) will be available, and they will still work as in DV25. While the DV26 software supports the product SMS DTI sequence known as Hyperband DTI, we recommend users to continue using our research sequences until we have had the opportunity to fully evaluate the Hyperband DTI sequence.

 

Laima measures GABA

August 31st, 2017

You may have been wondering about Laima’s experimental work over the last few years.  You can now read about it in a paper co-authored by folks who work at the CNI, GE, and Lucas.  Nice collaboration!

GABA editing with macromolecule suppression using an improved MEGA-SPECIAL sequence
Meng Gu, Ralph Hurd, Ralph Noeske, Laima Baltusis, Roeland Hancock, Matthew D. Sacchet, Ian H. Gotlib, Frederick T. Chin, Daniel M. Spielman (http://onlinelibrary.wiley.com/doi/10.1002/mrm.26691/full)

 
Sincerely,
The CNI Team

Upgrade Plan for DV26

August 28th, 2017

Executive summary

We will be upgrading the GE software and computational infrastructure in late September (from DV25 to DV26). The reasons and implications for your projects are explained below in detail.

To migrate the CNI sequences to this new environment, the CNI development team needs time on the scanner (we estimate about 12 hours).  As most of you know, the schedule is very full. Thus, starting September 1st and continuing for a few weeks, the CNI will have priority for any released time and all protocol development time.

If you have already booked protocol development time, we may contact you to negotiate an alternative slot. We will return to a more open policy after the transition is completed. Thank you for your cooperation.

Background

Like many GE sites, we are now planning for a significant upgrade.  This upgrade, DV26, includes new computational hardware and software (but no new MR gear, such as coils or gradients).  This upgrade includes features that will eventually be valuable for many of you.

At minimum before we make the upgrade, we will be making sure the existing CNI-modified sequences (cni_epi, cni_epi2, muxarcepi, muxarcepi2, sprt, cni_3dgrass, cni_efgre3d,  cni_ir_epi and Probe-MEGA) will all be working at DV26 as they do at DV25, together with offline reconstruction for the mux and spiral sequences using NIMS.  Other existing product sequences are not noticeably changed in this upgrade. As a result, the transition for users should in most cases be seamless.

A beneficial feature of the new system is that GE has incorporated the SMS methods that were implemented by Adam, Kangrong, Bob, Hua  and Matt Middione (GE) at the CNI.  GE refers to their implementation as Hyperband (love the marketing folks; multiband was not enough).  The DV26 product includes only a Hyperband DTI sequence, but GE has agreed to enable us to use a beta version of the Hyperband fMRI sequence.

The user-interface for Hyperband will operate as any normal sequence. Simply prescribe the whole volume you wish to acquire and the online reconstruction will perform the slice and inplane acceleration unaliasing so that undistorted images appear in the mini-viewer and scanner image database. The new computational hardware from GE will perform these reconstructions, eventually reducing the burden on our aging CNI computers.

However, there are some limitations of the new product Hyperband sequences.  GE has not yet implemented our preferred reconstruction algorithm for Hyperband acquisitions (split-slice GRAPPA). Also, there are some support features in the CNI versions of these sequences (e.g. triggering selection) that are not in the product Hyperband sequences.  The CNI team will make modifications to these Hyperband sequences to support the specific CNI features as well as augment the product reconstruction.  Some of these updates, in particular supporting online split-slice-GRAPPA reconstruction, will not be completed until after our migration to DV26.

As a result of these limitations to the Hyperband sequences, and until we have the opportunity to confirm these sequences have the same performance of our existing SMS sequences, we advise users to continue to use the CNI SMS sequences (muxarcepi, muxarcepi2). However we expect that we will be able to recommend users migrate to these Hyperband sequences sometime later this year.  We will keep you posted on our progress.

The CNI Team

Optimizing image quality: Fieldmaps and shimming

April 9th, 2017

Acquiring a high quality fieldmap of the mean magnetic field is crucial to obtaining a good measurement.  Making sure you set the parameters so that this field map is obtained as part of your protocol is something we help you with.  There are cases, including new sequences, where this can require some extra attention.

The problem: The CNI team recently helped diagnose a confusing fieldmap result.  The user was acquiring a fieldmap using a spiral acquisition, but without first performing a high-order shim (HOS) acquisition or setting Autoshim (linear-order shim).  They subsequently acquired EPI data with Autoshim.  This resulted in acceptable imaging quality but also created some problems. The disadvantage was that high-order shim corrections were not used, and the spiral fieldmap data did not incorporate the linear-order shim corrections that were imposed by the Autoshim.  As a result, the data quality were not optimized.

The solution: We recommend that a HOS be acquired as part of your protocol, especially when EPI sequences are used for subsequent data acquisition.  We describe these procedures on our Wiki entries, as well as some troubleshooting steps in a blog entry:

http://cni.stanford.edu/wiki/MR_Protocols#HOS_WB_HRBRAIN
http://cni.stanford.edu/wiki/Troubleshooting#HIGH_ORDER_SHIMS_.28HOS.29
https://cni.stanford.edu/high-order-shim-errors/

If this overhead is too time-consuming, then it is important to ensure an Autoshim is acquired, which performs a linear-order shim correction. Please note: when Autoshim acquisition is set to “Auto”, and an HOS is acquired, the system should use the HOS acquisition rather than acquire a new linear correction.

Some details: A variation in the B0 main field from the desired B0 leads to an image shift in the phase encode direction of EPI acquired images.  When the B0 field is spatially varying, this leads to varying image shifts which can result in signal pileup, voids, and image warping. There are two methods described in our Wiki for correcting these distortions.  First, you can repeat your EPI data acquisition twice, with a reversal of the phase-encoding direction between data sets as we describe in a Wiki entry: CNI Data Processing

Secondly, you can acquire an explicit fieldmap using the spiral fieldmap sequence and then process the subsequently acquired EPI data as described in another Wiki entry: Fieldmaps

Please note that if the explicit fieldmap correction approach is adopted, it is important to ensure that the subsequent EPI acquisition does not modify the shim corrections.  In this case setting Autoshim to “Off” in your protocol would be advisable.

 
Adam and Hua

Updates for multiband reconstruction

March 15th, 2017

The CNI has recently introduced a new option for reconstructing SMS (aka, multiband or mux) scans. The default reconstruction method in the SMS reconstruction pipeline is currently 1D-GRAPPA (Blaimer M. et al. MRM 2013). Based on recent research and testing, we believe that the split-slice-GRAPPA (Cauley SF, et al. MRM 2014) reconstruction algorithm does a better job at unaliasing the simultaneously acquired slices, especially in cases where the calibration data are corrupted by subject motion. This more robust unaliasing will help reduce the chance of false correlations in fMRI scans by reducing signal leakage across aliased slices.

Another advantage of the split-slice GRAPPA method is that it is less dependent on the image contrast being consistent between the calibration data and the SMS data, therefore it allows more flexibility in choosing the best calibration scans. So, we have also introduced a new SMS calibration scan option – using a separate single-band scan as an external calibration for the target SMS scan. Most of you doing SMS are using internal calibration, i.e. the first few volumes integrated in the SMS scans are used as the calibration data. And a few of you are doing an external calibration that has the same SMS (mux) factor as the target scan. Compared to these calibration methods, the single-band external calibration has higher SNR in the calibration data and is less sensitive to subject motion during the calibration. Therefore we believe it is a more robust calibration method, and in combination with the split-slice-GRAPPA reconstruction method, is likely to produce better image quality for the SMS scans, especially when you have wiggly subjects.

Here is a compelling example of how the single-band calibration scan can reduce a particularly insidious artifact due to excessive eye motion during the calibration scans (this subject was instructed to intentionally move their eyes during the calibration scans). In these standard deviation maps of the BOLD timeseries, the aliased eye artifact is clearly visible in the 1D GRAPPA reconstruction (top). The split-slice GRAPPA reconstruction (middle) shows a reduced eye artifact in the white matter, but there is still significant aliasing of the eyes. This aliasing is substantially reduced or eliminated in the same data reconstructed using a single-band calibration scan with split-slice GRAPPA (bottom), even though that also had subject eye movement.

s1_grappa
s1_ssg
s1_sbref

However, in cases where there is no excessive motion during the calibration, all the methods are quite comparable:

s2_grappa
s2_ssg
s2_sbref

The CNI SMS data processing pipeline will by default keep using the original 1D-GRAPPA reconstruction method for continuity of ongoing studies. And if you have compliant subjects who remain still, ideally with eyes-closed during calibration, this method should be fine. However, if you think your subjects may move during calibration, then we recommend switching to split-slice GRAPPA for image reconstruction. And you may also consider adding a single-band calibration scan to your protocol. Any SMS scan that doesn’t have a separate calibration scan setup in the same scan session will also be reconstructed using the internal calibrations. In order to use the new methods, you need to do the following in your protocol:

To use the split-slice-GRAPPA reconstruction method, include the keyword “_ssg” at the end of each series description that you want to be reconstructed with split-slice-GRAPPA. Note that this also enables SENSE1 coil combination (Sotiropoulos et. al., MRM 2014).

To use the single-band calibration, you need to set up a separate scan with SMS (mux) factor = 1 (CV 22). Include the keyword “_sbref” in the series description. This single-band scan needs to have the same coverage as the multiband scan, i.e. the same FOV and matrix size but X times the prescribed number of slices, X being the SMS (mux) factor. You will need to increase TR (by a few seconds) in order to accommodate all the slices in one TR. You only need 4 or 5 phases for this scan. Because the TR will be longer, you can set the flip angle to 90 to optimize SNR.

For scans using the single-band calibration, the calibration volume is not included in the reconstructed images, i.e. the NIFTI files will only contain the SMS volumes. This information is also shown in the JSON file that now accompanies all SMS NIFTI files in NIMS. The JSON file contains a list of important parameters related to the scan and the reconstruction.

Please contact Hua or Bob if you have any questions and/or want help setting up these new SMS features in your protocol. Also, we owe thanks to the Wagner and Poldrack labs for help in testing these new methods.

Planning for hardware upgrades

May 23rd, 2016

The CNI is planning for a significant equipment upgrade, which we expect to be available in about a year. This message describes our plans, which are rather uncertain. Despite this uncertainty, we thought it best to write this note to give you plenty of time to plan.

About a year ago, Siemens released a new scanner (Prisma) that has particularly strong gradients. Many NIH grants are now being written with the specification of matching the Prisma performance. Bob has worked hard at the CNI to implement the sequences and reach the quality of images that are required for these grants. The CNI team have documented the SNR of the data, and we think it is pretty good and should make us eligible for these NIH awards.

GE is responding to the competition. In particular, they have told us that they expect make available a gradient system upgrade within the next year. The stronger gradients will make our scanner competitive with (GE says better than) the Siemens Prisma.

We are funding this upgrade through a GE non-obsolescence service contract that costs about $100k per year for the next three years. The funds for this service contract are coming from user fees (which have barely gone up over the 5 years of operation). We can afford this because of the heavy usage at the CNI and our efforts to keep other costs in check. An additional $200k was needed to bring our system up to the current GE hardware platform, and this funding was provided by the Dean of Research. This upgrade was implemented last year and involved a faster host computer and reconstruction server. Some of you may have noticed this upgrade in the form of reduced delays between multiband scans. (It did not affect the data acquisition systems, so it has no impact on data quality.)

We will keep you informed as we learn about the likely delivery dates for the scanner upgrade.  We expect the new hardware to be available in about a year, and the system will likely be down for about 2 weeks during the installation process. The new gradients can be run at the current system’s lower performance level to maintain compatibility with data collected pre-upgrade. Diffusion sequences and a few others will benefit significantly from the new gradients (not such much for fMRI).

Feel free to post questions about the upgrade here. We will let you know more as we learn more.

Brian and Bob

 

High Order Shim Errors (UPDATE)

March 15th, 2016

Gary Glover kindly shared his fix for this issue and we have installed it on the CNI scanner. So you no longer need to worry about the HO Shim checkbox described below. Your shims will be preserved regardless of the checkbox state (although it doesn’t hurt to have it checked).

 

Hello CNI users,

After you do High Order Shim, and then start to a new scan, you may receive the error that reads:

A change has been made to scan locations.
High Order Shimming results will be lost.

To prevent this error, please do the following:

1. In ALL series/scans that you want to use the HO shim, check the tiny “Retain HOS Currents” box in the lower left corner of the screen.

 

N.B.  The checkbox is not visible when you are in the Protocol Editor. You can only check this box when you are scanning.

2. When you finish scanning, save the updated protocol.  Then you won’t need to check this box the next time you scan.

 

SMS, EPI and tSNR (long)

March 15th, 2016

Bob, Hua and the CNI team are working with the community to improve our methods.  The text below - excerpted from a recent exchange with the Wagner lab – illustrates the tools we use to exchange data and computational methods.  This software infrastructure is an important part of the CNI research and development mission.

The story below illustrates how one group uncovered a problem and effectively communicate it to the CNI team.  They collaborated to develop a solution that improves on previous methods, and this will benefit the entire community.

In a subsequent post, we will describe our plan of action when we discover that a method can be improved. Such advances happen (routinely we hope!).  Our general plan is to share advances by taking advantage of the database (NIMS) so that we can identify data that could be improved and alert you to apply the improvements.

Bob, Brian and Michael


 

An SMS Story

Bob, Kangrong, Matt, Hua, and Adam have been developing simultaneous multislice methods (SMS) for use at the CNI. Variants of this sequence for rapid, whole-brain acquisitions have been developed and distributed on Siemens, but as far as we know, the CNI implementation is the first fully working system on the GE platform.  The SMS technology allows investigators to collect whole brain fMRI measurements with a repetition time of substantially less than 1 sec even with a resolution as low as 2mm isotropic. For diffusion imaging, SMS allows the scan time to be substantially reduced, allowing more diffusion directions and/or b-value shells to be measured in a reasonable scan time.

Our user community has been very actively involved in testing the CNI implementation.  As with the development of any new technology, feedback from the field is very important.  Since the initial roll out of the method, Karen LaRocque and the team in the Wagner lab have provided particularly useful feedback.

In February, Karen sent a message to Bob noting that

I’m analyzing some multiband (3 band) data and am noticing that the variance in the timeseries seems to vary systematically between the odd-even slices. It’s more apparent for some runs than for others, but is present in multiple runs / subjects.

Karen and her colleagues also shared links to data sets and Jupyter notebooks showing her calculations.

Bob responded with some ideas (the CNI team often uses “mux” as a synonym for SMS)

Hi Karen,

One hypothesis that I have is that this is related to the calibration scan. If the subject moves (even a little along z) during the calibration scan, it can create some inhomogeneity in the signal intensity in the calibration images and that will carry over into the mux scans.

Things to check: 

1. look at the quality of the calibration scan (should be the second volume in the nifti) and see if it correlates with the appearance of the artifact

2. is the tSNR variance caused by changes in the signal or the noise? Or both?

If it is a calibration scan issue, then we can try reconstructing some of of the bad scans using calibration data from a different scan. I will also talk to the MR physics group to see if there are any ideas for a fix in the reconstruction (e.g., smoothing the calibration images). Longer-term, we do hope to develop better calibration scan methods. But that will be some time away.

Also, can you tell me how serious you think this artifact is? Are you thinking that it makes data unusable in some cases? 

thanks,

bob

Hua pitched in, working with Bob to understand the problem.  Karen pointed Hua to their most problematic data set, which could be referenced by a link to the NIMS data base

From: Karen Fossum LaRocque <klarocqu@stanford.edu>
Sent: Wednesday, February 17, 2016 2:10 PM
To: Hua Wu
Cc: Anthony David Wagner; Michael Lawrence Waskom; Valerie Ann Carr; Ian Connors Ballard; Bob Dougherty
Subject: Re: multiband data: odd-even slice variance differences

Hi Hua,

This is my most problematic scan:  https://cni.stanford.edu/nims/auth/browse#main,exp=95441,sess=96169,epoch=96210

Thanks!
karen

After some analyses and experiments, the CNI team found an improved method.

From: Bob Dougherty <bobd@stanford.edu>

Sent: Monday, February 22, 2016 5:30 PM
To: Karen Fossum LaRocque
Cc: Anthony David Wagner; Michael Lawrence Waskom; Valerie Ann Carr; Ian Connors Ballard; Brian A Wandell; Hua Wu
Subject: Re: multiband data: odd-even slice variance differences

Hi Karen,

We’re trying out an alternative recon algorithm (split-slice GRAPPA) and some z-axis smoothing on the calibration images. The ssGRAPPA seems to make the tSNR more uniform across slices, and the smoothing may increase tSNR a bit as well. Here’s the comparison for subject you pointed us to (exam 7840, series 26):

heegieda

I’ve put both files up on your cni lx-container (cnic9) in /data/7840_26_1_weightedavg.nii.gz and /data/7840_26_1_spslgrappa.nii.gz. You should be able to scp the files with ‘scp klarocqu@cnic9:/data/7840_26_1_* .’ (for more info on the cni containers, see http://cni.stanford.edu/wiki/LXC). Note that the image orientation is messed up in these niftis because we’re using our bleeding-edge recon code, which isn’t fully debugged yet. But we hope to get that fixed this week. After more testing, we could be ready to start redoing recons in NIMS sometime next week.