Re-run Directory:/projects/tomato_genome/fnb/dataprocessing/SRP438952/nfcore-SL4
Prefetch SRR Script:

#! /bin/bash

#SBATCH --job-name=prefetch_SRR
#SBATCH --partition=Orion
#SBATCH --nodes=1
#SBATCH --ntasks-per-node=1
#SBATCH --mem=4gb
#SBATCH --output=%x_%j.out
#SBATCH --time=24:00:00

cd /projects/tomato_genome/fnb/dataprocessing/SRP438952/nfcore-SL4
module load sra-tools/2.11.0
vdb-config --interactive

files=(
SRR24685698
SRR24685699
SRR24685700
SRR24685701
SRR24685702
SRR24685703
SRR24685704
SRR24685705
SRR24685706
SRR24685707
SRR24685708
SRR24685709
SRR24685710
SRR24685711
SRR24685712
SRR24685713
SRR24685714
SRR24685715
SRR24685716
SRR24685717
SRR24685718
SRR24685719
SRR24685720
SRR24685721
SRR24685722
SRR24685723
SRR24685724
SRR24685725
SRR24685726
SRR24685727
SRR24685728
SRR24685729
SRR24685730
SRR24685731
SRR24685732
SRR24685733
SRR24685734
SRR24685735
SRR24685736
SRR24685737
SRR24685738
SRR24685739
SRR24685740
SRR24685741
SRR24685742
SRR24685743
SRR24685744
SRR24685745
)

for f in "${files[@]}"; do echo $f; prefetch $f;  done

Execute:

chmod u+x prefetch.slurm

sbatch prefetch.slurm

Faster Dump Script:

#! /bin/bash

#SBATCH --job-name=fastqdump_SRR
#SBATCH --partition=Orion
#SBATCH --nodes=1
#SBATCH --ntasks-per-node=1
#SBATCH --mem=40gb
#SBATCH --output=%x_%j.out
#SBATCH --time=24:00:00
#SBATCH --array=1-48

#setting up where to grab files from
file=$(sed -n -e "${SLURM_ARRAY_TASK_ID}p"  /projects/tomato_genome/fnb/dataprocessing/SRP438952/nfcore-SL4/Sra_ids.txt)


cd /projects/tomato_genome/fnb/dataprocessing/SRP438952/nfcore-SL4
module load sra-tools/2.11.0

echo "Starting faster-qdump on $file";

cd /projects/tomato_genome/fnb/dataprocessing/SRP438952/nfcore-SL4/$file

fasterq-dump ${file}.sra

perl /projects/tomato_genome/scripts/validateHiseqPairs.pl ${file}_1.fastq ${file}_2.fastq

cp ${file}_1.fastq /projects/tomato_genome/fnb/dataprocessing/SRP438952/nfcore-SL4/${file}_1.fastq
cp ${file}_2.fastq /projects/tomato_genome/fnb/dataprocessing/SRP438952/nfcore-SL4/${file}_2.fastq 

echo "finished"

Execute:

chmod u+x fasterdump.slurm

sbatch fasterdump.slurm

Nextflow Pipeline ran successfully with SL4 genome
Directory: /projects/tomato_genome/fnb/dataprocessing/SRP438952/nfcore-SL4
MultiQC report notes: No errors or warnings were present in the report. The strandedness did need to be changed to 'unstranded' instead of 'reverse' for SL4 it is saying but when you do change it to unstranded it says it need to be in reverse so I am keeping it at unstranded which did work for SL5. The output file is named 'SRP438952_SL4_multiqc_report.html'.

Next steps:
Commit multiqc report to Splicing repo on bitbucket
Change sorted bam names
Create junction files
Create Coverage graphs

Launch renameBams.sh script:
./renameBams.sh
Launch Scaled Coverage graphs script:
./sbatch-doIt.sh .bam bamCoverage.sh >jobs.out 2>jobs.err
Launch Junction files script:
./sbatch-doIt.sh .bam find_junctions.sh >jobs.out 2>jobs.err

Directory: /projects/tomato_genome/fnb/dataprocessing/SRP438952/nfcore-SL4/results/star_salmon

Reviewer:
Check that files have reasonable sizes (no "zero" size files, for example)
Check that every "FJ.bed.gz" file has a corresponding "FJ.bed.gz.tbi" index file
Check that every bam file has a corresponding "FJ.bed.gz" file
Check that every bam file has a corresponding "scaled.bedgraph.gz" file
Check that every "scaled.bedgraph.gz" has a corresponding "scaled.bedgraph.gz.tbi"

The folder does indeed exist!

ll *bed.gz | wc -l
48

We have 48 experiments coinciding with what is in the SRA.

Running these commands:
ll *bed.gz.tbi
988 ll *bed.gz.tbi | wc -l
989 ll *bed.gz | wc -l
991 ll *bam | wc -l
992 ll *bai | wc -l
995 cat *.err
996 ll *err
997 ll *bam
998 ll *bai
1000 ll *.bed.gz

(I have an alias ll that equald ll='ls -lrt'). So the above commands use this alias.

A weird warning!!
WARNING: BAM index file /projects/tomato_genome/fnb/dataprocessing/SRP438952/nfcore-SL4/results/star_salmon/SRR24685736.bam.bai is older than BAM /projects/tomato_genome/fnb/dataprocessing/SRP438952/nfcore-SL4/results/star_salmon/SRR24685736.bam

I don't think this is anything. But it might be good to test a few of these in samples in IGB to ensure everything is ok.
More than likely the .bai file was produced so quick, it gets a timestamp prior to the actual bam file.

All of the bam and bai files are the size as expected. So the warning above is likely nothing!!

And everything else looks as it should.

Branch: https://bitbucket.org/mdavis4290/molly-2-splicing-analysis/branch/IGBF-3544
PR: https://bitbucket.org/hotpollen/splicing-analysis/pull-requests/14

Suggestions for testing:

• Check that these new quality control reports are consistent with the original quality control reports obtained when we processed the original, pre-submission data files. The results should be the same.

Molly Davis - please see above comment on how to test. I don't know if you have already compared the files or not?

If not, it would be good to do that now.

The QC reports provide a great overview of a data processing run. Comparing the QC reports pre- and post-SRA submission will tell us a lot. For example, if there are a big differences between the pre- and post-SRA submission files, the QC report will likely show it.

The original mature pollen and seedlings data on the cluster was not run with SL4, only SL5. So the next step would be to run the original data with SL4 and then compare the rerun SL4 report with the original report.

When I make the comparison ticket for mature pollen and seedling I will compare the mutliqc reports then so for now I will move this ticket to Done!