As described in Getting Started / Configuration, the -d data flag is a required parameter to specify a newline-separated text file indicating what projects to import. For convenience, a file called allData.txt is included which will pull all previously prepared sample data. For any project, the script expects two things: a YAML configuration file to define the structure of the project and a folder containing the data for the project. The YAML file must be titled "$projectId_metadata.yaml". The data folder should contain individually zipped sessions at the top level. When the script starts, it will read the text file and begin checking for these files. If the ./data folder does not already contain the YAML file, the script will search for it on the NRG FTP site. Likewise, if the ./data folder does not contain the folder containing the data for the project (or its zip), the script will attempt to locate a zip by the project ID on the NRG FTP site. Below is an example project YAML file which contains most of the currently supported operations (note that the file would necessarily be called study_001_metadata.yaml):

id : study_001
runningTitle : First XNAT Study
title : My First XNAT Study
keywords : 1st XNAT
description : This collection contains data for my new XNAT
anon :
    file : sample_anon.das
subjects :
    Subj_004 :
        gender : Male
        yob : 1950
        education : 16
        share :
            DEST_PROJ :
                label : DEST_SUBJ_LABEL
        complexSessions :
            0000004 :
                share :
                    DEST_PROJ : DEST_LABEL
    GSU002 :
        gender : Male
        yob : 1921
        handedness : Right
        sessions : [GSU002_v00_mr, GSU002_v00_pet, GSU002_v01_mr]
    OUA001 :
        gender : Female
        yob : 1937
        handedness : Ambidextrous
        complexSessions :
            OUA001_v00_mr :
                pipelines :
                    DicomToNifti :
                        create_nii : "N"
            OUA001_v01_mr :
                pipelines :
                    DicomToNifti :
                        create_nii : "Y"
users :
    owners : [owner]
    members : [member]
    collaborators : [collaborator]
pi :
    title : Dr
    firstname : Atticus
    lastname : Cromwell
investigators : [{firstname : Jens, lastname : Aasgaard}, {firstname : Arthur, lastname : Compton}]

Tips on the YAML above:


The anonymization section mirrors the syntax exactly of how it is used in Site Configuration, except now it is added to the project.

sessions versus complexSessions

The sessions element allows you to easily define an array of sessions which will all be uploaded to the XNAT server as is. So, while it is exceedingly easy to specify the sessions as an array like this, you lose power to fine-tune the sessions, as needed. So, if you want to do this, you specify the sessions under complexSessions, instead. The sessions here will also be uploaded through the session importer, but additional modifications will be added. So, the study_001 folder for this project should contain the following files:


The format for sharing differs depending on whether the object being shared is a subject or session. For a subject, the child elements of share are one or more destination projects. Each of these destination projects takes zero or more key-value pairs to customize the sharing. In the above example, subject Subj_004 is being shared into a single project, "DEST_PROJ" while being given the label "DEST_SUBJ_LABEL". In addition to specifying the label, also supported is passing shareAllSessions : true, which will share all of the sessions from this subject into the destination project with labels as is (included for convenience). The sharing for a session is easier. The child elements of share on a complexSession element are one or more key-value pairs of destination project to destination label of the session. So, in the above example, session 0000004 would be shared to project DEST_PROJ with the session label DEST_LABEL


If the users already exist, and the XNAT user running the script has access to the site user list, the users will be added to the project in their corresponding roles. If the users do not already exist, insecure users will be created (the password is just the username), which should not be used in production (this requires admin access).