Raw Read QC
This module answers one question: what do the raw Great Auk reads actually look like, before we change anything? It is diagnostic, not corrective. You will run FastQC and MultiQC, open and read their real HTML reports, and write a QC diagnosis — but you will not trim, filter, merge, map, or otherwise modify a single FASTQ file. That's Module 04.
Learning objectives
- Tell FASTA and FASTQ apart confidently, by structure, not just by filename
- Explain what a Phred quality score means, without the maths overwhelming the concept
- Explain what FastQC does — and does not do — to a FASTQ file
- Run FastQC on a real Great Auk run, interactively, and read its HTML report
- Interpret the major FastQC panels biologically, not as a pass/fail scoreboard
- Distinguish FastQC's surface patterns from confirmed ancient-DNA damage
- Run FastQC and MultiQC across all 13 libraries reproducibly
- Compare libraries and write a QC diagnosis that justifies later preprocessing choices
FASTA vs FASTQ
FASTA and FASTQ are file formats, not analysis methods — worth saying plainly, since the names and the letters FASTA/FASTQ are easy to blur.
| FASTA | FASTQ | |
|---|---|---|
| Stores | Sequence only | Sequence + per-base quality |
| Record length | Header + sequence (any number of lines) | Exactly 4 lines per read |
| Typically represents | A reference genome, assembly, contig, scaffold, chromosome, or consensus sequence | One sequencing read |
| Common extensions | .fa, .fasta, .fna | .fastq, .fq (usually .gz) |
| In this project | The razorbill reference genome | The Great Auk raw reads |
A FASTA file can contain one or many FASTA records — each one may represent anything from a single gene to an entire chromosome. A FASTQ file also contains many records: each FASTQ record represents exactly one sequencing read and occupies exactly four lines. FASTQ files therefore often contain millions of reads and can be very large, even though each individual record is short.
>scaffold_12 ACTGACTGACTGGGTTCAGCTAGCATCGATCGTAGCTAGCATCGATCG...
Classify each of the following as FASTA or FASTQ, and write down how you know — extension, structure, or both:
Alca_torda_genomic.fnaSRR32500061.fastq.gzreference.fa- the 4-line record shown above
- the
>scaffold_12record shown above
Extensions are a useful clue (same as Module 01's file command lesson) but can be wrong or missing. The structural tell is absolute: does it have a per-base quality line or not?
Show model answer
Alca_torda_genomic.fna — FASTA (extension + it's a reference genome). SRR32500061.fastq.gz — FASTQ (extension + it's raw sequencing data). reference.fa — FASTA. The 4-line record — FASTQ (has a quality line). The >scaffold_12 record — FASTA (header line, no quality line).
Why can FastQC analyze a FASTQ file but would have nothing meaningful to say about a reference FASTA's sequencing quality?
What does read quality mean?
Each base call gets a Phred quality score — higher means a lower estimated probability that base is wrong. It's per-base, which is exactly what FASTQ's quality line (line 4) encodes, one character per base of line 2.
| Phred score | Approx. error probability | Approx. accuracy |
|---|---|---|
| Q10 | 1 in 10 | 90% |
| Q20 | 1 in 100 | 99% |
| Q30 | 1 in 1,000 | 99.9% |
Sequencing quality is not the same thing as biological usefulness. A low-quality base might still be biologically real; a high-quality base can still come from contamination or an artifact. Phred scores tell you about measurement confidence, not biological importance.
Look at the quality line from Exercise 1 (IIIHHHGF). Without calculating anything precisely, which end of the read looks higher quality, and which looks lower? (Hint: later letters in this range are generally higher quality than earlier ones in standard Phred+33 encoding.)
Why isn't a low Phred score automatically a biological problem, as opposed to a measurement one?
What does FastQC actually do?
FastQC is a diagnostic tool: it reads a FASTQ file, summarizes its properties, and reports them — it never modifies the file itself.
You'll meet these modules properly in Exercise 6 — no need to memorize them now: Basic Statistics, Per base sequence quality, Per sequence quality scores, Per base sequence content, Per sequence GC content, Sequence Length Distribution, Sequence Duplication Levels, Overrepresented sequences, Adapter Content.
Before running anything, predict: which one or two of the modules listed above do you expect might show a warning for ~170-year-old museum DNA, and why? (You'll check this prediction in Exercise 7.)
Does FastQC ever conclude that an entire dataset is unusable, or does it only ever flag individual modules?
Run FastQC on one real library
For a single quick exploratory run like this one, an interactive Slurm job is more convenient than writing a whole batch script for one command — it gives you a live shell directly on a compute node. Mjolnir's documentation gives this verified pattern for starting one:
srun --partition=cpuqueue --qos=normal --nodes=1 --cpus-per-task=2 --mem-per-cpu=2G --time=01:00:00 --pty bash
The specific resource numbers (2 CPUs, 2 GB per CPU, 1 hour) are a modest teaching allocation chosen for this exercise — Mjolnir's docs don't prescribe particular values for FastQC specifically, just this general pattern for requesting an interactive session.
Start an interactive session, check whether fastqc is available, load it, create
an output directory, and run FastQC on SRR32500061 — the smallest run, already on
disk from Module 02.
FastQC's -o output directory must already exist — it won't create one for you.
Show command
Replace <version> with whatever module avail fastqc actually shows you.
Why does this single-file, exploratory run make sense as an interactive job rather than a batch script? What would you lose by submitting it with sbatch and walking away instead?
Open and inspect the FastQC HTML report
FastQC produced two things: SRR32500061_fastqc.html (a fully self-contained
report — every plot is embedded directly in the HTML, so this one file is all you need to
view it) and SRR32500061_fastqc.zip (the same data in parsed form, which should
stay on Mjolnir — Exercise 9's MultiQC step reads directly from files like
this one).
Mjolnir is remote, so you can't just double-click the HTML file where it sits — you need to
copy it onto your own computer first. scp ("secure copy") does exactly this,
over the same SSH connection you already use to log in.
The command has the shape scp <username>@<mjolnir-host>:/full/path/to/file .:
<username>@<mjolnir-host>:— the remote server (your KU-ID and the same host you SSH into)/full/path/to/file— where the file lives on Mjolnir.— "here" — the current directory on your own computer
This only matters for small result files like HTML reports — never copy the large raw FASTQ files back to your laptop this way.
Run scp to copy SRR32500061_fastqc.html from Mjolnir to your own
computer, then open it in a browser.
Run this command from your own computer's terminal, not from inside your Mjolnir SSH session — scp needs to start from the machine you want the file to end up on.
Show command
Replace /full/path/to/... with the real absolute path pwd gives you on Mjolnir. Once it's downloaded, open the file directly — double-click it, or drag it into a browser window.
If you want the FastQC HTML file to end up on your laptop, where should you actually run the scp command — your laptop's terminal, or your Mjolnir SSH session? Separately: why is it enough to copy only the .html file, and not the .zip, just to look at the plots?
Interpret the FastQC plots
For each panel in your real report, ask the same four questions: what does it measure? What pattern do you actually see? Is that pattern necessarily a problem? Would you act on it immediately, or investigate further?
| Panel | What it measures | How to interpret it in historical DNA |
|---|---|---|
| Basic Statistics | Total sequences, sequence length, GC% | Raw read length reflects the sequencing setup, not necessarily the original DNA-fragment length. A ~101-bp read can come from a shorter molecule if sequencing continues into adapter sequence. |
| Per base sequence quality | Box plots of quality by position along the read | Quality often declines toward the end of Illumina reads, but this is not specific to historical DNA. Interpret the profile before deciding whether any bases need trimming. |
| Per sequence quality scores | Distribution of each read's average quality | A lower-quality subset may indicate technical variation among reads; it is not by itself an ancient-DNA signature. |
| Per base sequence content | A/C/G/T proportions by position | End-position biases can reflect fragmentation and library-preparation effects. FastQC alone cannot tell whether a pattern represents ancient-DNA damage. |
| Per sequence GC content | Distribution of per-read GC% | Shifts, broadening, or extra peaks can have several causes, including mixed sequence sources or technical bias; FastQC alone cannot identify the cause. |
| Sequence Length Distribution | Spread of read lengths | In these raw reads, lengths may be nearly uniform because sequencing was performed to a fixed read length. This does not mean the original DNA molecules were equally long. Length distributions become especially informative after adapter trimming. |
| Sequence Duplication Levels | How often identical reads recur | High sequence duplication can be consistent with low library complexity and substantial amplification of low-input historical DNA. FastQC sequence duplication is not the same as identifying PCR duplicates after mapping. |
| Overrepresented sequences | Specific sequences appearing unusually often | Adapter sequence is one possible cause, but other recurrent sequences can also be overrepresented; inspect what FastQC identifies rather than assuming. |
| Adapter Content | Detected adapter sequence by position | Short DNA inserts can cause sequencing to continue into the adapter. This is particularly relevant for fragmented historical DNA and is a key observation for deciding on adapter trimming. |
Open your own SRR32500061_fastqc.html and, for at least four of the panels above, write down what you actually observe and your answer to all four questions.
Pick one panel where your report shows a warning or fail. Is that necessarily a problem? What would you want to check before deciding either way?
What can ancient DNA make look "weird"?
Several real, well-documented features of historical/ancient DNA can make FastQC plots look unusual: short fragments; adapter read-through (when the DNA fragment is shorter than the sequencing read, the read runs past the fragment into adapter sequence); unusual base composition near read ends; high duplication from limited library complexity; and damage-associated substitutions concentrated near molecule termini.
Keep these three separate: what FastQC can actually show you (a pattern); what you can only hypothesize from it (a possible cause); and what requires real downstream testing (confirmation).
Revisit your Exercise 3 predictions. Which modules actually showed a warning or fail? Which of your predictions were right, and which weren't?
If your report shows an unusual base-composition pattern near the read ends, is that proof of ancient DNA damage? What would you actually need to do to test that hypothesis properly?
Run FastQC on all 13 Great Auk libraries
Now that you understand one report, scale up — the same way Module 00 taught you to move from an interactive exploration to a reproducible batch job. FastQC can take many input files at once and process them in parallel with -t, which is simpler and more honest than writing a 13-iteration shell loop.
Write and submit a batch script that runs FastQC on all 13 Great Auk FASTQ files in one call, writing everything into the same analysis/raw_qc/fastqc/ directory.
FastQC's own filename-based naming (e.g. SRR32500061_fastqc.html) already keeps the 13 outputs distinguishable in one flat directory — no need for per-run subfolders.
Show command
-t 8 processes up to 8 files simultaneously — all 13 will still complete in one job, just with a short queue of 5 once the first 8 are underway.
Why does one fastqc call with -t 8 handling all 13 files make more sense here than either 13 separate commands or 13 separate job submissions?
Summarise all libraries with MultiQC
FastQC analyzes one FASTQ at a time. MultiQC collates many FastQC outputs — reading the .zip files, not the HTML — into a single comparative report.
MultiQC itself is lightweight, but since you'll already be inside a real analysis job from Exercise 8, it makes sense to add it as a second command in the same batch script rather than hopping back to the login node for one more step of the same workflow.
Check that multiqc is available, then add it to your Exercise 8 script (or a short follow-up job) to summarise analysis/raw_qc/fastqc/ into analysis/raw_qc/multiqc/. scp the resulting report down and open it, the same way you did in Exercise 5.
Show command
Produces multiqc_report.html — also self-contained, same scp approach as Exercise 5.
Why does MultiQC need the .zip files FastQC produced, rather than the .html files?
Compare libraries and write a QC diagnosis
The library names fall into groups — G, GH, lib, lib2 — but exactly like Module 02 Exercise 8, don't infer what these groupings mean beyond what the data actually show you. Use the MultiQC report to look for patterns, not to confirm a story you've already decided on.
Using the real MultiQC report, compare read counts, sequence lengths, quality profiles, GC content, duplication, and adapter content across all 13 libraries. Then ask:
- Do libraries with similar names cluster visually in the report?
- Are there obvious outliers?
- Which patterns are consistent across all 13 libraries?
- Which differ, and between which libraries?
- What would you want to investigate further before preprocessing?
Finish with a short written QC diagnosis: what looks good, what looks unusual, what may be expected for historical DNA specifically, what potentially needs action, and what you cannot yet conclude.
Which single library would you want to look at individually before deciding how to preprocess all 13 together, and why?
Module 03 summary
We have now inspected the raw reads without altering them. We know what the major QC patterns look like across the 13 Great Auk libraries, and can use those observations to decide what preprocessing is actually justified.
Looking ahead — Module 04: Preprocessing raw historical-DNA reads. Adapter trimming, read trimming/filtering, minimum length thresholds, single-end ancient-DNA considerations, and producing cleaned FASTQ files while preserving the raw originals all belong there — none of it happens in this module.