[ssvictor]

colin, thanks that worked .......

[colindaven]

Matt,
I tried to run the Prostate cancer data set explained in the tutorial following the same process using the same tools mentioned. I get the error below when running bowtie


Error: reads file does not look like a FASTQ file
Command: bowtie -v 3 --best --sam /usr/local/bowtie/indexes/hg19 s1.fa s1_test.sam

Any help would be great, I am trying to setup a NGS workflow like the one mentioned in the paper

vic

It looks like bowtie is expecting fastQ format and your reads are in fastA format
Try adding -f
bowtie -v 3 --best --sam /usr/local/bowtie/indexes/hg19 -f s1.fa s1_test.sam

[ssvictor]

Matt,
I tried to run the Prostate cancer data set explained in the tutorial following the same process using the same tools mentioned. I get the error below when running bowtie


Error: reads file does not look like a FASTQ file
Command: bowtie -v 3 --best --sam /usr/local/bowtie/indexes/hg19 s1.fa s1_test.sam

Any help would be great, I am trying to setup a NGS workflow like the one mentioned in the paper

vic

[zhacker]

Excellent tutorial. Helped a great deal in connecting the many dots that I had . Thank you very much!

[milesgr]

I had a problem when running this workflow and was wondering if someone could help me solve this problem. It appears as if the chromosome lengths for chromosomes 14 and 10 in the yeast genome are off by a single base between the two reference sequences used when trying to generating the overlaps (read counting). Can anyone assist me with the issue below?

> counts=countOverlaps(tx_by_gene,reads)
Error in queryHits(findOverlaps(query, subject, maxgap = maxgap, minoverlap = minoverlap, :
error in evaluating the argument 'x' in selecting a method for function 'queryHits': Error in mergeNamedAtomicVectors(seqlengths(x), seqlengths(y), what = c("sequence", :
sequences chrXIV, chrX have incompatible seqlengths:
- in 'x': 784333, 745742
- in 'y': 784334, 745741

All help is greatly appreciate. Thanks.

[waseem]

I ran this commond
> txdb=makeTranscriptDbFromUCSC(genome='G.max', tablename='ensGene')
Output was;
Download the ensGene table ... OK
Download the ensGtp table ... OK
Extract the 'transcripts' data frame ... OK
Extract the 'splicings' data frame ... OK

Every thing was OK till this step;

Download and preprocess the 'chrominfo' data frame ... Error in download.file(url, destfile, quiet = TRUE) :
cannot open URL 'http://hgdownload.cse.ucsc.edu/goldenPath/G.max/database/chromInfo.txt.gz'
In addition: There were 50 or more warnings (use warnings() to see the first 50)

I don't know how to handle that.

[Balat]

Hi,
Can you download gff file from Phytozome for soybean? If so, you can use "Bedtool"s "CoverageBed" to extract the read counts mapping to the transcripts which you may use for DE testing in "edgeR".

[waseem]

Hi Flyyuan: I am having the same concern, Matt is using Human transcript from UCSC, I want to do it for Soybean from Phytozome, I was wondering how you figured it out?

[waseem]

Thanks Matt for this nice guide, now, I am tring to analysis some soybean rna-seq data following this article. However, I am very new to this work, could anybody give me some suggestions to solve following problems:

1. I try to use makeTranscriptDbFromBiomart to get the information of soybean in phytozome database, but it seems there many organisms in phytozome database, how can I select the G.max which I need?

2.bowtie software map the RNA-seq tag to reference gene, what is the criterion for match or does not match.

thanks in advance!

Hi Flyyuan: I am having the same concern, Matt is using Human transcript from UCSC, I want to do it for Soybean from Phytozome, I was wondering how you figured it out?

[lewewoo]

case practice help

This summary is so awesome!!! Thanks so much!!!!!!!!!!
I am wondering whether we can get RPKM starting from the reads from here? Can the annotation file here give the length of gene used here? Thanks!

[tarmac]

Thanks for your tutorial

[RNAer]

Thanks, Alicia.In your paper, it's said in Methods section "Their analysis utilizes an offset to account for the library size and a likelihood ratio (LR) statistic to test for differences in expression between libraries ... In order to use TMM normalization, we augment the original offset with the estimated normalization factor". Do you mean this?

But I guess that augmenting with the original offset with the scaling factor would produce a non-integer number, right? Is it rounded to an integer? Will it cause a problem especially for the genes with few reads.

Hi RNAer,
The scaling factor normalization preserves the count data because in the statistical tests for DE the data is not actually multiplied by the scaling factor. In edgeR (where TMM is implemented) the scaling factor is used as an "offset" in the negative binomial model and the original count data is entered into the model. In this way we can preserve the count data but include the appropriate normalization between samples. So we never actually multiply the counts by the scaling factor. Hope this helps but it may become clearer when you implement the whole edgeR testing procedure.

[A Oshlack]

Hi RNAer,
The scaling factor normalization preserves the count data because in the statistical tests for DE the data is not actually multiplied by the scaling factor. In edgeR (where TMM is implemented) the scaling factor is used as an "offset" in the negative binomial model and the original count data is entered into the model. In this way we can preserve the count data but include the appropriate normalization between samples. So we never actually multiply the counts by the scaling factor. Hope this helps but it may become clearer when you implement the whole edgeR testing procedure.

[RNAer]

Hi Matt, it's a great introduction. May I ask why "the scaling factor normalization method ... preserves the count nature of the data"? I read the Robinson's paper but my understanding is that it still may produce non-integer numbers after scaling. Could you elaborate on this a little bit? Thanks

[ge_SF]

Great! I am glad this worked for you.

Actually, thank you for helping to troubleshoot my protocol. I will update it at least to remove the typos, and hopefully make it a little more clear.

Happy R adventures...