Installing the Anaconda Python distribution on an air-gapped (i.e., non-networked) computer is possible but not trivial. These steps worked for me.

1. Create a local environment under Anaconda that contains the desired packages

$ conda create --name myenv python=3.6.7
$ conda activate myenv
$ conda install pillow pip

Choice of Python version, packages, etc., should match your needs. Ensure that your local installation works as desired before proceeding.

2. Write a list of packages installed in the environment to a text file (spec file)

$ conda list --explicit > /path/for/spec_file.txt

3. Retrieve all of the packages from the remote servers to local storage (e.g., ./pkgs directory)

$ cat /path/for/spec_file.txt | grep "^http" | xargs -I xxx wget -P /path/for/pkgs xxx 

4. Edit the spec file so that it references your local pkgs directory

I found that the following format and directory structure made things simpler:

$ cat spec_file.txt

# This file may be used to create an environment using:
# $ conda create --name <env> --file <this file>
# platform: linux-64
@EXPLICIT
pkgs/pillow-6.2.1-py36hd70f55b_1.tar.bz2
pkgs/python-3.6.7-h357f687_1006.tar.bz2
pkgs/pip-19.3.1-py36_0.tar.bz2

$ tree .

.
├── pkgs
│   ├── pillow-6.2.1-py36hd70f55b_1.tar.bz2
│   ├── pip-19.3.1-py36_0.tar.bz2
│   └── python-3.6.7-h357f687_1006.tar.bz2
└── spec_file.txt

5. Download the latest Miniconda

From https://docs.conda.io/en/latest/miniconda.html

6. Put spec file, packages, and Miniconda installer on a USB drive

7. Copy files from USB drive to air-gapped computer

8. Install Miniconda

Use the Windows installer or bash Miniconda3-latest-Linux-x86_64.sh on Linux.
Depending on your installation choices, you may need to open the Anaconda prompt (Windows) or run source ~/.bashrc (Linux) to access the conda command in the next step.

9. Create your new environment with the "--file" option pointing to your spec file

$ conda create --name myenv --file /path/to/spec_file.txt

Note that the packages you downloaded must be located at the paths indicated in the spec file (relative paths are fine).

10. Switch to and test the new environment

$ conda activate myenv
$ python test.py

TL;DR Attach the physio devices, switch on physio recording in the CMRR Multiband EPI Sequences Sequence/Special card by selecting DICOM from the drop-down menu, record your EPI data, and enjoy.

Introduction

Physiological signals such as heart rate and respiration can influence the fMRI BOLD signal (more below), so recording these signals can be useful for later processing and analysis. At the suggestion of a friendly expert, I explored how to record physiological signals at our institution's research MRI facility.

Happily, this proved to be pretty straightforward on our Siemens Prisma. However, it took me a while to find the necessary information on-line, hence this post.

Record

If you're using a recent build of the CMRR Multiband EPI Sequences, you're 99% of the way there. The hardworking CMRR experts have baked physiological recording into the sequence software itself; all you need to do is activate it. At the scanner console, browse to the Sequence/Special card and look to the top-right for a drop-down menu.

Lifting flagrantly from the sequence manual:

Physio. recording: Control recording of physiological signals (cardiac, respiration, ECG, external) to text or encoded DICOM files. Text files will be stored in C:\MedCom\Log\Physio\ on the host computer (MRC). Legacy uses the classic CPmuSequence/IdeaCmdTool logging facility (this is the only option available on VAxx/VBxx systems and VD11x; it is known to be unreliable on VD11x/VD13x/VE11x). DICOM and File use the new online/ICE logging available since VD13A, which is recommended for use when available. File writes the log data to individual text files for each signal (this option was named Online in previous versions). DICOM embeds these logs in a special DICOM “image” stored in the database (sample Matlab code for reading the special DICOM files is provided in the GitHub repository). Multiple enables both Legacy and File options (not recommended for routine use).

To test this, we put a volunteer in the scanner, hooked up the wireless respiratory and pulse-ox sensors, selected the DICOM option from drop-down menu on the Special card, and started recording EPI data. Lo and behold, we found a DICOM file associated with the study. Success!¹

Extract

With the physio data saved to a DICOM, the next step was to extract the recordings. The CMRR repo has a Matlab script for this purpose, but I wanted to get a Python version working. This was down partly to Python chauvinism and partly to wanting a better understanding of what extraction is doing.

My draft implementation is available in a Github gist . The script takes the path to a physio DICOM as an argument (along with an optional output directory). The physiological recordings are then extracted to their original filenames in the output directory (same as the DICOM's if not supplied).

usage: physio_convert.py [-h] [--path PATH] [--outdir OUTDIR]

optional arguments:
  -h, --help       show this help message and exit
  --path PATH      path of physio DICOM file
  --outdir OUTDIR  directory for output

Depending on the data you collected at scan time, running the script should produce two or three of the following (the * is shared date-time and scan information):

Inspect

The recordings themselves may require additional attention prior to use (this will depend what you want to do with them). As a first step, I wanted to visualize the data to ensure that we got something reasonable.

All signals are timestamped by clock "TICS", which on our scanner appear to be 400 Hz/2.5 msec timesteps. Although all signals are stamped with codes corresponding to this 400-Hz "heartbeat" signal, different signals are sampled and recorded at different rates. On our Prisma, we observed the sampling rates reported in the table above.

Aligning the signals is relatively painless using Python and Pandas. Plotting the data, we see the expected sinusoids for pulse (blue) and respiration (orange) as well as a steady pulse for EPI volumes (green). 😎

Regarding use of the physio recordings as covariates for fMRI processing and analysis, I'll defer to the expertise of other investigators. Some useful resources might include:

• Glover, G. H., Li, T. Q., & Ress, D. (2000). Image-based method for retrospective correction of physiological motion effects in fMRI: RETROICOR. Magnetic Resonance in Medicine, 44(1), 162–167.
• Birn, R. M., Diamond, J. B., Smith, M. A., & Bandettini, P. A. (2006). Separating respiratory-variation-related fluctuations from neuronal-activity-related fluctuations in fMRI. NeuroImage, 31(4), 1536–1548. https://doi.org/10.1016/j.neuroimage.2006.02.048
• Power, J. D., Lynch, C. J., Silver, B. M., Dubin, M. J., Martin, A., & Jones, R. M. (2019). Distinctions among real and apparent respiratory motions in human fMRI data. NeuroImage, 201, 116041. https://doi.org/10.1016/j.neuroimage.2019.116041

Acknowledgments

Thanks to the CMRR team for making this easy, to our scanner tech Lisa for her patience, and to Jonathan for reassurance that getting physio recordings from new scanners isn't too arduous.

The Aguirre lab has a resource page that provided useful hints.

Footnotes

¹ Acquiring physio recording without the CMRR MB-EPI sequence is left as an exercise for the reader.
² The timing information in the Info file includes start/stop for each volumes, slices, and (if used) multiple echoes. Having this information might be useful for various reasons including converting DICOM to NIFTI accurately, although tools such as dcm2niix should have the necessary timing information built-in.

My wife and I were pleased to attend the AFNI Bootcamp held in Lincoln, Nebraska a couple of weeks ago, and I'll write more about that elsewhere. For now, I'll just provide some notes on hardware and software for prospective campers.

Hardware

I wanted to run AFNI natively under Linux rather than on a virtual machine (more on that in the software section), so I bought a pair of older machines. Happily, they performed quite well. I purchased two used Lenovo Thinkpad T420 laptops on a popular online auction site for about $225 each. These machines aren't speed demons, but they more than met the challenges presented by a week of AFNI ¹. Here are the rough specs for the laptops:

• Intel Core i5 (~2.5 GHz, 3MB L3, 1333 MHz FSB)
• 8 GB RAM
• Intel integrated graphics 3000
• 160 GB SSD
• 14.0" display, 1600×900 pixels

Of course, when you're throwing terabytes of neuroimaging data at AFNI, you'll want as much processing power as possible, but these computers were fine for didactic purposes.

Software

I've never had a great experience running Linux through a VM — it works, but it's clunky and doubly so on a laptop. So, when the computers arrived, I installed the recently-released Ubuntu 16.04 LTS distribution. As I'd hoped, Ubuntu worked flawlessly on the Thinkpads, including conveniences such as two-finger scrolling, volume control button functionality, and the patented Thinkpad top-down keyboard light.

Also as expected, installing AFNI presented a few quirks and challenges. The AFNI guide to installing on Linux is generally quite good, but I found a few inconsistencies that I'll note here.

• libmotif installation: libmotif4 is not in the default package repositories, so you'll need to add to the base set. Here's how to do that from a terminal:

sudo su # Become root user
echo 'deb http://cz.archive.ubuntu.com/ubuntu trusty main universe' >> /etc/apt/sources.list.d/extra.list
apt-get update
exit # Exit root user
sudo apt-get install -y tcsh xfonts-base python-qt4                    \
                        libmotif4 libmotif-dev motif-clients           \
                        gsl-bin netpbm gnome-tweak-tool libjpeg62      \
                        libxp6

• Library linking: the installation procedure describes symlinking libgsl, but the indicated link doesn't work. Here's the fix:

sudo ln -s /usr/lib/x86_64-linux-gnu/libgsl.so.19 /usr/lib/libgsl.so.0

• Bootcamp files: the files distributed for the bootcamp lectures are intended to be installed in the user's home directory, but the instructions still describe placing the files in a CD subdirectory. Basically, the following section of the main instructions is outdated:

curl -O https://afni.nimh.nih.gov/pub/dist/edu/data/CD.tgz
tar xvzf CD.tgz
cd CD
tcsh s2.cp.files . ~
cd ..

You can still use the CD subdirectory (I did), but the lecturers will expect things to be installed in the canonical spots. Depending on your comfort with UNIX-like operating systems, you may appreciate the simplicity of simply having everything you need in your home directory.

Otherwise, everything went swimmingly!

¹ This may be more of a commentary on the slowing of processor speed gains than on the stunning legacy of these laptops.

Just a quick note to indicate that I'm taking a hiatus from new peer-reviewing activity for the remainder of 2016. My peer-review burden has been substantial so far this year, and I need to reserve some time for my own professional writing. I look forward to resuming normal peer-review activity in 2017.

I'm currently seeking well qualified, highly motivated applicants for a research assistant position in my lab at UNMC in Omaha, NE. For more information, visit https://unmc.peopleadmin.com/postings/27573. Looking forward to interviewing some exceptional people!

Here's the email announcement that I circulated about my new position:

Dear friends,

It's a new year, and I'm pleased to report that I have accepted and started a new job: as of January 1st, I'm an assistant professor in the Department of Neurological Sciences at the University of Nebraska Medical Center. I'm very excited to start my career as an independent scientist in a terrific environment here at UNMC with great colleagues including our department chair, Dr. Matt Rizzo. My new contact information follows:

Dr. David E. Warren

Department of Neurological Sciences

University of Nebraska Medical Center

988440 Nebraska Medical Center

Omaha, NE 68198-8440

Phone, office: 402-559-5805

Email: david.warren@unmc.edu

I'm in the process of setting up my lab, and my research will continue to explore topics in memory and other cognitive domains in neurological populations using techniques such as neuropsychology, neuroimaging, and eye-tracking. To help with these efforts, I expect to make several hires (research assistant, post doc, etc.) in the upcoming months. Formal advertisements for those positions will follow but for now, please do keep me and UNMC in mind for promising undergraduate or graduate students who are looking to take the next step in an academic career. UNMC and affiliate institutions in the Omaha area offer a broad range of doctoral programs in which I expect to enroll graduate students, while senior graduate students seeking post-doctoral positions should find UNMC's resources attractive. Nebraska's neuroscience community is growing rapidly, and I'm looking forward to adding outstanding individuals to our team.

In closing, let me say "Thank you!" to everyone who helped me get to this point by contributing mentorship, training, teaching, camaraderie, or other support of any kind. I look forward to catching up with everyone very soon. All the best,

Dave

Pictures of neuroimaging data are incredibly compelling, but creating those images can be a challenge. While many tools are available, none of them are ideal for easily creating lots of images. I decided to explore whether my favorite programming language (Python) could be used to quickly create many images of brain data.

If this is interesting, please continue reading. Or if you'd like to get the demonstration scripts right now, head to the repository.

Background: what's volume rendering?

Specifically, I wanted to be able to perform volume rendering of large batches of neuroimaging data. Volume rendering is the process of creating a 2D image of 3D (or really n-dimensional) data. It's very hard to do correctly, but fortunately smart people have done a lot of the difficult work already. This means that complex multidimensional data can be turned into human-interpretable 2D images with relatively little effort.

VTK is a sophisticated visualization toolkit (get it?) that supports rendering of 3D scenes including volume rendering (among many other functions). It also plays nicely with Python, meaning that you can use VTK's functionality while scripting in a high-level language. This was ideal for me, so I worked up a demonstration project.

VTK is very powerful and — even with excellent Python support — quite different from any programming interface that I'd ever used. Critically, some of the most challenging tasks related to volume rendering with VTK had already been worked out by Adamos Kyriakou which he laid out beautifully in a post on his PyScience blog. Adamos's simple approach and clear explanations made my work here tractable. For an introduction to rendering brain data with Python, check out his stuff.

While rendering a brain volume with VTK was clearly possible, my goal was a bit more complex than single-volume rendering. Technically, I wanted to blend multiple volumes together. This meant overlaying colors representing one set of numbers (e.g., brain activation) on colors representing another set of numbers (e.g., brain structure). You see images of this kind frequently in neuroscience journals and even the popular press, but often the images aren't made with what I would consider true volume rendering, instead using surface rendering (a separate topic that I won't get into here).

After investing a bit of time learning about VTK, I was able to produce some decent images. I go into more detail about how this was accomplished in the repository's README. Here are a pair of examples:

First, a synthetic lesion. This shows the extent of damage that might follow a bad middle cerebral artery stroke superimposed on a healthy template brain.

Second, some resting-state functional connectivity data. Using the same template as a base, I've superimposed functional connectivity of the default mode network (DMN) seeded from the posterior cingulate/precuneus region.

These images are attractive and informative, but they aren't novel in and of themselves. Similar images can be generated manually using GUI-driven applications; some of these can even be scripted to batch-render images. However, the means by which these images were generated, and the potential ease with which large numbers of similar images could be generated, appears to be novel. The scripts and comments in the README file included with the repository lay out the approach(es) that I took, so I'll close this post with broader comments about rationale, some hurdles to clear, and what I'd like to provide soon.

Rationale: why volume rendering?

Brain images can be generated using many different techniques, some of which are much simpler and more straightforward than volume rendering. Why bother? Some reasons:

• Clipping: Rendering volumes lets you clip the volume to suit your needs, slicing it where you want to show a given effect. Here are a few examples showing the results of clipping a solid volume with different planes.
  
• Opacity: Rendering volumes also lets you decide what values are opaque, translucent, and transparent. Here are examples that make CSF more visible than usual, a typical rendering, and one that makes gray matter more translucent.
  
• Color: Similarly, you get to decide how values correspond to colors. Here are examples of rendering the same template and activation map using different color palettes.
  

The intersection of these advantages makes volume rendering of brain data (or any data) very appealing.

Outstanding issues

Overall, I was very impressed with the images rendering using VTK and Python, but there were certainly some frustrations.

First, you can't render multiple overlapping translucent volumes in VTK at the moment. This prompted the current approach of mixing template and overlay images instead. It works, but it's a bit clunky and slow. A native VTK solution for blending two or more volumes would be terrific.

Second, the VTK renderer that I used couldn't produce images in an off-screen window. This is a minor annoyance, but it would be nice to have images be saved directly to disk instead of flashing by on the desktop during the rendering process.

Third, I'm a novice VTK user. I ended up using Numpy to work with arrays of data, then saving the results back out to NIFTI formatted data files, then loading those using VTK. This is slower and certainly less elegant that doing more data manipulation with native VTK calls. Suggestions for improvements would be welcome!

What's next?

I'd like to build this approach out into a simple, functional tool that can batch-render images combining a template volume with an overlay. There are complexities that will need to be overcome, but this approach serves my immediate needs and I'd very much like to pass it along to others. If you think that you'd use such a tool, do please let me know.

This is a placeholder post for now, but our manuscript describing deficits in observational learning in patients with focal vmPFC damage is out at Cerebral Cortex. More at the link:

http://t.co/JFF5KRoZA0 CC just posted our manuscript describing deficits in observational learning after vmPFC lesion. @dharshsky #article

— David E. Warren (@DavidEWarrenPhD) April 27, 2015

As I've mentioned before, I love to use Python for data processing and statistical analysis. In this entry, I'll describe my recent experience with the Anaconda Python distribution published by Continuum Analytics. Thus far, using Anaconda has been very straightforward and I'm sufficiently impressed to recommend it.

The problem

A recent round of computer upgrades at the lab means we're all experiencing the minor trauma of reinstalling software. Python is one of my most important tools, so getting it up and running was essential. Unfortunately, while Python's famous maxim about coming with “batteries included” is absolutely true for the base libraries, difficulties with installing and managing third-party libraries can waste a lot of time. That's because despite a terrific community and tons of great third-party packages, Python's built-in package management software remains rudimentary.¹

Batteries Plutonium included

Enter Anaconda. This distribution provides a base installation of the Python language along with almost 200 widely-used Python packages. That includes mainstays such as NumPy and SciPy, relative newcomers such as pandas and scikit-learn, and perhaps lesser known but extremely useful entries such as bitarray and xlrd. If there's any downside, it's that you probably won't use all of these additional packages. However, sacrificing a bit of disk space seems a small price to pay for simple Python package management.²

In our lab I've tried Anaconda on my Windows desktop and on our lab's SUSE Linux workstations. In both cases, installation was painless, even without root access on the Linux boxes. Compared to my previous exertions that got full-blown scientific Python working on those systems, this was a snap. Notably, Anaconda also handles non-Python libraries that some third-party packages require (e.g., scikit-learn uses LibSVM for support vector calculations), meaning still fewer installation hassles. Python's built-in tools, which are getting much better at managing native Python packages, don't yet handle these external dependencies.

Ludicrous speed

Python's free numerical libraries are arguably as fast as those of the other high-level programming languages³, but more speed is always welcome when you're working with large datasets. On that note, another benefit of Anaconda is that it can get you access to CA's proprietary speed-boosting extensions. For most users, access to these features costs money; academics can apply (painlessly) for a free license.

So how fast is it? As Barf the Dog might say, “They've gone to plaid!” I installed CA's accelerate library, and without changing a line of my scripts, NumPy suddenly recruited multiple cores for time-consuming calculations. I've found the speed increase to be very significant for calculations using Python's scikit-learn library among others.

Wrapping up

Anaconda seems to be a great solution to a common problem — managing many potentially overlapping Python package requirements. I've been very pleased so far, and will post again with further impressions and tips in the future. If you have experience with Anaconda or other Python distributions that you'd like to share, please contact me or post below.

Disclosures

Python is an open source programming language, and the base Anaconda distribution is likewise free for use. However, the publisher (Continuum Analytics) appears to be a for-profit enterprise. I have no financial interest in or other relationship with CA, but as I mentioned earlier, I did take advantage of CA’s open offer of free academic access to their professional tier of products. I don't believe that this unduly influenced my opinion of CA or Anaconda, but I feel that full disclosure is always the best policy.

Notes

¹ setuptools, easy_install, and pip definitely beat manual installation and may suffice for UNIX-like operating systems. Unfortunately, these tools often aren't enough for Windows users such as me, and it's all too easy to become mired in Python's own dependency hell. If you're on Windows but still want to try managing packages manually, I highly recommend Christophe Gohlke's amazing collection of pre-complied Windows binaries for Python — I relied on these almost exclusively before trying Anaconda.

² There's also a stripped-down Miniconda distribution if you want to install packages only as needed.

³ It's my understanding that NumPy, MATLAB, and the rest all rely on math libraries such as BLAS and LAPACK under the hood, making their effective speed very similar.

The Python programming language has a terrific and rapidly growing scientific ecosystem, and I'm currently using some of those tools to apply Support Vector Machines to neuroimaging data. Our neuroimaging lab uses openSUSE Linux, and getting the necessary Python packages installed proved to be a bit tricky. With some help from Stack Overflow, the problems were resolved, and I'm happily fitting models to data as I write this:

Ghost town at work, spent the whole day with Python and brain data. Flashback to grad school! #python #dejavu #aloneatlast

— David E. Warren (@DavidEWarrenPhD) November 8, 2014

Library issues

As I mentioned, there were some hurdles to clear before I could get to hacking. Numpy and Scipy are the workhorses of any Scientific Python installation, and both take advantage of high-performance math libraries such as BLAS and LAPACK. Unfortunately, those libraries aren't installed by default in our lab, and our sysadmin was (reasonably) wary of disrupting systemwide settings by installing new packages. Happily, I was able to compile and install everything from source with lots of help and a few tweaks.

Here's the system information:

> cat /etc/SuSE-release
openSUSE 12.3 (x86_64)
VERSION = 12.3
CODENAME = Dartmouth

> uname -a
Linux somecomputer 3.7.10-1.40-desktop #1 SMP PREEMPT Thu Jul 10 11:22:12 UTC 2014 (9b06319) x86_64 x86_64 x86_64 GNU/Linux

And this is the Stack Overflow answer that got me started: http://stackoverflow.com/a/9173550/719469.

A few changes were necessary. First, we use a tcsh shell, so environment variables have to be set using a different format. Second, compile options had to be altered for our system. Details follow.

For BLAS:

mkdir -p ~/path/to/src/
cd ~/path/to/src/
wget http://www.netlib.org/blas/blas.tgz
tar xzf blas.tgz
cd BLAS

## NOTE: For openSUSE, I needed to edit a couple of lines in BLAC/make.inc before proceeding:
# -OPTS     = -O3
# -NOOPT    = -O2
# +OPTS     = -O2 -fPIC -m64
# +NOOPT    = -O0 -fPIC -m64

## NOTE: The selected fortran compiler must be consistent for BLAS, LAPACK, NumPy, and SciPy.
## For GNU compiler on 32-bit systems:
#g77 -O2 -fno-second-underscore -c *.f                     # with g77
#gfortran -O2 -std=legacy -fno-second-underscore -c *.f    # with gfortran
## OR for GNU compiler on 64-bit systems:
#g77 -O3 -m64 -fno-second-underscore -fPIC -c *.f                     # with g77
gfortran -O3 -std=legacy -m64 -fno-second-underscore -fPIC -c *.f    # with gfortran
## OR for Intel compiler:
#ifort -FI -w90 -w95 -cm -O3 -unroll -c *.f

# Continue below irrespective of compiler:
ar r libfblas.a *.o
ranlib libfblas.a
rm -rf *.o
setenv BLAS ~/path/to/src/BLAS/libfblas.a

For LAPACK:

mkdir -p ~/path/to/src/
cd ~/path/to/src/
wget http://www.netlib.org/lapack/lapack.tgz
tar xzf lapack.tgz
cd lapack-*/
cp INSTALL/make.inc.gfortran

# Again, for openSUSE the following changes to make.inc were necessary:
# -OPTS     = -O2 -frecursive
# -NOOPT    = -O0 -frecursive
# +OPTS     = -O2 -frecursive -m64 -fPIC
# +NOOPT    = -O0 -frecursive -m64 -fPIC

make.inc          # on Linux with lapack-3.2.1 or newer
make lapacklib
make clean
setenv LAPACK ~/path/to/src/lapack-*/liblapack.a

Pip pip

With BLAS and LAPACK installed, I was able to use a Python virtual environment to get all of the necessary packages installed. The pip utility is very handy for this purpose if you're on a Linux system. A few invocations of pip install later, I had Numpy, Scipy, and the rest of the tools that I needed in place to get on with my project.

Big thanks to Stack Overflow user “cfi” for his excellent answer to a complicated question!

Not remembering what you shouldn't

Are there brain regions that help us to fill in gaps in memory? What would happen when those regions are damaged? My co-authors and I recently published a short report in the Journal of Neuroscience describing findings that may begin to address this question. A very nice follow-up piece discussed our work last week, and we wrote a brief response.

We know that memory is at least partially reconstructed when recalled. That is, a remembered experience isn't a perfect reproduction of that experience; instead, a remembered experience is the gist of a particular experience with some of the detail filled in from other, similar experiences. If you've ever remembered something typically true but wrong about a specific episode (e.g., Aunt Alice being at Thanksgiving last year when she actually didn't make it, or Derek Jeter starting for the Yankees in a game when he was actually on the DL), you've experienced this kind of memory error.

Recent functional neuroimaging data have pointed toward medial prefrontal cortex (mPFC) as a brain region that could potentially support this kind of generalized, or schematic, memory. Here at UIowa, we're very fortunate to have access to an extraordinary resource in the form of a registry of neurological patients with focal brain injuries, including many with damage limited to the ventral mPFC (vmPFC).

How it worked

We tested these individuals with a memory task designed to produce benign false memories for words that were not studied. The task is simple: participants listened to lists of words such as bed, pillow, blanket, etc., and then recalled as many words as possible. Our healthy normal comparison participants showed the expected effect by often recalling a critical word that was missing from the list, such as sleep. People with vmPFC damage recalled these non-studied words less often than the participants without brain injuries¹. This suggests that the vmPFC may normally play a role in filling gaps in memory with plausible information, and that damage to vmPFC reduces this effect.

Can brain damage improve memory?

We observed that damage to the vmPFC made people less susceptible to false memories while leaving their true memory unaffected. Does this mean that people with specific patterns of brain damage have better memory? Not necessarily. Two key points:

1. Memory is a cognitive process that we define by studying healthy individuals. That is, if healthy normal people typically remember things in a certain way, that's what we should call normal memory. From this perspective, false memories for related words would be normal and vmPFC damage made memory abnormal.
2. The same characteristics of memory that make healthy normal people susceptible to false memories in the DRM task probably help memory performance more often than not. For example, outside of a laboratory setting, how often would you expect to encounter a dozen words related to sleep and later be penalized for thinking about and recalling sleep? Most of the time, the influence of generalized world knowledge such as schemas and semantic relations is beneficial to memory performance, and may have evolved to relieve pressure on other memory systems.

Take-home message

Our memory often takes shortcuts, using general knowledge derived from experience to fill in gaps. Although often harmless or even useful, this can lead to false memories. These memory effects may be supported in part by a specific brain region, the vmPFC. We're continuing to investigate other ways in which vmPFC may influence memory.

¹ Important note: people with vmPFC damage still had some false recall, but it was substantially reduced. Critically, their memory was otherwise identical to that of healthy individuals.

Our new paper

I recently had the good fortune to be the lead author of an article published in PNAS. I'm proud of how the paper turned out, and anyone who's interested should take a look. If the article is more than you care to tackle, you might try the very nice UIowa press release.

What's it about?

Quick summary: we investigated the consequences of brain damage to locations thought to be important to the function of brain networks – we called them hubs. Hubs in brain networks are notoriously difficult to define, so we tested the consequences of brain damage to two different types of hubs. We found that damage to a certain kind of hub caused widespread impairment in thinking and behavior, while similar damage to other hubs had much more limited effects. We attributed these differences in severity of impairment to the role that the first type of hubs play in the network organization of the brain. With more research, we think that our findings have the potential to help doctors make decisions and predictions about treatment based on brain imaging.

Expanding et al.

Before writing more, I should acknowledge the contributions of all of the other authors at UIowa and Wash U, particularly my co-first author, Jonathan D. Power. Jonathan's first take on where the hubs of brain networks might reside (in a great Neuron article) laid the theoretical foundation for this project. Testing that theory in a lesion population required an intensive collaboration between the lab of Jonathan's doctoral adviser, Steve Petersen, and my post-doctoral adviser, Dan Tranel. Their support was critical to the success of the project.

Lots of other people also deserve credit for their contributions, and they're all appropriately acknowledged in the author list. To pick out a couple of key contributions, Joel Bruss helped out tremendously with the processing and visual inspection of neuroanatomical data, and he made some lovely figures, too. Natalie Denburg and Eric Waldron acted as blind raters for the neuropsychological data, and did an admirable job of not asking what all this was about. More efforts should also be acknowledged, but I'll confine myself to saying that it was a great group to work with and I'm looking forward to continuing our collaboration.

Next up

Having taken the first step down this road, we're eager to ask and potentially answer more questions. Specifically, we're planning to:

• explore the effects of damage to more and different brain hubs
• study how damage to brain hubs affects brain activity
• work with neurosurgery patients before and after their procedures to monitor any brain network changes

I can't wait to get started! If you've got questions or comments, post them below or feel free to contact me.

In the fall of 2014, I was very pleased to accept an offer to assume a non-tenure-track junior faculty position in the University of Iowa Neurology Department. It's a great temporary position while I'm on the job market, and I'm excited to be at Iowa for another year.

One odd thing about the job is the name. Other institutions call this kind of position by names such as "Research Scientist", but the title of my position is "Associate". Associate what? Associate nothing, apparently. Definitely not associate professor, and I want to make sure that's clear, hence this post.

Whatever the title, it's terrific to be faculty, even if I'm still on the job market this year.

Arbitrary but related

Many of the things that we need to remember are related only arbitrarily. Consider:

• You're at a party, and your wife introduces to one of her co-workers whom you've never met before. You smile, shake hands, and try frantically to remember that this new face belongs to Alice.
• You exit the mall, bags in hand, and are confronted with a sea of cars and a burning question – Where did I park?
• You know that you've got two meetings this afternoon, but were you supposed to get coffee with your friend before or after chatting with your advisor?

Memory binds the pieces of these experiences together. What's less obvious is that they all rely on the same type of memory – relational memory. As the first real content for this blog, I'll be giving a breezy overview of relational memory theory (RMT) intended for a general audience with a minimum of jargon. In future posts, I'll elaborate and offer more specifics. But for now, the basics of relational memory and RMT.

Multiple memories, multiple systems

The earlier examples describe what we often think of as memory – they focus on events, places, and facts. However, we can store information about earlier experiences in lots of different ways, all of which count as memory. Here are a few examples:

• Your significant other is really excited about riding bikes in the park, so despite being years out of practice you saddle up and find yourself gliding along with no effort.
• Your student submitted his report in a bizarre font that you can barely read at first, but by the third or fourth page you're barely noticing it.
• You pull into a surprisingly empty parking lot at work only to realize that it's Saturday and you've followed your daily commute instead of running errands.

In each case there's memory at work even though what’s been learned is a skill or habit. However, memories of this kind seem very different from memories for facts and events.

The distinction between these two kinds of memory is a key component of RMT. The theory suggests that different kinds of memory depend on unique memory systems, and that memory systems belong to one of two groups. Non-relational memory systems are the second type that we considered, and are well-suited for gaining motor skills such as bicycling, tuning perceptual systems to read a difficult font, or habit learning that can lead to commuter's coma.

Non-relational learning is typically very incremental and slow; non-relational memories are usually very durable but inflexible. These are great properties for lots of memories. Having learned to ride a bike, you'll retain that motor skill throughout your life with little or no practice. However, we don't always have time to learn new information by practicing. You may only hear a new acquaintance's name once; you probably won't have the luxury of parking in the same spot every day for a year; and you aren't going to rehearse your daily schedule until you know it by heart. Slow, durable learning is great, but sometimes you need to learn fast.

Relational memory

Relational memory is used every time you need to bind together two or more pieces of information together, especially when those pieces of information were not previously related to each other. Say you're trying to bind Alice's name to Alice's face during your first meeting: there's nothing in her face that can clue you in to the name; and there's nothing about the name that would prompt you to think of a particular face. The relation between these two pieces of information is therefore arbitrary. Non-relational memory systems might eventually help you learn the arbitrary "Alice"-face relationship, but the hundreds of introductions it would take might get on her nerves. Relational memory offers a shortcut – having met Alice once (or twice or three times), you have a decent chance of remembering her name.

Relational memory is strikingly different from non-relational memory, and not just in terms of learning speed. Relational memory is also extremely flexible. Meeting Alice again later on, you might recognize her in a new outfit and a work setting. One lonely bit of information, such as Alice's face, can be enough to trigger memory for all kinds of related information, including her name, the party where you met, and so on. And despite the speed with which relational memories are formed, they can be extremely durable, lasting for years. The strengths of relational memory, its speed and style of learning, complement non-relational memory in important ways.

Where to next?

I'll pause here for now, but plan to write more about RMT before too long. Likely topics:

• RMT in the brain
  • Brain regions supporting relational memory
  • Brain regions supporting non-relational memory
• The continued evolution of RMT
  • Development during my time at UIUC
  • Contributions by other scientists
• My own experience studying RMT
  • Developing RMT tasks
  • Working with amnesic patients
• Challenges for RMT
  • Future directions and how to stay relevant
  • Alternative accounts of memory function

But for now, I'll just close by acknowledging the guys who put it all together.

Origins

All credit for originating RMT belongs to Neal J. Cohen and Howard Eichenbaum. If you're interested in reading an authoritative account, check out their respective publications at the above websites or PubMed, or one of their two books on the topic (non-affiliate links, I promise).

I'm Dave Warren, and as of this writing, I'm a post-doc at the University of Iowa working with Prof. Dan Tranel. I'm adding a blog to my website to offer my thoughts on a variety of topics that interest me professionally, including but not limited to:

• Cognitive neuroscience
• Memory research
• Methodological issues
• Programming/scripting
• Professional issues

I'm planning to update once a week or so, with more frequent short updates posted to my Twitter account (@DavidEWarrenPhD). More soon!