Difference between revisions of "Trinity"
m (Text replacement - "#uppercase" to "uc")
m (Text replacement - "/ufrc" to "/blue")
|Line 43:||Line 43:|
=Local Drive Use=
=Local Drive Use=
You must use local scratch directories on compute nodes for Trinity output and then only copy the results back to your /
You must use local scratch directories on compute nodes for Trinity output and then only copy the results back to your // directory tree. Local scratch directory for a job is available via the $TMPDIR variable provided by SLURM. Put the output directory under $TMPDIR and then copy that directory to your /space ''at the end of the job''. If you do not use $TMPDIR for staging out the Trinity output directory your job(s) could be cancelled without warning. See [[Temporary Directories]] for more information.
Revision as of 19:22, 11 February 2021
Trinity, developed at the Broad Institute and the Hebrew University of Jerusalem, represents a novel method for the efficient and robust de novo reconstruction of transcriptomes from RNA-seq data. Trinity combines three independent software modules: Inchworm, Chrysalis, and Butterfly, applied sequentially to process large volumes of RNA-seq reads. Trinity partitions the sequence data into many individual de Bruijn graphs, each representing the transcriptional complexity at at a given gene or locus, and then processes each graph independently to extract full-length splicing isoforms and to tease apart transcripts derived from paralogous genes. Briefly, the process works like so:
Inchworm assembles the RNA-seq data into the unique sequences of transcripts, often generating full-length transcripts for a dominant isoform, but then reports just the unique portions of alternatively spliced transcripts.
Chrysalis clusters the Inchworm contigs into clusters and constructs complete de Bruijn graphs for each cluster. Each cluster represents the full transcriptonal complexity for a given gene (or sets of genes that share sequences in common). Chrysalis then partitions the full read set among these disjoint graphs.
Butterfly then processes the individual graphs in parallel, tracing the paths that reads and pairs of reads take within the graph, ultimately reporting full-length transcripts for alternatively spliced isoforms, and teasing apart transcripts that corresponds to paralogous genes.
- HPC_TRINITY_DIR - installation directory
- ALLPATHSLG_BASEDIR - Allpaths-LG installation directory
To run Trinity after you load the module use the "Trinity" command.
Compute Partition Use
It was empirically determined that local drives in the hpg1-compute partition are better suited for the Trinity i/o patterns than hpg2-compute node drives. HPG1 compute nodes also have twice as many CPU cores (64) and twice as much memory (250gb) as HPG2 nodes. Use the following in your job scripts:
For jobs that require more than 250gb of memory to run Trinity use the bigmem partition.
Local Drive Use
You must use local scratch directories on compute nodes for Trinity output and then only copy the results back to your /blue/ directory tree. Local scratch directory for a job is available via the $TMPDIR variable provided by SLURM. Put the output directory under $TMPDIR and then copy that directory to your /blue space at the end of the job. If you do not use $TMPDIR for staging out the Trinity output directory your job(s) could be cancelled without warning. See Temporary Directories for more information.
Java Heap Memory
If the run produces an error that states that java could not create a virtual machine due to insufficient heap memory you can set the java memory with a command that looks like
either at the command line if doing an interactive run on a test node or in the job script. Make sure that the value in the "-Xmx" is less than the amount of memory you requested from the batch system.
The default Butterfly memory setting in the Trinity script is '-Xmx20G', so plan your job resource request accordingly.