search

HBClab / LabManual

updating the lab Manual
MIT License
0 stars 4 forks source link

readme

Health, Brain, Cognition Lab Manual

Introduction

This wiki is intended to be a resource base for background reading and lab protocols. By comparison, our "public face" is through our lab website and facebook page.

What does the lab do?

Our lab is interested in understanding how to maximize the brain’s capacity for adaptive plasticity across the lifespan. In other words, how to get the most out of your brain as you get older. This includes examining mechanisms associated with declines in plasticity and cognitive function associated with aging, injury, or disease, and determining how we may intervene for improved performance and quality of life. To study plasticity, we are interested in how people learn new skills and abilities, and the lifestyle factors that affect learning and retention. For example, what is the best way to learn how to play the piano? How can we improve our memory for the people we meet and new knowledge we've learned over time? What brain processes support this learning and how do they change throughout the lifespan? Is there anything we can do to improve our ability to learn and remember? Do they differ when we’re thirty compared to seventy? We are particularly interested in cognitive abilities important for successful aging, such as episodic memory, working memory, processing speed, task-switching, and different types of skill learning.

More specifically, our research goals relate to three broad questions:

  1. Aging brain and cognition: How do the brain and cognition change across the lifespan? What are the competing forces of "damage" and "resilience" and how can their process and outcome be measured in testable forms in humans? See this figure from Ferrucci et al, 2018 as a visual of these competing forces which are biological at their root and become phenotypic when they are observable/measurable (e.g., cognitive performance, cardiorespiratory fitness).

  2. Translation: What are the earliest signs of brain and cognitive decline that are most predictive of functional decline and/or risk for neurodegenerative disease? We hope this work helps define biomarkers that are in the causal pathway of later functional or neurodegenerative decline. These help capture personalized assessment of risk and tracking change over time. Think of this as working our way back to the biological root of changes we later want to prevent, like in this figure from Ferrucci et al, 2018 showing the relationship over time of biological, phenotypic, and functional changes with aging.

  3. Neuroplasticity for improved function: What factors or interventions associate with or maintain brain health and in turn, cognition and everyday function? Here we take what we've learned about the processes of aging and the most predictive markers of age-related functional decline, and determine how to prevent or reverse them through processes of neuroplasticity. The majority of our research on this question examines the impact of how to regularly challenge our brains and bodies to maintain optimal performance throughout life, as shown by this figure from Clark et al 2018 We are also interested in how other lifestyle factors, such as sleep and nutrition, affect the potential for neuroplasticity. Key background for this research can be read in Dan Simon's review of cognitive training, and our review on exercise neuroscience (paper, supplementals).

To do this, we use cognitive neuroscience methods. For example, we study learning with both basic learning and memory paradigms and applied training experiences such as commercialized “brain training” programs and videogames. To understand neural mechanisms of brain plasticity and cognitive function, we use primarily magnetic resonance imaging (MRI) techniques. We use MRI often because it is the only tool to look at functional brain systems throughout the whole brain at once. MRI data is collected at MRRF, which is a short 10-12 minute walk from our lab in the Psychological and Brain Sciences Building (PBSB). To help narrow in on the most useful imaging measures collected with MRI, we collaborate to examine mechanisms of cognitive and brain function using other imaging modalities (e.g., ECoG) and species.

Mentoring philosophy, by Professor Voss

In teaching and mentoring my goal is to empower students to feel comfortable with uncertainty by having the skills to identify unknowns and methodically turn a puzzle into new knowledge. Just as we all approach puzzles differently, students come with diverse perspectives and skillsets, so effective teaching and mentoring requires an awareness to listen, support, and amplify voices from a diversity of backgrounds and perspectives. My hope is that through your experience in this lab you will experience how diversity can spark novel insights, solutions, and knowledge. This philosophy inspires an approach focused on personal interaction, asking questions, open discussion and feedback, and listening and learning from different perspectives. Students will learn the foundations of scientific thinking, analysis, and writing. Whether students I mentor go on to generate new knowledge in a research lab or become mostly consumers of research, my hope is that they will appreciate what good science looks like and the value it can bring when done with curiosity and care.

What is expected of me

General Conduct

Expectations for day-to-day culture Examples Accountability
Teamwork 1. Support each other, be on each others' team
2. Choose a positive attitude
3. Help
4. Openness to feedback for improvement		 1. Weekly check-ins with project coordinators and graduate students
2. Check-ins with all students and staff on interactions and comfort with project coordinators and grads
3. Feedback opportunities from participants on their experience (good and what to improve)
Respect each other and collaborators, the lab, our participants, and the data 1. Awareness of open workspace (noise, your stuff, etc.)
2. Be aware of data files being open (hard or electronic)		 1. Weekly check-ins with staff and/or grad you're working with
2. Personal check-ins: ask yourself whether what you're doing could negatively affect someone else in the space or confidentiality of data
3. Document mistakes and let your supervisor for the task know, and discuss strategies to prevent it next time.
Persistence and attention to details: Every task is important! 1. Document any confusion in protocols or instructions
2. Document trouble-shooting efforts and then seek help/feedback		 1. Document lab activities in a notebook
2. Open an issue on the relevant github repository.
Develop scientific literacy and skills and knowledge of the broader impact of our work 1. Attend journal club and be engaged (read and ask questions)
2. Be open and proactive in learning new skills via tutorials or research tasks
3. Be proactive about suggesting topics to learn about		 1. Attendance and engagement
2. Work towards presenting a paper or data at journal club
3. Document goals, feedback, and progress and set up meetings to review in person

Lab communication

Data scoring, entry, and processing Conduct

Session Running Conduct

Expectations for interactions with participants Examples Accountability
Participants have a good experience 1. Be early and greet with a smile
2. Introduce yourself
3. Empathize and be supportive
4. Don't be distracting in the background of testing		 1. Feedback opportunities from participants on their experience (good and what to improve)
Testing and training are standardized 1. Follow testing protocols, document any deviations or questions
2. Maintain consistency in instructions and feedback to participants questions		 1. Document lab activities in a notebook
2. Open an issue on the relevant github repository
Data are complete and valid 1. Complete data files are saved
2. Data are backed up on github or redcap after the session
3. Participants were able to understand and complete the task under standardized conditions		 1. Ask your project coordinator how to view the data quality reports for the tasks you've run
2. Be respectful and open to improvement when receiving "coaching" from labmates.
Confidentiality 1. Do not talk about participants with their names in the lab space or with other participants
2. Do not leave other participant's data files open where another participant could see
3. Names should not be on data files except for the project manager's protected tracking sheet
4. If you are the last one to leave the lab and materials are out with identifying information, ensure it's in a locked location before you leave.
5. Be sensitive about interaction with participants while other participants are around		 1. Breaches in confidentiality could have major consequences -- this is serious! When in doubt, ask Professor Voss.
2. Feedback opportunities from participants on their experience (good and where to improve)

Before Session

During Session

After Session

Session Training Protocol

Trainer is expected to conduct the following sessions before the trainee is qualified to run sessions independently. Trainee is required to read this protocol to understand training expectations during all training sessions. An example training log is shown below, the trainer is required to record date, Pass/Fail, and initial after each training session. Only when the trainee completes all four training sessions successfully will trainee be considered fully qualified to independently run sessions. If there are sessions that are the same between studies, trainee is considered qualified upon completing training for the session for one of the studies. If sessions are similar but not the same, trainee still must complete training, but the training session may be modified.

Who can be a "trainer"

Session 1 - Protocol Meeting

Session 2 - Shadowing

Session 3 - Paired Practice

Session 4 - Observed Session

Background Literature

Guide to reading and contributing to literature reviews

Below is a list of topics separated and outlined by topic. Some are general interest topics and others relate specifically to the methods and research questions relevant to our lab.

As part of the lab, we want you to be both a consumer and producer of this page. To consume and get the most out of your reading, please read the reading questions and consider these for each review or primary article that you read. It's expected that you'll run into questions, so don't be shy to contact someone in the lab to discuss your answers to reading questions. This includes other undergraduates in the lab, the graduate student or staff you work with most, and Professor Voss. To produce and generate new information on these pages, you should:

(1) Consult with a graduate student or Professor Voss to find out about which topic(s) are priority

(2) Search for new papers; we often use PubMed or Google Scholar (see here if you're not sure how to do this)

(3) Pick a set of 1-2 papers to read that may be relevant to your search topic; answer reading questions as you read each, and document answers on the reading response form (which you can download below). Note you may have to skim more papers than you actually read in depth. I would suggest once you find a promising abstract, to skim to make sure it's relevant.

(4) Make an appointment to discuss the articles with the graduate student you're working with or Professor Voss (whoever you first consulted with). Facilitate discussion by sending PDFs of the articles and your responses, as this will be a guide for discussion.

(5) Once we're ready to add an article, email a PDF of the article(s) to Professor Voss, along with the final (electronic) copy of the reading response form(s). Professor Voss will update the wiki.

Reading questions

Journal articles are the way scientists communicate their ideas and results to one another. The dissemination of hypotheses and findings in this way is fundamental to the process of progress in science because it maintains rigor (through peer-review) while also making new research publicly available to other labs that may try to replicate or extend the published studies in their own lab. Thus, the ability to read and interpret articles in the primary literature, both in terms of methods and results and the conclusions/interpretations that can be drawn, is a fundamental skill for a successful scientist. These questions are meant to help critically analyze research articles, so you can evaluate when a paper is a good contribution to the literature, i.e., it creates new knowledge.

Reading topic areas

Journal club:

Statistics

General resources

Computing in the lab

Automation Stations

Contact for administrator of computers: bradley-carson@uiowa.edu

We have two computers (one physically in lab and one located off-site) to help with automation of tasks. The computer physically located in lab is only for testing and playing and should not be used for any automation. The computer located off-site is the computer we can rely on to run jobs automatically. These computers have different addresses:

To login to either of these computers, I'm assuming you are using either a Mac or linux computer (if you need to login using Windows, check out PuTTY). The general form of logging into the computers is:

where HAWKID is your University of Iowa hawkid, and COMPUTER-ADDRESS is one of the two computer addresses above. For example, if I wanted to log in to the computer located off-site, I would type:

If you are unable to log in, but believe you should have access, contact Bradley Carson with Michelle Voss cc'd.

Once logged in, if you want to modify the crontab or do other work, you need to switch from your username to the lab service account vosslab-svc. To do so, type:

If are unable to login as vosslab-svc or if the terminal asks you for a password, and you believe you should be able to, contact Bradley Carson with Michelle Voss cc'd.

James wrote an introduction to crontabs if you want a jumpstart

Building Singularity Containers

While we use Docker to create software containers, Docker requires elevated privileges to run, which is not possible in a high performance computing (HPC) environment. Luckily, developers made Singularity to circumvent the requirement for elevated privileges.

We use singularity to create singularity containers that run our software in an isolated environment with all the software dependencies installed. We keep all the singularity containers we build in the <mount-location>/vosslabhpc/UniversalSoftware/SingularityContainers/ directory. To build a singularity container, we use the general form:

where software represents the code we want to make a container for, and X.Y.Z represents the version of the code we want to use. The v in the docker tag (vX.Y.Z) is not always there, so be aware what the available docker tags are in dockerhub.

For example, if I wanted to build a singularity container for xnat_downloader, I would type:

or if I wanted to build a version of fmriprep, I could type:

Data organization

Computational Workflows

General workflows for acquiring/working with data in the lab.

Behavioral Data Workflow

(Click on image to get access to useful links) behavioral_workflow

XNAT Downloading Images Workflow

(Click on image to get access to useful links)

xnat_workflow

Coding Jumpstart

We are excited that you want to pick up the basics for learning to code and help out with some of the more technical aspects of data collection and analysis. Persistance is key, but Professor Voss and the graduate students will be here to help you along your journey. If you are a graduate student, then more senior graduate students will help. What I will outline below are some soft suggestions of what to learn about; everyone may have different resources that "click" for them, so stick to what helps you. With that said, there does not exist a resource that makes anything "easy"; there is not a replacement for persistance and asking for help when you get stuck.

General Resources

General R Resources

General Python Resources

General Shell Resources

Data Technology Stack

Here is a list of the current technologies/software used in the lab

Beginner Goals

Beginner Git/Github Goals

Beginner Shell Goals

Beginner R Goals

Beginner Python Goals

Beginner Shell/R/Python Goals

Beginner Resources

Beginner Git/Github Resources

Beginner Shell Resources

Beginner R Resources

Beginner Python Resources

Intermediate Goals

Intermediate Git/Github Goals

Intermediate Shell Goals

Intermediate R Goals

Intermediate Python Goals

Intermediate Shell/R/Python Goals

Intermediate Git/Github Resources

Intermediate Shell Resources

Intermediate R Resources

Intermediate Python Resources

Improve this Manual

You may have read this manual and saw a typo or wanted to add a new resource. THANK YOU! We encourage and welcome your contributions!

If you have never used github before, no worries, we will walk you through step-by-step.

Step 1: Fork the repository

The first step is to "fork" the LabManual, which gives you your own copy of the LabManual that you can safely do whatever you want with without affecting the original LabManual.

  1. Click the button with the word "Fork". forking

  2. A screen should appear asking where to fork the repository (i.e., the LabManual). Select your own github profile. wherefork

  3. You should now see the LabManual under your own account. You can tell that your repository is a fork by looking in the upper left corner of your screen. There should be the tiny phrase: "forked from HBClab/LabManual" mahfork

  4. If you would like to make the edits locally on your computer, instead of on github, see the terminal instructions.

Step 2: Create a new branch

Having your own fork of the repository is nice, and it is even nicer to have your own branch. Creating a new branch lets you and your collaborators know what you are working on. Besides, "master" is not a very descriptive name to describe the changes you want to make.

  1. Click on the Branch: master button.

    master

  2. Name your branch something descriptive, like add_awesome_link. Hit enter after you name your branch to create it.

    add_awesome_link

  3. You should now be on your new branch, instead of master, you can see add_awesome_link

    new_branch

Step 3: Make your edits

With forking and branching out of the way, you can start making edits. This is the change you wanted to make in the first place!

  1. Assuming you are editingREADME.md, you will want to click on that file.

    readme

  2. Now you can see the contents of README.md, but you cannot edit yet. To edit, click on the pencil icon.

    all_icons

    pencil

  3. The interface should change and look something like this:

    new_face

  4. Make the edits/add the links!

    new_link

Step 4: Commit your changes

Commiting your changes is like creating a savepoint that you can go back to at any time. If you've ever overwritten your work and wanted an easy way to go back without hitting control-z a billion times, git has got you covered.

  1. At the bottom of your screen, there should be a a text box to write your commit message. It is encouraged to write your commit message using imperative language (“spoken or written as if giving a command or instruction”)

    gitit

  2. Once satisfied with what you've written, click commit changes

Step 5: Open a pull request

With your edits saved on your fork, you would like the original HBClab/LabManual to also have those edits. To request those changes you will open a "Pull request". As in, I would like the HBClab/LabManual to please pull the changes on my branch from my fork (e.g., jdkent/LabManual) and incorporate them into the HBClab/LabManual master branch. That's a bit of jargon soup, but with enough repetition, all those words will become familiar to you!

  1. Right after you make your commit, you can select the "Pull Request" tab.

    pulltab

  2. If you just made the commit, there should be a greenish banner on your page. Click on "Compare & pull request"

    brucebanner

  3. You should be directed to a new page with a text box to give information about your pull request. First, however, we should double check, to make sure that the base repository is HBClab/LabManual and that the base branch is master. The base repository is the repository we want to change. The "head" repository is the one we edited, specifically on the add_awesome_link branch. If the base or head repositories are not what you want, change them now.

    why

  4. Next, give a title to your pull request and any other additional information to give anyone else reading the pull request why you made your changes.

    moarinfo

  5. When you are satisfied with what you've written, click on "Create Pull Request"

    create_pull

  6. Congrats, you've opened a pull request!

    new_pull

Step 6: Responding to reviews

To help improve the edit you are suggesting, someone may review your pull and request you make some changes. It's awesome that you took the time to open the pull request and it's awesome someone else took the time to review your edits, we are all trying to make the document better. Sometimes the reviewer may have some suggestions for your edits before they are accepted and merged.

  1. read the review

    review

  2. Go back to your branch on your fork of LabManual and select edit mode as you did in step 3

    edit_again

  3. commit the changes as you did in step 4

    commit_again

  4. There is NO NEED TO OPEN A NEW PULL REQUEST. Since you've already opened a pull request, any new commits are automatically added to your existing pull request.

    see_it

Conclusions

You may repeat step 6 multiple times, or none at all, but whichever the case, be proud of the work you've completed.

This may appear to be a drawn out process to make a simple edit (and you are right to think so), but the steps you've learned are used to handle much more complex changes, so consider this an investment to be able to tackle that complex change you may want to make to another project tomorrow, next month, or next year. Some members of the lab use this workflow every day, making it important to learn for effective collaboration.

Below are "advanced" instructions for making the edits on your computer instead of using the github website.

Step 2: Clone the repository (terminal)

Cloning a repository gives you a local copy of the repository on your laptop or machine.

  1. From your forked repository, select the Code button.

    cloneit

  2. The button should expand a small menu, with a url and a clipboard next to it. Click on the clipboard to copy the text.

    clipit clipitgewd

  3. Open a terminal on your local laptop/machine

    term

  4. Type git clone and then either control+shift+v or command+shift+v whether you are using windows/linux or mac. The result should look something like the following.

    clonecommand

  5. Hit enter, and the repository should download to your computer. The output should look like the following:

    cloneout

  6. Type cd LabManual to change directories into the repository. You are now ready to make edits.

Step 3: Make your edits (terminal)

  1. Type ls to see the contents of LabManual

    contents

  2. Create a new branch with git checkout -b add_awesome_line

    branchingout

  3. Open your favorite text editor in this directory. (mine is vscode).

    codeit

  4. Open README.md to make your edits.

    mah_edits

Step 4: Commit your changes (terminal)

  1. Type git status to see what changes are "unstaged"

    unstaged

  2. Type git add README.md to stage the file. We have not taken the snapshot yet, this just prepares what items we want to take a snapshot of. (like getting all your family members together for a picture).

  3. Type git status again to see README.md in the staging area.

    staged

  4. Use git commit -m '...' to commit your changes. Replace ... with your actual commit message.

    committed

  5. Finally, you can push the changes to your forked repository on the new branch you have created with the command: git push origin <name of branch>. Replace <name of branch> with the actual name of your branch.

    push

  6. Now you can continue with step 5 on github

Add Developer to HBClab

In order to administer travis-ci/circleci and other github applications that help with testing, you need to explicitly give people permission so they can add passwords/change workflows, and generally be useful to maintain our software.

This was a little unclear to do so we're leaving a note in the manual on how to do this.

  1. Go to the HBClab page and click on the settings tab.

  2. Click on GitHub Apps under "Developer Settings"

    gh_app

  3. Add the user you want to have access to travis/circleci/etc.

    add_user

Now that person should be able to access/administer all our repository workflows in HBClab.