"consensus" peaks are generated even when samples have only 1 replicate

[kopardev]

• consensus peak should be same as the replicates' peak call.
• no need to redo everything downstream

[kopardev]

Resolved in the current code.

For single-replicate samples, ASPEN does not run the multi-replicate consensus logic. Instead, it reuses the replicate peak call directly as the consensus output. This is implemented in:

• workflow/scripts/ccbr_atac_macs2_peak_calling.bash
• workflow/scripts/ccbr_atac_genrich_peak_calling.bash

The relevant logic is the single-replicate branch:

• if the replicate count is 1, the script copies the replicate output into the pooled-style filenames and writes the consensus BED directly from the replicate peak file (cut -f1-3 ... > <sample>.consensus.bed)
• no separate consensus recomputation is performed for one replicate
• this matches the issue requirement: no redundant downstream consensus generation and no unnecessary re-do of work when only one replicate exists.

This requirement is therefore already satisfied in the current implementation.

[kopardev]

This issue is resolved in the current ASPEN code.

I verified the single-replicate behavior in:

• workflow/scripts/ccbr_atac_macs2_peak_calling.bash
• workflow/scripts/ccbr_atac_genrich_peak_calling.bash

For nreplicates == 1, the script does not run the multi-replicate consensus recomputation path. Instead, it:

1. copies the replicate output into the pooled-style filenames expected downstream, and
2. writes the consensus BED directly from the single replicate peak file (cut -f1-3 ... > <sample>.consensus.bed)

This matches the original requirement: a single replicate reuses its own peak call as the consensus output, without redoing consensus generation downstream.

This is therefore fixed and can be closed.

[kopardev]

Issue resolved in the current code: single-replicate samples reuse the replicate peak call as consensus output without running the multi-replicate consensus logic.