▫︎ Data Prep Short-Reads (SE) - GDC First Aid Kit

Single-end processing is the exception, and usually a last resort rather than a plan.

Most Illumina amplicon projects can, and should, be designed to produce overlapping paired-end reads. You can buy kits for different cycle numbers (e.g. 500 cycles for PE250, or 600 for PE300), or adjust cycle numbers manually, to get enough overlap for your expected amplicon length. That overlap is valuable: it's what lets forward and reverse reads correct each other's errors during merging (see the Overview Workflows page for why), a benefit you lose entirely once you drop down to single-end processing.

Where This Fits, and Where It Differs

Apart from replacing read merging with fixed-length trimming, the overall logic of the workflow is the same as for paired-end data:

PE:  QC → Merge → Primer trim → Filter → Cluster → Taxonomy

SE:  QC → Trim R1 → Primer trim → Filter → Cluster → Taxonomy
             ↑
       replaces merging

	Paired-end	Single-end
Read merging	Yes	No
Error correction from overlap	Yes	No
Fixed-length trimming	Optional	Required
Read typically used	Merged R1+R2	R1 alone
Denoising (zOTU) confidence	Higher	Lower

When Do We Use This?

These are rare and unfortunate cases, and in practice we only resort to single-end processing for a small minority of projects. Sometimes the number of properly overlapping read pairs turns out to be low, because the actual amplicon length varies more than expected, or because of a faulty run. When that happens, only one read is used on its own, and it's usually R1, since read quality generally declines over the course of a sequencing run, and R2 is sequenced after R1, so it tends to accumulate more error and be the weaker of the two. That's a practical default rather than a rule: if R2 happened to be the stronger read for a given run, the workflow below would apply just as well to R2 instead, with only minor adjustments. Instead of merging reads, we trim the chosen read to avoid the low-quality bases that build up towards its end.

What You Lose Going Single-End

Dropping R2 means losing the built-in error correction that comes from two independent reads agreeing (or disagreeing) at each position, see the Overview Workflows page's discussion of merging as error correction. Denoising (UNOISE/zOTU) leans more heavily on this kind of signal than OTU clustering does, so single-end data going into Step E deserves a bit more scrutiny of the resulting clusters than paired-end data would. This isn't a reason to avoid single-end processing when it's genuinely your best option, but it is a reason not to treat SE and PE results as equally precise.

Fixed-Length, Not Quality-Based, Trimming

We deliberately trim R1 to a fixed length rather than trimming based on quality score. Quality-based trimming would cut different reads to different lengths depending on where their quality happens to drop, and variable-length reads complicate everything downstream: clustering, chimera detection, and error models generally assume reads of consistent length. A fixed cutoff, chosen from the quality profile of the run as a whole rather than read by read, keeps every read the same length and keeps those downstream steps well-behaved, at the cost of discarding a few more bases than a quality-based approach strictly would on any individual read.

Data Processing Steps - Explained

Step A - Quality Control, Data and Parameter Evaluation

Identical to Step A1 of the PE workflow, FastQC/MultiQC plus USEARCH's eestats and our own scripts, except that here we're also confirming that single-end is genuinely the right call, by checking read overlap statistics and R1/R2 quality profiles against each other, and determining the fixed trim length used in Step B from where R1 quality typically starts to drop off across the run.

Step B - Filter Reads and 3'-End Trimming

Identical to Step B of the PE workflow for the PhiX and low-complexity filtering, except that with no R2 to merge against, there is no merging step here. Instead, we trim every R1 read to the fixed length determined in Step A, cutting off the low-quality tail rather than merging it away. With no second read to cross-check against, this fixed trim is doing double duty: it's both a length-standardisation step and the main defence against the accumulated quality drop-off typical of the later cycles in a read, which in turn keeps clustering and taxonomic assignment downstream working from cleaner input.

Step C - Forward Primer Site Trimming

Identical to Step C of the PE workflow for the mismatch and wobble-base criteria: we trim the forward primer site from R1 the same way it's trimmed from the merged read in the paired-end workflow.

Read-Through in Short Amplicons

One consideration comes up here that doesn't apply once reads are merged. If your amplicon is shorter than the trimmed R1 length, the read can run through the far end of the amplicon and into the reverse primer's binding site, read as its reverse complement. Where this is expected, we screen for and remove that read-through sequence too, not just the forward primer, so it doesn't contaminate clustering downstream.

Step D - Size Selection & Quality Filtering

Identical to Step D of the PE workflow in the kind of quality, size, and composition filtering applied, just working from the trimmed R1 reads rather than a merged sequence. Because R1 alone has already had a fixed-length trim applied in Step B, the size selection window here is typically narrower than in the paired-end workflow, where merged read length can vary more with true amplicon length.

Steps E-G - Clustering, Taxonomic Assignment, and Extras

From here on, single-end processing rejoins the paired-end workflow entirely. Clustering (UPARSE/UNOISE), mapping, taxonomic assignment with SINTAX, and any marker-specific extras like ITSx all work the same way regardless of whether the input reads were merged pairs or trimmed single reads. See Steps E through G of the PE workflow for the full explanation. The main difference that carries through the rest of the analysis is that zOTUs inferred from single-end reads should be interpreted somewhat more cautiously than those from overlapping paired-end reads, since denoising no longer benefits from read-pair agreement.

GDC Report Files, by Step

This section is specific to how we organise processing at the GDC and won't be relevant if you're running your own pipeline elsewhere.

Step	What happens	Report
A	Quality control, data and parameter evaluation	`y_help/A_*.report`
B	Filtering and 3'-end trimming	`y_help/B_*_FFT_R1only.report`
C	Forward primer site trimming	`y_help/C_*_RMP_R1only.report`
D	Size selection and quality filtering	`y_help/D_*_QFR_R1only.report`
E	Clustering (OTU/zOTU)	`y_help/E*.report`
F	Taxonomic prediction	`y_help/F*.report`
G	Extras (e.g. ITSx for ITS amplicons)	`y_help/G_*.report`

The * in each filename is a placeholder for your project and sample identifiers.

Reproducibility

As with the paired-end workflow, every processing run is parameterised and logged. The reports listed above document the exact software versions, parameters, and modules used for your project.