Bam Coverage

[peter.mc...@gmail.com]

Hi Fidel,

Just got hold of some BAM files from a collaborator and used BAM coverage to take a quick look. However, the resulting bigwig shows blocks rather than reads (see example attached). 

I thought I was dealing with BAM from a ChIP-Seq but after running samtools flagstat found that it was paired end and though I could also be dealing with RNA-seq data. 

I then went back and played around with some of the parameters (e.g. extend paired end, only neg strand) but continue to see the same results. 

Am I missing something super basic here?!

Thanks again for Deeptools!!!!!

Kind regards,

Peter

Parameters for attachment:

BAM file	1: No_Dox_D12.bam
Bin size in bases	50
Scaling/Normalization method	1x
Effective genome size	2451960000
Scaling factor	1.0
Coverage file format	bedgraph
Region of the genome to limit the operation to
Show advanced options	yes
Smooth values using the following length (in bases)	None
Regions that should be excluded for normalization
Ignore missing data?	False
Extend reads to the given average fragment size.	yes
Ignore duplicates	False
Center regions with respect to the fragment length	False
Minimum mapping quality	1
Include reads based on the SAM flag	None
Exclude reads based on the SAM flag	None
Determine nucleosome positions from MNase-seq data	False
Only include reads originating from fragments from the forward or reverse strand.	no

[Friederike Dündar]

Hi Peter,

I don't see a bigWig profile uploaded in the attached pdf - to me it seems as if you uploaded a BAM file (the read blocks connected by horizontal lines which does indicate that you have a paired end run).

Can you confirm that you're uploading the output file generated by bamCoverage?

Best,

Friederike

--
You received this message because you are subscribed to the Google Groups "deepTools" group.
To unsubscribe from this group and stop receiving emails from it, send an email to deeptools+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[peter.mc...@gmail.com]

Hi Friederike,

Yes this is the image that was generated with BamCompare. 

Even though it is categorised as a bigwig in the output and I get the link to the UCSC browser, this is what I see.

I can send you the BAM file in question if you'd like?

Kind Regards,

Peter

[peter.mc...@gmail.com]

Also Friederike,

When I set the output to bedgraph I get this;

1	2	3	4
1	0	9950	0.00
1	9950	10250	0.27
1	10250	10500	0.00
1	10500	10800	2.46
1	10800	10850	4.38

Again I get a link to USCS but get an error message, I think since there is no 'chr' prefix for the chromosomes. 

Thanks

Peter

[Devon Ryan]

Hi Peter,

You're visualizing a BAM file, not a bigWig file. Yes, if you used a reference with Ensembl chromosome names at some point then UCSC will likely have problems. IGV handles different chromosome names better than UCSC, so use that instead.

Devon

--
Devon Ryan, Ph.D.
Email: dpr...@dpryan.com
Data Manager/Bioinformatician
Max Planck Institute of Immunobiology and Epigenetics
Stübeweg 51

79108 Freiburg

Germany

--

[peter.mc...@gmail.com]

Hi Devon, 

Ahhh yes! Seems that my bigwig track was set to 'hide' on the browser and hence the BAM file (which I loaded previously) was the only one being shown!

That said, the bigwig shows not track data and is likely due to the BAM file being aligned to Ensembl ref genome, something that I was not aware of!

Thanks tremendously for your help!

Kind Regards,

Peter