Quality control,before anything else
FastQC across every read file you point it at.One HTML report per input, written back to output.
$ dxflow workflow create --identity fastqc hub://fastqc --start
A report,for every file
FASTQ, BAM or SAM in; an HTML report and a ZIP back out.
FASTQ, BAM or SAM, matched by the INPUT glob you set at the start.
An HTML report and a ZIP of the numbers, one pair for every input.
THREADS is how many files it takes at once, not threads in a file.
Point it at the reads,and read what comes back
Files go up into input, reports come down out of output, and three variables sit between them.
$ dxflow artifact upload sample_R1.fastq.gz input/
$ dxflow workflow start fastqc --override env.job.INPUT=/data/input/*.bam
$ dxflow artifact download output/ ./reports/
It runs,and then it stops
A job, not a session — it ends when the last report is written.
A pass, a warnor a fail, per module
Every input leaves two files behind, and every module inside them carries a verdict.
An HTML report to read, and a zip holding the tables behind it. Pass --extract to unpack those too.
Quality falling away at the 3' end means trimming. An odd GC curve usually means something else got in.
Adapter content sends you to a trimmer. Reads that came back clean go straight on to alignment.
Pulled once,then it stays
FastQC arrives as one image. This is what comes down the first time, and what the disk should have free for it.
What it wants,and what it needs
The definition asks for 4 cores and 4 GB. The image comes up on less than that, and a start given --fit trims the ask to whatever the machine actually has.
Machines that fit it
FastQC asks for 4 cores and 4 GB. Cheapest first.