[fh331]

Looking at your reads, it seems you had a problem when you extracted them from the CRAm files. They look exactly similar with a shift of 3-4 bp...

I peeked into the original cram file using the following command and the result is the same Fastq. So i don't know if the Cram decompression to Fastq has caused the problem:

fazal@fazal-Precision-T1700:/media/fazal/backup/BCL11A/Cram$ java -jar /opt/cramtools-3.0.jar fastq -I 18418_2#1.cram | head -20
@HS32_18418:2:2307:11553:47098#1/1
CCTAACCCTAACCCTAACCCTAACCCTAACCCTAACCCTAACCCTAACCCTAACCCTAACCCTAACCCTAACCCT
+
BBBBBBF/FFFFFFFFFFFFFFFFFFFFFFFFFFFBBFFFB</<FFFF//FFFFFFFBBF<FFFFFFBF/B<FF/
@HS32_18418:2:2307:11553:47098#1/2
TAACCCTACCCCTAACCCTAACCCTAACCCTAACCCTAACCCTAACCCTAACCCTTACCCTAACCCTAACCCAAC
+
</FBB<///F<BF/B/F<FB<<FB<B<FFF/BFFBFBBB<FFB<FFFFBFFFFFF<FFFF/FFBFFF<FFBBBBB
@HS32_18418:2:1201:20716:93279#1/2
ACCCTAACCCTAACCCTAACCCTAACCCTAACCCTAACCCTAACCCTAACCCTAACCCTAACCCTAACCCTAACC
+
BBBBBFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFBFFFFF//FFB
@HS32_18418:2:1201:20716:93279#1/1
AACCCTAACCCTAACCCTAACCCTAACCCTAACCCTAACCCTAACCCTAACCCTAACCCTAACCCTAACCCAAAC
+
/<FFF</<FBF<</FFFBF<FFFFBBFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFBBBBB
@HS32_18418:2:1102:8324:84406#1/1
CTAACCCTAACCCTAACCCTAACCCTAACCCTAACCCTAACCCTAACCCTAACCCTAACCCTAACCCAAACCCTA
+
BBBB</<<FFFFFBBF<<BFFBB/F/<<<<F/FFFFFBBB<F//B/F/<FBFFB//</BFFBB/</////</7/<

[fh331]

These sequences (CCCTAA) are from the telomere repeat. CRAMs are sorted files so, depending on the reference used for alignment, it's not unusual to see all of these reads at the beginning of the file.

What IS unusual is that both reads are from the same strand, when one should be the reverse complement of the other (e.g., TTAGGG). Not sure how that happened, but it's likely to be the reason why realignment failed.

Hi HESmith,
Bear with me for the silly and naive question i am about to ask: In PE chipseq, pair of reads should be completely reverse complementary to each other or there is like a region in which the reads are reverse complementary?

[GenoMax]

Hi HESmith,
Bear with me for the silly and naive question i am about to ask: In PE chipseq, pair of reads should be completely reverse complementary to each other or there is like a region in which the reads are reverse complementary?

They will only be completely rev-comp of each other, IF the insert size=number of F/R sequencing cycles (not likely for every fragment in your library).

[fh331]

Are you sure the reads in file 1 and file 2 are in the same order? Just print the first 5 reads of each file...

You can also try to map only one file (not considered as paired-end then) to see the percentage of mapped reads...

Hi SylvainL,
I tried to align single file from the PE. Here's the output report and worked fine i think:

fazal@fazal-Precision-T1700:/media/fazal/backup/BCL11A/FastQ_Files$ bowtie -m 1 -S /media/fazal/backup/BCL11A/Bowtie_Indices/Bowtie1_Index/human_g1k_v37.fasta 18418_2-1_1.fastq > /media/fazal/backup/BCL11A/Sam_from_FastQ/18418_2-1_1.sam
# reads processed: 40095362
# reads with at least one reported alignment: 33362937 (83.21%)
# reads that failed to align: 2434332 (6.07%)
# reads with alignments suppressed due to -m: 4298093 (10.72%)
Reported 33362937 alignments to 1 output stream(s)

No I don't know what's going wrong with aligning the two PEs together?

I am kind of getting frustrated

[fanli]

Like @HESmith said, you may have a problem with the orientation of your read pairs.

The default orientation for valid alignments in bowtie1 is --fr. If your read pairs got converted somehow to ff, then none of the alignments would be valid.

[SylvainL]

Probably the wrong orientation came from the exportation of the reads from the CRAM files. As fanli said, change the setting in bowtie (or reverse complement the reads 2)