Gene order and strand orientation flip between single lane and merged lane inputs (identical read counts)

[EDohmen]

Hi Sebastian,
I noticed recently a behavior where Arriba flips the gene call order (gene1/gene2) and the transcription strand orientation when comparing a single sequencing lane input against a merged FASTQ input (concatenated lanes), despite the underlying supporting read evidence being identical and would like to have your opinion about it.

Dataset Context

• Library: Paired-end RNA-seq
• Inputs compared:
  • Single Run: Original R1.fastq.gz and R2.fastq.gz from a single lane
  • Merged Run: samples from two lanes merged (lane1_R1 + lane2_R1 into merged_R1.fastq.gz, and same for R2).

Observed Behavior
The fusion event is caught in both runs with identical split read and coverage counts, confirming the second sample contributed no new evidence for this specific event and the exact same reads are being used. However, the output properties flip:

Input	Gene 1	Gene 2	Strand 1	Strand 2
Single Run	GENEY	GENEX	-/-	+/+
Merged Run	GENEX	GENEY	+/-	-/+

Questions
Do you have an explanation for this behaviour?

• is there any kind of heuristic tie-breaking in Arriba that would depend on read order for example?
• could this be influenced by multi-threaded alignment or other STAR alignment differences between the merged and the single run?
• which orientation would you trust more in this case?

Thank you for your insight and for maintaining such a great tool!
Cheers,
Elias

[suhrig]

Hi Elias,

Is this single-end or paired-end data? The most recent version has a fix for strand detection of SE data.

Are both runs stranded or unstranded or mixed?

Am I assuming correctly that the breakpoints do not coincide with splice sites?

Best regards,
Sebastian

[EDohmen]

Hey Sebastian,
thanks for the quick response.
It is paired-end and unstranded.
And you're right that the breakpoints do not coincide with splice sites, they are in an exon and in an intron.
Thanks for your help!
Best,
Elias

[suhrig]

In the case of unstranded data, usually Arriba should prefer the strand of the gene with the exonic breakpoint. If Arriba cannot determine the strand from the strandedness of the read (because it is unstranded), it tries to infer the strand from the splice pattern. If that fails, too, it looks for plain exon overlaps (without matching splice pattern).

It tries to infer the strand for every read independently. Then, it sums up the number of reads mapping to the predicted + strand and compares it to the number of reads mapping to the predicted - strand. Whichever is greater decides what the final strand for the fusion is.

Given that Arriba detected the strands as matching with the annotation in the single-lane run and then throws it all over to the opposite when the merged lanes are used, the additional reads from the merged run must have added more reads to the opposing strand such that in sum there are more supporting reads for the antisense strand than the sense strand.

is there any kind of heuristic tie-breaking in Arriba that would depend on read order for example?

No, there shouldn't be. The fusion-supporting reads are sorted before analysis, so read order should not matter.

could this be influenced by multi-threaded alignment or other STAR alignment differences between the merged and the single run?

No, since the alignments should be the same (just different order).

which orientation would you trust more in this case?

Hard to say. The single-lane run makes more sense. But the merged-lane run has more evidence. In any case it is not really a clear situation. If you can share the alignments of the fusion-supporting reads (the ones mentioned in the column read_identifiers from the BAM file), then I can take a look and give my "expert opinion" and also check out why Arriba flips the strand assignment.

[EDohmen]

Thanks a lot for your help and offer. I just sent you an email to top-notch-bioinformatics with the reads and arriba output.

[suhrig]

I have received your example file. I will be on vacation the next week. I'm unsure if I will manage to investigate this before.