Repository navigation
Generate DiffATAC counts matrices/results from both filtered.bam and dedup.bam #138
Description
Background
filtered.bam (quality-filtered) is produced before Picard MarkDuplicates runs, so it retains PCR duplicates; dedup.bam is derived from filtered.bam by marking + removing duplicates. Currently, both the Tn5 nicking-sites and read-counts matrices used for DiffATAC (DESeq2/edgeR) are generated from tn5sites_bam/reads_bam, which are built from filtered.bam (see create_tn5bams in workflow/rules/align.smk) — i.e. duplicates are not removed before counting today.
Standard ATAC-seq practice (ENCODE ATAC pipeline, ArchR, Signac, DiffBind/csaw) counts from deduplicated fragments, since PCR duplication rate varies by sample (input amount, PCR cycles, library complexity) and isn't corrected by DESeq2/edgeR size factors, which can confound differential accessibility calls.
Counter-consideration: Tn5 insertion is biased toward accessible chromatin, so independent molecules can genuinely converge on the same insertion coordinate at highly accessible sites — Picard's paired-end duplicate definition (requires both fragment ends to match) partially mitigates this, and ROI windows (fixed_width: 500 by default) further dilute the effect, but it's not eliminated.
Proposal
Rather than picking one BAM source, generate both counts matrices and DiffATAC results — one from filtered.bam, one from dedup.bam — in separate output folders, so users can compare/choose.
Plan
Add a BAM_TYPES = ["dedup", "filtered"] axis and thread it through existing rules as a wildcard (not duplicated rules):
align.smk—create_tn5bams: wildcard on{bamtype}so it runs once per BAM type, writing tovisualization/{bamtype}/tn5sites_bam/...andvisualization/{bamtype}/reads_bam/....create_bigwigs: same wildcard threading (open question: needed for both types, or just counts/DESeq2?).diffatac.smk—get_counts_table/scale_counts_table/diffatac: add{bamtype}wildcard so outputs land inpeaks/{peakcaller}/fixed_width/counts/{bamtype}/...andpeaks/{peakcaller}/DiffATAC/{bamtype}/{method}/....init.smk: defineBAM_TYPESand extendget_diffatac_input()/final target list to expand over it.- Docs: update
docs/outputs.mdanddocs/extra.mdto explain both folders and give guidance (recommenddedupfor standard differential testing;filteredretained for comparison, with the Tn5-convergence caveat noted). - CHANGELOG: user-facing entry for the new
dedup-based counts/DiffATAC outputs alongside the existingfiltered-based ones.
Open questions
- Should
dedupbe the default recommended path (highlighted in docs) whilefilteredis kept for backward compatibility, or present both as equal options? - Duplicate bigwigs per
bamtype, or just counts matrices/DiffATAC results (to limit extra compute/storage)? - Naming:
dedup/filtered, or something likededup/nondedupfor folder-name clarity?
⚡ Generated using AI ⚡
Activity
chore(gitignore): ignore local plans/ directory
feat(diffatac): generate dedup and nondedup counts/DiffATAC outputs
docs: overhaul documentation for accuracy and ELI15 clarity
Dedup/nondedup outputs, spike-in fail-fast fix, and docs audit (#140)