problems with bwa

[Kotoro]

seeing this message:
[infer_isize] fail to infer insert size: too few good pairs

vast majority of reads/pairs are marked unaligned.

Quality data from SolexaQA doesnt indicate any problems with quality scores. (it also autodetects the scores as standard sanger scores)

These files previously had mapped fairly well to the same reference genome. (in march 2012, when we first received them)
OS: CentOS linux 64 bit nodes on a cluster managed by CCAM group @ UConn Health Center.

i'm currently trying a bowtie2 run to see if I get the same problem. Is there a problem with new versions of BWA? I have references that were built after the 6.0 upgrades.)

I have absolutely no idea whats wrong.

[swbarnes2]

Have you started by blasting some reads to confirm that they do align to the reference they ought to align to?

[Kotoro]

Have you started by blasting some reads to confirm that they do align to the reference they ought to align to?

These files previously had mapped fairly well to the same reference genome. (in march 2012, when we first received them)

I dont want to be rude, but an adequate answer to the question was in my post.

I still have those bam files, and I CAN use them but i'm trying to figure out why the alignments i'm attempting NOW, are failing.

also, an update on bowtie2 run, it produced usable alignments.

This does appear to be a problem either with BWA or the index I was using. I'm currently generating a new index off the fasta file. (we originally were using the igenomes files but recently started using gatk bundle, but I don't think that change would account for the switch from 75% alignments to less than 1% alignments)

[GenoMax]

Is the same cluster being used for the current alignments as compared to last year (and are you using the latest bwa release)?

Generating your own indexes is certainly one thing to try. The problems may magically go away with that index.

[vivek_]

I'd think there might be a possibility that the index files might cause some issues if the human reference is from different sources. NCBI has a version of human reference with additional patches, which is different from the GATK bundle. I had an issue when I used one reference for alignment and another for SNP calling and it introduced twice the number I initially expected.

[Kotoro]

Is the same cluster being used for the current alignments as compared to last year (and are you using the latest bwa release)?

Its a different cluster, but I stage all my own non-system binaries (and even some standard libraries, in the cases where I need newer versions than the admins installed), so as far as software versioning goes, that doesn't really impact it all that much. I did update to the newest release during my attempt to fix the problem. It didn't impact it at all, but I figured it was worth a shot.

Generating your own indexes is certainly one thing to try. The problems may magically go away with that index.

The weird thing is the one I had been attempting to use was generated manually a few months back, (after the 1.6 updates), so I don't really know why there was a problem. I'm still doing it again though just in case.

[Kotoro]

I'd think there might be a possibility that the index files might cause some issues if the human reference is from different sources. NCBI has a version of human reference with additional patches, which is different from the GATK bundle. I had an issue when I used one reference for alignment and another for SNP calling and it introduced twice the number I initially expected.

sure, but I didnt switch that far into the analysis. The problem came immediately after alignment. the problem being that there was no alignment. (meaning I also had no opportunity to erroneously switch indices)

[Kotoro]

Sure enough something was wrong with the index. Wish I knew what & why.