That is true, but the code at the moment also has no dependency on being sorted correctly.  Its current usage in the pipeline ensures that its input bam is both correctly sorted and has been through FixMates.

If SplitBamByChromsoome is to be used independently, then I agree that it would need to ensure that the input bam has been through FixMates, and also that it was correctly sorted, as per Steve's suggestion.  It feels to me that pull request 56 and Steve's request would need to be one change, though not necessarily done at this point in time.

On 28 Aug 2013, at 15:55, Steven Leonard wrote:

> if we are changing SplitBamByChromosome.jar we should add a check that reads are sorted so paired reads are guaranteed to be next to each other, which is not the case for alignment ordered reads. The code processes reads with the same template as a single unit but only if they are next to each other. This is why Kate had problems when she ran the code on an alignment ordered bam file.
> 
> Steven

 
On 10 Sep 2013, at 15:51, dkj wrote:

> In src/uk/ac/sanger/npg/picard/SplitBamByChromosomes.java:
> 
> > @@ -221,6 +221,11 @@ private void writeGroup(ArrayList<SAMRecord> groupOfReads,
> >  				} else {
> >  					unaligned = false;
> >  				}
> > +			} else { // one or both reads are unmapped
> > +				if ((EXCLUDE_UNALIGNED) && (SUBSET.contains(rec.getReferenceName()))) {
> > +					// FixMate has reset * Y or * Y to Y Y
> Code at the moment has no dependancy on fixmates having been run - only that read records from the same template are collated together.
> 
> —
> Reply to this email directly or view it on GitHub.
>