Menu
▾
▴
useq-users — General forum for useq users
You can subscribe to this list here.
| 2010 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
(4) |
Jun
(2) |
Jul
(3) |
Aug
(3) |
Sep
(5) |
Oct
(2) |
Nov
(4) |
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2011 |
Jan
(12) |
Feb
|
Mar
(5) |
Apr
(6) |
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
(15) |
Nov
(3) |
Dec
|
| 2012 |
Jan
|
Feb
(7) |
Mar
(3) |
Apr
(17) |
May
(5) |
Jun
|
Jul
(5) |
Aug
(1) |
Sep
(2) |
Oct
(3) |
Nov
(2) |
Dec
(1) |
| 2013 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(4) |
Jun
|
Jul
(1) |
Aug
|
Sep
(2) |
Oct
(2) |
Nov
(2) |
Dec
(2) |
| 2014 |
Jan
|
Feb
(2) |
Mar
(9) |
Apr
(2) |
May
|
Jun
(2) |
Jul
(1) |
Aug
(1) |
Sep
|
Oct
|
Nov
(1) |
Dec
(1) |
| 2015 |
Jan
|
Feb
|
Mar
(4) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2017 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: David N. <dav...@gm...> - 2012-05-24 18:24:57
|
Hello Noboru, I'd try setting the peak shift to 0 and the window size to 200 for RNASeq data. I suspect something odd is occurring when the window size is smaller than the peak shift. With RNASeq data it doesn't make sense to shift the location of the read with a peak shift. This is really only applicable to chIP-Seq data. -cheers, D On 5/24/12 12:14 PM, "Noboru Jo Sakabe" <ns...@uc...> wrote: > Hi David, I'm using ScanSeqs to find peaks in RNA-seq data using >peaks shift = 100 and window size = 50 and I noticed that a considerable >number of the peaks found are very short (<20 bp) and have 0 read. >ScanSeqs reports BW_Sum BW_Sum+ BW_SumT- such as 2.0 0 2.0, but when I >overlap the peak with my reads, I find none. > > Do you know what I could be doing wrong? > > >java -Xmx7500M -jar mypath/USeq_7.6.9/Apps/ScanSeqs -t all_Point/ -s >results -p 100 -w 50 > >java -Xmx6000M -jar >~/shared/programs/chip/USeq_7.6.9/Apps/EnrichedRegionMaker -f >results/windowData50bp.swi -i 0 -s 0 > > I used -i 0 and -s 0 because I couldn't find information about the >index number for BW_Sum and I actually wanted all the peaks so that I >could filter myself later. > > If you want to have a look at my .bed and .xls files, I put them at >http://mnlab.uchicago.edu/download/ > > > The last peak in the .xls file is only 19bp long and doesn't >overlap any read. > > I can postprocess the peaks, and filter by minimum number of reads, >but I'm curious whether I'm doing something wrong. > > Thanks! >-------------------------------------------------------------------------- >---- >Live Security Virtual Conference >Exclusive live event will cover all the ways today's security and >threat landscape has changed and how IT managers can respond. Discussions >will include endpoint security, mobile security and the latest in malware >threats. >http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/_________________ >______________________________ >Useq-users mailing list >Use...@li... >https://lists.sourceforge.net/lists/listinfo/useq-users |
|
From: Noboru Jo S. <ns...@uc...> - 2012-05-24 18:14:19
|
Hi David, I'm using ScanSeqs to find peaks in RNA-seq data using
peaks shift = 100 and window size = 50 and I noticed that a considerable
number of the peaks found are very short (<20 bp) and have 0 read.
ScanSeqs reports BW_Sum BW_Sum+ BW_SumT- such as 2.0 0 2.0, but when I
overlap the peak with my reads, I find none.
Do you know what I could be doing wrong?
java -Xmx7500M -jar mypath/USeq_7.6.9/Apps/ScanSeqs -t all_Point/ -s
results -p 100 -w 50
java -Xmx6000M -jar
~/shared/programs/chip/USeq_7.6.9/Apps/EnrichedRegionMaker -f
results/windowData50bp.swi -i 0 -s 0
I used -i 0 and -s 0 because I couldn't find information about the
index number for BW_Sum and I actually wanted all the peaks so that I
could filter myself later.
If you want to have a look at my .bed and .xls files, I put them at
http://mnlab.uchicago.edu/download/
The last peak in the .xls file is only 19bp long and doesn't
overlap any read.
I can postprocess the peaks, and filter by minimum number of reads,
but I'm curious whether I'm doing something wrong.
Thanks!
|
|
From: David N. <dav...@gm...> - 2012-05-03 15:02:46
|
Hmmm, Sam2USeq by default scales the data based on the total number of reads. Thus making relative read depth/coverage graphs. You can then reformat these to big wig using the USeq2UCSCBig app. Are you looking for something different? -cheers, D On 5/2/12 4:51 PM, "Jesse Rowley" <jes...@u2...> wrote: >We have noticed that visualization of comparisons in IGB can lead to >confusion when comparing samples that aren't normalized to total aligned >reads prior to making depth coverage tracks. The steps that we use to >get normalized Read Coverage tracks to visualize in IGB are SamParser, >SubSamplePointData, ReadCoverage. This is a carryover from when we were >using .novoalign format files and seems rather inefficient. Could this >option (either subsample to a user defined number, or just scale the >depth coverage tracks to a user defined %) be worked into the Sam2Useq? >thanks, > >Jesse Rowley >Post-Doctoral Research Fellow >Andrew Weyrich Lab >Eccles Institute of Human Genetics >University of Utah >-------------------------------------------------------------------------- >---- >Live Security Virtual Conference >Exclusive live event will cover all the ways today's security and >threat landscape has changed and how IT managers can respond. Discussions >will include endpoint security, mobile security and the latest in malware >threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >_______________________________________________ >Useq-users mailing list >Use...@li... >https://lists.sourceforge.net/lists/listinfo/useq-users |
|
From: Jesse R. <jes...@u2...> - 2012-05-02 23:26:33
|
We have noticed that visualization of comparisons in IGB can lead to confusion when comparing samples that aren't normalized to total aligned reads prior to making depth coverage tracks. The steps that we use to get normalized Read Coverage tracks to visualize in IGB are SamParser, SubSamplePointData, ReadCoverage. This is a carryover from when we were using .novoalign format files and seems rather inefficient. Could this option (either subsample to a user defined number, or just scale the depth coverage tracks to a user defined %) be worked into the Sam2Useq? thanks, Jesse Rowley Post-Doctoral Research Fellow Andrew Weyrich Lab Eccles Institute of Human Genetics University of Utah |
|
From: David N. <Dav...@hc...> - 2012-04-27 16:59:02
|
Oh no don't do that! Gene names are assumed to be unique to the entire dataset. I'd suggest prepending the chromosome to your gene name to avoid collisions. -cheers, D On 4/27/12 10:55 AM, "Oler, Andrew (NIH/NIAID) [C]" <and...@ni...> wrote: >Hi David, > >I noticed something about how MergeUCSCGeneTable treats transcripts with >the same gene name on different chromosomes. > >For example, if I have this UCSC-formatted table: >cat test.ucsc.real.table >OR4F16 NM_001005277 chr1 + 367658 368597 367658 368597 1 367658, 368597, >OR4F16 NM_001005277 chr1 - 621095 622034 621095 622034 1 621095, 622034, >OR4F16 NM_001005277 chr5 + 180794287 180795226 180794287 180795226 1 >180794287, 180795226, > >I run this command to get a merged table: > >java -jar ~/USeq/MergeUCSCGeneTable -u test.ucsc.real.table > >Arguments: -u test.ucsc.real.table > >3 transcripts collapsed to 1 genes. > >I get this output: > >cat test.real.table_Merged.ucsc >OR4F16 OR4F16 chr1 + 367658 180795226 367658 180795226 3 >367658,621095,180794287 368597,622034,180795226 > >I think it should make one merged transcript per chromosome (or else not >merge them at all since they are far apart and/or don't have any shared >exons, although not much harm is done by merging them within the same >chromosome). > >Thanks, > >Andrew > >Andrew Oler, Ph.D. >High-Throughput Sequencing Bioinformatics Specialist >Contractor Medical Science & Computing, Inc. >Computational Biology Section >Bioinformatics and Computational Biosciences Branch (BCBB) >OCICB/OSMO/OD/NIAID/NIH > >31 Center Drive, Room 3B62 >Bethesda, MD 20892 >Mobile: 240-507-3791 >Office: 301-402-5685 >http://bioinformatics.niaid.nih.gov<http://bioinformatics.niaid.nih.gov/> >(Within NIH) >http://exon.niaid.nih.gov<http://exon.niaid.nih.gov/> (Public) > >Disclaimer: The information in this e-mail and any of its attachments is >confidential and may contain sensitive information. It should not be used >by anyone who is not the original intended recipient. If you have >received this e-mail in error please inform the sender and delete it from >your mailbox or any other storage devices. National Institute of Allergy >and Infectious Diseases shall not accept liability for any statements >made that are sender's own and not expressly made on behalf of the NIAID >by one of its representatives. > |
|
From: Oler, A. (NIH/N. [C] <and...@ni...> - 2012-04-27 16:55:24
|
Hi David, I noticed something about how MergeUCSCGeneTable treats transcripts with the same gene name on different chromosomes. For example, if I have this UCSC-formatted table: cat test.ucsc.real.table OR4F16 NM_001005277 chr1 + 367658 368597 367658 368597 1 367658, 368597, OR4F16 NM_001005277 chr1 - 621095 622034 621095 622034 1 621095, 622034, OR4F16 NM_001005277 chr5 + 180794287 180795226 180794287 180795226 1 180794287, 180795226, I run this command to get a merged table: java -jar ~/USeq/MergeUCSCGeneTable -u test.ucsc.real.table Arguments: -u test.ucsc.real.table 3 transcripts collapsed to 1 genes. I get this output: cat test.real.table_Merged.ucsc OR4F16 OR4F16 chr1 + 367658 180795226 367658 180795226 3 367658,621095,180794287 368597,622034,180795226 I think it should make one merged transcript per chromosome (or else not merge them at all since they are far apart and/or don't have any shared exons, although not much harm is done by merging them within the same chromosome). Thanks, Andrew Andrew Oler, Ph.D. High-Throughput Sequencing Bioinformatics Specialist Contractor – Medical Science & Computing, Inc. Computational Biology Section Bioinformatics and Computational Biosciences Branch (BCBB) OCICB/OSMO/OD/NIAID/NIH 31 Center Drive, Room 3B62 Bethesda, MD 20892 Mobile: 240-507-3791 Office: 301-402-5685 http://bioinformatics.niaid.nih.gov<http://bioinformatics.niaid.nih.gov/> (Within NIH) http://exon.niaid.nih.gov<http://exon.niaid.nih.gov/> (Public) Disclaimer: The information in this e-mail and any of its attachments is confidential and may contain sensitive information. It should not be used by anyone who is not the original intended recipient. If you have received this e-mail in error please inform the sender and delete it from your mailbox or any other storage devices. National Institute of Allergy and Infectious Diseases shall not accept liability for any statements made that are sender's own and not expressly made on behalf of the NIAID by one of its representatives. |
|
From: David N. <Dav...@hc...> - 2012-04-25 17:23:20
|
OK Folks, Give USeq_8.2.3 a try. This checks that each read actually touches down on the exon under interrogation and should allow folks to use TopHat alignments more accurately. USeq 8.2.3 also reworks the MultipleReplicaScanSeqs app enabling one to bypass DESeq's variance outlier filtering. There were also mods to the NovoalignBisulfiteParser allowing it to play nice with spliced RNASeq alignments. -cheers, David -- David Austin Nix, PhD Huntsman Cancer Institute Dept. OncSci University of Utah Bioinformatics Shared Resource HCI 3165 (801) 587-4611 dav...@hc... Skype: NextGenBio On 4/23/12 9:12 AM, "Oler, Andrew (NIH/NIAID) [C]" <and...@ni...> wrote: >Hi David, > >This is what I expected as the reason for what I was seeing. Thanks in >advance for making the changes. Can you please let me know when the new >version is available? > >Thanks, > >Andrew > >Andrew Oler, Ph.D. >High-Throughput Sequencing Bioinformatics Specialist >Contractor Medical Science & Computing, Inc. >Computational Biology Section >Bioinformatics and Computational Biosciences Branch (BCBB) >OCICB/OSMO/OD/NIAID/NIH > >31 Center Drive, Room 3B62 >Bethesda, MD 20892 >Mobile: 240-507-3791 >Office: 301-402-5685 >http://bioinformatics.niaid.nih.gov<http://bioinformatics.niaid.nih.gov/> >(Within NIH) >http://exon.niaid.nih.gov<http://exon.niaid.nih.gov/> (Public) > >Disclaimer: The information in this e-mail and any of its attachments is >confidential and may contain sensitive information. It should not be used >by anyone who is not the original intended recipient. If you have >received this e-mail in error please inform the sender and delete it from >your mailbox or any other storage devices. National Institute of Allergy >and Infectious Diseases shall not accept liability for any statements >made that are sender's own and not expressly made on behalf of the NIAID >by one of its representatives. > > >From: David Nix <Dav...@hc...<mailto:Dav...@hc...>> >To: "Oler, Andrew (NIH/NIAID) [C]" ><and...@ni...<mailto:and...@ni...>> >Cc: >"use...@li...<mailto:use...@li...> >" ><use...@li...<mailto:use...@li...> >> >Subject: Re: ORSS not counting reads properly? > >Hello Andrew, > >OK, I found out the issue. I'm calling Picard's SAMRecordIterator i = >reader.queryOverlapping(chromosome, start, stop); method to retrieve all >alignments that overlap each exon. I then hash the names of the hits to >reduce this to the number of fragments found to hit the entire gene. > >For our standard Extended Junction Analysis with know splices and >annotation derived theoretical splices this works well >(http://useq.sourceforge.net/usageRNASeq.html) since alignments will share >sequence with at least with one of the genes exons. (There are very few >to no multi gene spanners with this approach, see below.) > >The problem is that you're using tophat to call splice matches and that >package is generating a lot of splices that have huge spans that overlap >all the gene's exons in genomic space but share no sequence. > >For example with Cav3, there are 572 such spanners, where the read is >split in half with 300k+ bp between them. These reads span multiple genes >and are counted as hits to each. Here's a couple of the spanners: > >HWI-ST183_0264:7:2208:7929:127398#0 0 chr6 112343683 255 28M309966N16M * 0 >0 GGACGTTCGGATCTTCTTCTTTTTGTGGCTGGGGGGGGCGGGTT >DFADFA;FHGAFGIICGG@@CFHGGCGG >FFFHBBA6@####### NH:i:1 NM:i:3 XS:A:- >HWI-ST183_0264:7:1105:15979:27960#0 0 chr6 112343684 255 27M309966N17M * 0 >0 GGCGTTCGGATCTTCTTCTTTTTGTGGCTGGGGGGGGGGTGTTC >FFHHHHHJJFHGHIHIJIJJJJJFBGHI >II6D<A6@######## NH:i:1 NM:i:3 XS:A:- > >HWI-ST183_0264:7:2205:3254:80300#0 0 chr6 112343686 255 25M309966N19M * 0 >0 >CGTTCGGATCTTCTTCTTTTTGTGGCTGGGGGGGGGGGTTTGTC FFHHHGGGIIJJJJIIJJJJJJHGIIJJI >III@B@######### NH:i:1 NM:i:3 XS:A:- >HWI-ST183_0264:7:1101:15952:159627#0 0 chr6 112343687 255 24M309966N20M * >0 >0 GTTCGGATCTTCTTCTTTTTGTGGCTGGGGGGGGGGGTTTCTCC FFHHHHFHHHIHIIIJJJJJJIJIIIJ >CB?7B########### NH:i:1 NM:i:3 XS:A:- > > >One fix here is to put in a requirement that each alignment actually share >sequence with the exons in a gene. Should be a pretty simple change. > >Thanks for bringing this to my attention! > >Note, for those looking for hit counts for every gene, set the -e 1. >Currently this defaults to 20 and only genes with this number of total >hits will be scored. I'll change this too in the next release. > >-cheers, D > > > >On 4/19/12 10:12 AM, "Oler, Andrew (NIH/NIAID) [C]" ><and...@ni...<mailto:and...@ni...>> >wrote: > >Hi David, > >I have two questions about ORSS. I'm using ORSS in USeq 8.2.0. I was >checking on a few genes (randomly chosen) that had no read counts and >noticed that there are some reads for those exons of those genes. Is >there a threshold number of reads that must be passed before the counts >are reported? (e.g., 5 in at least one dataset?) Is there a way to get >ORSS to report all of the read counts regardless of threshold (and only >skip the differential testing if below a threshold)? (e.g., Dnajb7, >Apol6, Dnahc5). > >What I'm more concerned about is a few genes that I noticed with large >differences between replicates. ORSS reports high counts, but when I >look at the raw reads, there is actually no expression for these genes at >all. See the screenshots for Cav3 and Oxtr. In the attached >spreadsheet, you can see that the read counts for the genes are 572 and >574, respectively for T1 (aka KO1 bam file in IGB). But there are no >reads for these exons in the KO1 bam file. I repeated with just a single >replicate and I got the same result (KO1 as treatment and WT1 as >control). If you look at the wide shot of Cav3, you see that there are >some spliced reads that flank these genes. I think these are being >counted, even though their aligned bases are not overlapping any exons; >there are about 500-600 reads that are hidden that probably have the same >profile, which is probably why the counts are ~572/4. I also just tried >this with USeq 8.2.2 and it gives the same result. > >Thanks, > >Andrew > >Andrew Oler, Ph.D. >High-Throughput Sequencing Bioinformatics Specialist >Contractor Medical Science & Computing, Inc. >Computational Biology Section >Bioinformatics and Computational Biosciences Branch (BCBB) >OCICB/OSMO/OD/NIAID/NIH > >31 Center Drive, Room 3B62 >Bethesda, MD 20892 >Mobile: 240-507-3791 >Office: 301-402-5685 >http://bioinformatics.niaid.nih.gov<http://bioinformatics.niaid.nih.gov/> >(Within NIH) >http://exon.niaid.nih.gov<http://exon.niaid.nih.gov/> (Public) > >Disclaimer: The information in this e-mail and any of its attachments is >confidential and may contain sensitive information. It should not be used >by anyone who is not the original intended recipient. If you have >received this e-mail in error please inform the sender and delete it from >your mailbox or any other storage devices. National Institute of Allergy >and Infectious Diseases shall not accept liability for any statements >made that are sender's own and not expressly made on behalf of the NIAID >by one of its representatives. > > > |
|
From: Oler, A. (NIH/N. [C] <and...@ni...> - 2012-04-23 15:15:25
|
Hi David, This is what I expected as the reason for what I was seeing. Thanks in advance for making the changes. Can you please let me know when the new version is available? Thanks, Andrew Andrew Oler, Ph.D. High-Throughput Sequencing Bioinformatics Specialist Contractor – Medical Science & Computing, Inc. Computational Biology Section Bioinformatics and Computational Biosciences Branch (BCBB) OCICB/OSMO/OD/NIAID/NIH 31 Center Drive, Room 3B62 Bethesda, MD 20892 Mobile: 240-507-3791 Office: 301-402-5685 http://bioinformatics.niaid.nih.gov<http://bioinformatics.niaid.nih.gov/> (Within NIH) http://exon.niaid.nih.gov<http://exon.niaid.nih.gov/> (Public) Disclaimer: The information in this e-mail and any of its attachments is confidential and may contain sensitive information. It should not be used by anyone who is not the original intended recipient. If you have received this e-mail in error please inform the sender and delete it from your mailbox or any other storage devices. National Institute of Allergy and Infectious Diseases shall not accept liability for any statements made that are sender's own and not expressly made on behalf of the NIAID by one of its representatives. From: David Nix <Dav...@hc...<mailto:Dav...@hc...>> To: "Oler, Andrew (NIH/NIAID) [C]" <and...@ni...<mailto:and...@ni...>> Cc: "use...@li...<mailto:use...@li...>" <use...@li...<mailto:use...@li...>> Subject: Re: ORSS not counting reads properly? Hello Andrew, OK, I found out the issue. I'm calling Picard's SAMRecordIterator i = reader.queryOverlapping(chromosome, start, stop); method to retrieve all alignments that overlap each exon. I then hash the names of the hits to reduce this to the number of fragments found to hit the entire gene. For our standard Extended Junction Analysis with know splices and annotation derived theoretical splices this works well (http://useq.sourceforge.net/usageRNASeq.html) since alignments will share sequence with at least with one of the genes exons. (There are very few to no multi gene spanners with this approach, see below.) The problem is that you're using tophat to call splice matches and that package is generating a lot of splices that have huge spans that overlap all the gene's exons in genomic space but share no sequence. For example with Cav3, there are 572 such spanners, where the read is split in half with 300k+ bp between them. These reads span multiple genes and are counted as hits to each. Here's a couple of the spanners: HWI-ST183_0264:7:2208:7929:127398#0 0 chr6 112343683 255 28M309966N16M * 0 0 GGACGTTCGGATCTTCTTCTTTTTGTGGCTGGGGGGGGCGGGTT DFADFA;FHGAFGIICGG@@CFHGGCGG FFFHBBA6@####### NH:i:1 NM:i:3 XS:A:- HWI-ST183_0264:7:1105:15979:27960#0 0 chr6 112343684 255 27M309966N17M * 0 0 GGCGTTCGGATCTTCTTCTTTTTGTGGCTGGGGGGGGGGTGTTC FFHHHHHJJFHGHIHIJIJJJJJFBGHI II6D<A6@######## NH:i:1 NM:i:3 XS:A:- HWI-ST183_0264:7:2205:3254:80300#0 0 chr6 112343686 255 25M309966N19M * 0 0 CGTTCGGATCTTCTTCTTTTTGTGGCTGGGGGGGGGGGTTTGTC FFHHHGGGIIJJJJIIJJJJJJHGIIJJI III@B@######### NH:i:1 NM:i:3 XS:A:- HWI-ST183_0264:7:1101:15952:159627#0 0 chr6 112343687 255 24M309966N20M * 0 0 GTTCGGATCTTCTTCTTTTTGTGGCTGGGGGGGGGGGTTTCTCC FFHHHHFHHHIHIIIJJJJJJIJIIIJ CB?7B########### NH:i:1 NM:i:3 XS:A:- One fix here is to put in a requirement that each alignment actually share sequence with the exons in a gene. Should be a pretty simple change. Thanks for bringing this to my attention! Note, for those looking for hit counts for every gene, set the -e 1. Currently this defaults to 20 and only genes with this number of total hits will be scored. I'll change this too in the next release. -cheers, D On 4/19/12 10:12 AM, "Oler, Andrew (NIH/NIAID) [C]" <and...@ni...<mailto:and...@ni...>> wrote: Hi David, I have two questions about ORSS. I'm using ORSS in USeq 8.2.0. I was checking on a few genes (randomly chosen) that had no read counts and noticed that there are some reads for those exons of those genes. Is there a threshold number of reads that must be passed before the counts are reported? (e.g., 5 in at least one dataset?) Is there a way to get ORSS to report all of the read counts regardless of threshold (and only skip the differential testing if below a threshold)? (e.g., Dnajb7, Apol6, Dnahc5). What I'm more concerned about is a few genes that I noticed with large differences between replicates. ORSS reports high counts, but when I look at the raw reads, there is actually no expression for these genes at all. See the screenshots for Cav3 and Oxtr. In the attached spreadsheet, you can see that the read counts for the genes are 572 and 574, respectively for T1 (aka KO1 bam file in IGB). But there are no reads for these exons in the KO1 bam file. I repeated with just a single replicate and I got the same result (KO1 as treatment and WT1 as control). If you look at the wide shot of Cav3, you see that there are some spliced reads that flank these genes. I think these are being counted, even though their aligned bases are not overlapping any exons; there are about 500-600 reads that are hidden that probably have the same profile, which is probably why the counts are ~572/4. I also just tried this with USeq 8.2.2 and it gives the same result. Thanks, Andrew Andrew Oler, Ph.D. High-Throughput Sequencing Bioinformatics Specialist Contractor Medical Science & Computing, Inc. Computational Biology Section Bioinformatics and Computational Biosciences Branch (BCBB) OCICB/OSMO/OD/NIAID/NIH 31 Center Drive, Room 3B62 Bethesda, MD 20892 Mobile: 240-507-3791 Office: 301-402-5685 http://bioinformatics.niaid.nih.gov<http://bioinformatics.niaid.nih.gov/> (Within NIH) http://exon.niaid.nih.gov<http://exon.niaid.nih.gov/> (Public) Disclaimer: The information in this e-mail and any of its attachments is confidential and may contain sensitive information. It should not be used by anyone who is not the original intended recipient. If you have received this e-mail in error please inform the sender and delete it from your mailbox or any other storage devices. National Institute of Allergy and Infectious Diseases shall not accept liability for any statements made that are sender's own and not expressly made on behalf of the NIAID by one of its representatives. |
|
From: David N. <Dav...@hc...> - 2012-04-20 19:02:33
|
Hello Andrew, OK, I found out the issue. I'm calling Picard's SAMRecordIterator i = reader.queryOverlapping(chromosome, start, stop); method to retrieve all alignments that overlap each exon. I then hash the names of the hits to reduce this to the number of fragments found to hit the entire gene. For our standard Extended Junction Analysis with know splices and annotation derived theoretical splices this works well (http://useq.sourceforge.net/usageRNASeq.html) since alignments will share sequence with at least with one of the genes exons. (There are very few to no multi gene spanners with this approach, see below.) The problem is that you're using tophat to call splice matches and that package is generating a lot of splices that have huge spans that overlap all the gene's exons in genomic space but share no sequence. For example with Cav3, there are 572 such spanners, where the read is split in half with 300k+ bp between them. These reads span multiple genes and are counted as hits to each. Here's a couple of the spanners: HWI-ST183_0264:7:2208:7929:127398#0 0 chr6 112343683 255 28M309966N16M * 0 0 GGACGTTCGGATCTTCTTCTTTTTGTGGCTGGGGGGGGCGGGTT DFADFA;FHGAFGIICGG@@CFHGGCGG FFFHBBA6@####### NH:i:1 NM:i:3 XS:A:- HWI-ST183_0264:7:1105:15979:27960#0 0 chr6 112343684 255 27M309966N17M * 0 0 GGCGTTCGGATCTTCTTCTTTTTGTGGCTGGGGGGGGGGTGTTC FFHHHHHJJFHGHIHIJIJJJJJFBGHI II6D<A6@######## NH:i:1 NM:i:3 XS:A:- HWI-ST183_0264:7:2205:3254:80300#0 0 chr6 112343686 255 25M309966N19M * 0 0 CGTTCGGATCTTCTTCTTTTTGTGGCTGGGGGGGGGGGTTTGTC FFHHHGGGIIJJJJIIJJJJJJHGIIJJI III@B@######### NH:i:1 NM:i:3 XS:A:- HWI-ST183_0264:7:1101:15952:159627#0 0 chr6 112343687 255 24M309966N20M * 0 0 GTTCGGATCTTCTTCTTTTTGTGGCTGGGGGGGGGGGTTTCTCC FFHHHHFHHHIHIIIJJJJJJIJIIIJ >CB?7B########### NH:i:1 NM:i:3 XS:A:- One fix here is to put in a requirement that each alignment actually share sequence with the exons in a gene. Should be a pretty simple change. Thanks for bringing this to my attention! Note, for those looking for hit counts for every gene, set the -e 1. Currently this defaults to 20 and only genes with this number of total hits will be scored. I'll change this too in the next release. -cheers, D On 4/19/12 10:12 AM, "Oler, Andrew (NIH/NIAID) [C]" <and...@ni...> wrote: >Hi David, > >I have two questions about ORSS. I'm using ORSS in USeq 8.2.0. I was >checking on a few genes (randomly chosen) that had no read counts and >noticed that there are some reads for those exons of those genes. Is >there a threshold number of reads that must be passed before the counts >are reported? (e.g., 5 in at least one dataset?) Is there a way to get >ORSS to report all of the read counts regardless of threshold (and only >skip the differential testing if below a threshold)? (e.g., Dnajb7, >Apol6, Dnahc5). > >What I'm more concerned about is a few genes that I noticed with large >differences between replicates. ORSS reports high counts, but when I >look at the raw reads, there is actually no expression for these genes at >all. See the screenshots for Cav3 and Oxtr. In the attached >spreadsheet, you can see that the read counts for the genes are 572 and >574, respectively for T1 (aka KO1 bam file in IGB). But there are no >reads for these exons in the KO1 bam file. I repeated with just a single >replicate and I got the same result (KO1 as treatment and WT1 as >control). If you look at the wide shot of Cav3, you see that there are >some spliced reads that flank these genes. I think these are being >counted, even though their aligned bases are not overlapping any exons; >there are about 500-600 reads that are hidden that probably have the same >profile, which is probably why the counts are ~572/4. I also just tried >this with USeq 8.2.2 and it gives the same result. > >Thanks, > >Andrew > >Andrew Oler, Ph.D. >High-Throughput Sequencing Bioinformatics Specialist >Contractor Medical Science & Computing, Inc. >Computational Biology Section >Bioinformatics and Computational Biosciences Branch (BCBB) >OCICB/OSMO/OD/NIAID/NIH > >31 Center Drive, Room 3B62 >Bethesda, MD 20892 >Mobile: 240-507-3791 >Office: 301-402-5685 >http://bioinformatics.niaid.nih.gov<http://bioinformatics.niaid.nih.gov/> >(Within NIH) >http://exon.niaid.nih.gov<http://exon.niaid.nih.gov/> (Public) > >Disclaimer: The information in this e-mail and any of its attachments is >confidential and may contain sensitive information. It should not be used >by anyone who is not the original intended recipient. If you have >received this e-mail in error please inform the sender and delete it from >your mailbox or any other storage devices. National Institute of Allergy >and Infectious Diseases shall not accept liability for any statements >made that are sender's own and not expressly made on behalf of the NIAID >by one of its representatives. > |
|
From: David N. <Dav...@hc...> - 2012-04-19 16:54:13
|
Let me take a look, there are several filters that are applied to exclude bad alignments before being counted by ODRSS. Thus the alignments counted will likely be a subset of the input file. On 4/19/12 10:12 AM, "Oler, Andrew (NIH/NIAID) [C]" <and...@ni...> wrote: >Hi David, > >I have two questions about ORSS. I'm using ORSS in USeq 8.2.0. I was >checking on a few genes (randomly chosen) that had no read counts and >noticed that there are some reads for those exons of those genes. Is >there a threshold number of reads that must be passed before the counts >are reported? (e.g., 5 in at least one dataset?) Is there a way to get >ORSS to report all of the read counts regardless of threshold (and only >skip the differential testing if below a threshold)? (e.g., Dnajb7, >Apol6, Dnahc5). > >What I'm more concerned about is a few genes that I noticed with large >differences between replicates. ORSS reports high counts, but when I >look at the raw reads, there is actually no expression for these genes at >all. See the screenshots for Cav3 and Oxtr. In the attached >spreadsheet, you can see that the read counts for the genes are 572 and >574, respectively for T1 (aka KO1 bam file in IGB). But there are no >reads for these exons in the KO1 bam file. I repeated with just a single >replicate and I got the same result (KO1 as treatment and WT1 as >control). If you look at the wide shot of Cav3, you see that there are >some spliced reads that flank these genes. I think these are being >counted, even though their aligned bases are not overlapping any exons; >there are about 500-600 reads that are hidden that probably have the same >profile, which is probably why the counts are ~572/4. I also just tried >this with USeq 8.2.2 and it gives the same result. > >Thanks, > >Andrew > >Andrew Oler, Ph.D. >High-Throughput Sequencing Bioinformatics Specialist >Contractor Medical Science & Computing, Inc. >Computational Biology Section >Bioinformatics and Computational Biosciences Branch (BCBB) >OCICB/OSMO/OD/NIAID/NIH > >31 Center Drive, Room 3B62 >Bethesda, MD 20892 >Mobile: 240-507-3791 >Office: 301-402-5685 >http://bioinformatics.niaid.nih.gov<http://bioinformatics.niaid.nih.gov/> >(Within NIH) >http://exon.niaid.nih.gov<http://exon.niaid.nih.gov/> (Public) > >Disclaimer: The information in this e-mail and any of its attachments is >confidential and may contain sensitive information. It should not be used >by anyone who is not the original intended recipient. If you have >received this e-mail in error please inform the sender and delete it from >your mailbox or any other storage devices. National Institute of Allergy >and Infectious Diseases shall not accept liability for any statements >made that are sender's own and not expressly made on behalf of the NIAID >by one of its representatives. > |
|
From: Oler, A. (NIH/N. [C] <and...@ni...> - 2012-04-19 16:13:51
|
Hi David, I have two questions about ORSS. I'm using ORSS in USeq 8.2.0. I was checking on a few genes (randomly chosen) that had no read counts and noticed that there are some reads for those exons of those genes. Is there a threshold number of reads that must be passed before the counts are reported? (e.g., 5 in at least one dataset?) Is there a way to get ORSS to report all of the read counts regardless of threshold (and only skip the differential testing if below a threshold)? (e.g., Dnajb7, Apol6, Dnahc5). What I'm more concerned about is a few genes that I noticed with large differences between replicates. ORSS reports high counts, but when I look at the raw reads, there is actually no expression for these genes at all. See the screenshots for Cav3 and Oxtr. In the attached spreadsheet, you can see that the read counts for the genes are 572 and 574, respectively for T1 (aka KO1 bam file in IGB). But there are no reads for these exons in the KO1 bam file. I repeated with just a single replicate and I got the same result (KO1 as treatment and WT1 as control). If you look at the wide shot of Cav3, you see that there are some spliced reads that flank these genes. I think these are being counted, even though their aligned bases are not overlapping any exons; there are about 500-600 reads that are hidden that probably have the same profile, which is probably why the counts are ~572/4. I also just tried this with USeq 8.2.2 and it gives the same result. Thanks, Andrew Andrew Oler, Ph.D. High-Throughput Sequencing Bioinformatics Specialist Contractor – Medical Science & Computing, Inc. Computational Biology Section Bioinformatics and Computational Biosciences Branch (BCBB) OCICB/OSMO/OD/NIAID/NIH 31 Center Drive, Room 3B62 Bethesda, MD 20892 Mobile: 240-507-3791 Office: 301-402-5685 http://bioinformatics.niaid.nih.gov<http://bioinformatics.niaid.nih.gov/> (Within NIH) http://exon.niaid.nih.gov<http://exon.niaid.nih.gov/> (Public) Disclaimer: The information in this e-mail and any of its attachments is confidential and may contain sensitive information. It should not be used by anyone who is not the original intended recipient. If you have received this e-mail in error please inform the sender and delete it from your mailbox or any other storage devices. National Institute of Allergy and Infectious Diseases shall not accept liability for any statements made that are sender's own and not expressly made on behalf of the NIAID by one of its representatives. |
|
From: David N. <dav...@gm...> - 2012-04-12 14:16:57
|
Yes, if you save it as a sam it bypasses Picard's SortSam and just writes
out the alignments. -cheers, D
From: Jon Manning <Jon...@ed...>
Date: Thu, 12 Apr 2012 15:15:10 +0100
To: David Nix <dav...@gm...>
Cc: <use...@li...>
Subject: Re: [Useq-users] Error with USeq SamTranscriptomeParser while
processing Novoalign RNA-seq outputs
Thanks for the pointers- don't worrry, I will be re-running the alignment.
However, specifying '-s output.sam' did at least make things run without
error- Zayed indicated that the BAM conversion was the problem, due to the
'absence of a valid sequence dictionary'.
But things are much clearer now than they were this morning- thank you.
Jon
On 12/04/2012 14:49, David Nix wrote:
>
> Hmm. That error you are seeing is from Picard. STP calls SortSam internally.
> Looks like it is trying to write a short that is too big, possibly due to the
> huge chromosome name? Or too many chromosome names since these have not been
> converted to genomic space.
>
>
>
>
> Use of the -u option won't change much of anything except redirect the failed
> alignment to a file.
>
>
>
>
> The big problem is you're going to have transcript alignments intermingled
> with your genomic alignments and won't be able to map the former to the
> latter.
>
>
>
>
> I don't think you can use your partially converted sam file. Need to rebuild
> the novoindex and realign.
>
>
>
>
> -cheers, D
>
>
>
>
> From: Jon Manning <Jon...@ed...>
> Date: Thu, 12 Apr 2012 14:43:11 +0100
> To: David Nix <dav...@gm...>
> Cc: <use...@li...>
> Subject: Re: [Useq-users] Error with USeq SamTranscriptomeParser while
> processing Novoalign RNA-seq outputs
>
>
>
>
>
>
> Okay, that's good to know- thanks.
>
> In the meantime I tried a fix suggested by Zayed at Novocraft, namely to not
> use '-u' and thereby to exclude unmapped reads. Both this and using USeq 8.2.2
> (I was on 8.2.1) changed the error to:
>
> Exception in thread "main" java.lang.IllegalArgumentException: Value (70699)
> to large to be written as ushort.
> at net.sf.samtools.util.BinaryCodec.writeUShort(BinaryCodec.java:324)
> at net.sf.samtools.BAMRecordCodec.encode(BAMRecordCodec.java:114)
> at net.sf.samtools.BAMRecordCodec.encode(BAMRecordCodec.java:37)
> at
> net.sf.samtools.util.SortingCollection.spillToDisk(SortingCollection.java:210)
> at net.sf.samtools.util.SortingCollection.add(SortingCollection.java:150)
> at
> net.sf.samtools.SAMFileWriterImpl.addAlignment(SAMFileWriterImpl.java:157)
> at net.sf.picard.sam.SortSam.doWork(SortSam.java:67)
> at
> net.sf.picard.cmdline.CommandLineProgram.instanceMain(CommandLineProgram.java:
> 175)
> at edu.utah.seq.data.sam.PicardSortSam.<init>(PicardSortSam.java:81)
> at
> edu.utah.seq.parsers.SamTranscriptomeParser.addHeaderAndSort(SamTranscriptomeP
> arser.java:482)
> at
> edu.utah.seq.parsers.SamTranscriptomeParser.doWork(SamTranscriptomeParser.java
> :101)
> at
> edu.utah.seq.parsers.SamTranscriptomeParser.<init>(SamTranscriptomeParser.java
> :55)
> at
> edu.utah.seq.parsers.SamTranscriptomeParser.main(SamTranscriptomeParser.java:4
> 95)
>
> I realise I'm working with a bad SAM file from your point of view, but do you
> think this error is part of the same thing, or something new?
>
> Jon
>
>
> On 12/04/2012 14:12, David Nix wrote:
>>
>> Yes that's incorrect. Don't add the xxxTranscripts.fasta. All of the splice
>> junctions are in the xxxSplices.fasta file. I'll cc Colin here to correct
>> this in the Novocraft docs. See also
>> http://useq.sourceforge.net/usageRNASeq.html
>>
>>
>>
>>
>> Not sure about the chr1 vs 1 . Off the top of my head I don't think there
>> should be a problem with USeq apps. But then again we haven't tested them.
>> Most of the genome browsers will probably complain unless you register a
>> synonyms table. Sounds like the ensembl browser wont though so maybe it
>> isn't an issue.
>>
>>
>>
>>
>> -cheers, D
>>
>>
>>
>>
>> From: Jon Manning <Jon...@ed...>
>> Date: Thu, 12 Apr 2012 14:04:45 +0100
>> To: David Nix <dav...@gm...>
>> Cc: <use...@li...>
>> Subject: Re: [Useq-users] Error with USeq SamTranscriptomeParser while
>> processing Novoalign RNA-seq outputs
>>
>>
>>
>>
>>
>>
>> Hi David,
>>
>> Thanks for the quick reply. Following the Novoalign folks' instructions the
>> transcripts were indeed added to the index. Excerpt from their docs:
>>
>> novoindex Transcriptome.nix geneMaskedGenome.fasta
>> refFlatRad45Num60kMin10Splices.fasta
>> refFlatRad45Num60kMin10Transcripts.fasta
>> Is that not the right thing to do? Should it just be the genome and the
>> splices?
>>
>> I'm working primarily with Ensembl data so I'd like to keep my chromosomes
>> 'sans chr' - unless of course the USeq apps require it?
>>
>> Thanks,
>>
>> Jon
>>
>>
>>
>> On 12/04/2012 12:45, David Nix wrote:
>>>
>>> Did you by chance add the transcripts to your genome index from the
>>> MakeTranscriptome App? These take the form of
>>> ENSDARG00000012493:ENSDART00000126849:chr20:705345-705376_708...
>>>
>>>
>>>
>>>
>>> That also could be the problem. -cheers, D
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Ahh, looks like you've joined your gene name using a : . Use an _ . The
>>> STP uses the : to split the splice junction chromosome name into it's
>>> component parts. A good junction should look like
>>>
>>>
>>>
>>>
>>> ENSDARG00000087418:chr20:6691-6707_9356-9386_9436-9463_9494-9513
>>>
>>>
>>>
>>>
>>> Rps3:ENSRNOT00000023935:1:156811472-156811541.... should be
>>> Rps3_ENSRNOT00000023935:1:156811472-156811541......
>>>
>>>
>>>
>>>
>>> As such STP isn't able to recognize the alignment as needing conversion to
>>> genomic coordinates.
>>>
>>>
>>>
>>>
>>> Also, it would be a good idea to rename your chromosomes to the standard
>>> UCSC nomenclature: chr1, chr2, chr3.... I've no idea why NCBI and others
>>> switched a couple years back.
>>>
>>>
>>>
>>>
>>> Yes, all splice junction header lines are stripped from the SAM header, they
>>> aren't needed after genomic coordinate conversion.
>>>
>>>
>>>
>>>
>>> -cheers, D
>>>
>>>
>>>
>>>
>>> From: Jon Manning <Jon...@ed...>
>>> Date: Thu, 12 Apr 2012 10:18:32 +0100
>>> To: <use...@li...>
>>> Subject: [Useq-users] Error with USeq SamTranscriptomeParser while
>>> processing Novoalign RNA-seq outputs
>>>
>>>
>>>
>>>
>>>
>>>
>>> Hello,
>>>
>>> I've been working through the Novoalign RNA-seq instructions
>>> <http://www.novocraft.com/wiki/tiki-index.php?page=RNASeq+analysis%3A+mRNA+a
>>> nd+the+Spliceosome&structure=Novocraft+Technologies&page_ref_id=35> , and am
>>> stuck at the last stage, where reads are converted back to genomic
>>> coordinates with USeq SamTranscriptomeParser, and I'm hoping you may be able
>>> to help.
>>>
>>> When it gets to the 'Adding SAM header, sorting, and writing bam output
>>> with Picard's SortSam...' stage I'm getting errors like:
>>>
>>> Exception in thread "main" net.sf.samtools.SAMFormatException: Error
>>> parsing text SAM file. RNAME
>>> 'Rps3:ENSRNOT00000023935:1:156811472-156811541_156811891-156812088_156812500
>>> -156812688_156814773-156814868_156815362-156815456_156815668-156815799_15681
>>> 6728-156816770' not found in any SQ record; Line 27
>>> Line: EBRI093151:81:FC:1:1:3202:1108 133
>>> Rps3:ENSRNOT00000023935:1:156811472-156811541_156811891-156812088_156812500-
>>> 156812688_156814773-156814868_156815362-156815456_156815668-156815799_156816
>>> 728-156816770 375 0 * = 375 0
>>> AANAAGTGGCCACAANNNNNNNNNGNGCCATNGCCCAGNNNNNNNCTCNACGCNACAAACNCTNAGGAGGGCTTGC
>>> AG
>>> B=#==A>ABCCBBAB#############################################################
>>> ## PG:Z:novoalign ZS:Z:QC
>>>
>>> I've checked, and these lines ARE present in the input SAM file (made by
>>> Novoalign), but not in the temporary SAM files I can see created by
>>> SamTranscriptomeParser, so I suspect they may be lost somehow.
>>>
>>> I'm not sure how to go about debugging this myself, so all pointers
>>> appreciated.
>>>
>>> Thanks,
>>>
>>> Jon Manning
>>>
>>>
>>>
>>> The University of Edinburgh is a charitable body, registered in Scotland,
>>> with registration number SC005336.
>>> ----------------------------------------------------------------------------
>>> -- For Developers, A Lot Can Happen In A Second. Boundary is the first to
>>> Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try
>>> it FREE!
>>> http://p.sf.net/sfu/Boundary-d2dvs2_________________________________________
>>> ______ Useq-users mailing list
>>> Use...@li...https://lists.sourceforge.net/lists/listinfo
>>> /useq-users
>>
>>
>> --
>> Dr Jonathan Manning
>> Bioinformatics Team
>> Centre for Cardiovascular Science
>> University of Edinburgh
>> Queens Medical Research Institute
>> 47 Little France Crescent
>> Edinburgh EH16 4TJ
>> United Kingdom
>> T: +44 131 242 6700
>> F: +44 131 242 6782
>> E: jma...@st...
>>
>>
>> The University of Edinburgh is a charitable body, registered in Scotland,
>> with registration number SC005336.
>
>
> --
> Dr Jonathan Manning
> Bioinformatics Team
> Centre for Cardiovascular Science
> University of Edinburgh
> Queens Medical Research Institute
> 47 Little France Crescent
> Edinburgh EH16 4TJ
> United Kingdom
> T: +44 131 242 6700
> F: +44 131 242 6782
> E: jma...@st...
>
>
> The University of Edinburgh is a charitable body, registered in Scotland,
> with registration number SC005336.
--
Dr Jonathan Manning
Bioinformatics Team
Centre for Cardiovascular Science
University of Edinburgh
Queens Medical Research Institute
47 Little France Crescent
Edinburgh EH16 4TJ
United Kingdom
T: +44 131 242 6700
F: +44 131 242 6782
E: jma...@st...
The University of Edinburgh is a charitable body, registered in Scotland,
with registration number SC005336.
|
|
From: Jon M. <Jon...@ed...> - 2012-04-12 14:15:30
|
The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. |
|
From: David N. <dav...@gm...> - 2012-04-12 13:49:52
|
Hmm. That error you are seeing is from Picard. STP calls SortSam
internally. Looks like it is trying to write a short that is too big,
possibly due to the huge chromosome name? Or too many chromosome names since
these have not been converted to genomic space.
Use of the -u option won't change much of anything except redirect the
failed alignment to a file.
The big problem is you're going to have transcript alignments intermingled
with your genomic alignments and won't be able to map the former to the
latter.
I don't think you can use your partially converted sam file. Need to
rebuild the novoindex and realign.
-cheers, D
From: Jon Manning <Jon...@ed...>
Date: Thu, 12 Apr 2012 14:43:11 +0100
To: David Nix <dav...@gm...>
Cc: <use...@li...>
Subject: Re: [Useq-users] Error with USeq SamTranscriptomeParser while
processing Novoalign RNA-seq outputs
Okay, that's good to know- thanks.
In the meantime I tried a fix suggested by Zayed at Novocraft, namely to
not use '-u' and thereby to exclude unmapped reads. Both this and using USeq
8.2.2 (I was on 8.2.1) changed the error to:
Exception in thread "main" java.lang.IllegalArgumentException: Value
(70699) to large to be written as ushort.
at net.sf.samtools.util.BinaryCodec.writeUShort(BinaryCodec.java:324)
at net.sf.samtools.BAMRecordCodec.encode(BAMRecordCodec.java:114)
at net.sf.samtools.BAMRecordCodec.encode(BAMRecordCodec.java:37)
at
net.sf.samtools.util.SortingCollection.spillToDisk(SortingCollection.java:21
0)
at
net.sf.samtools.util.SortingCollection.add(SortingCollection.java:150)
at
net.sf.samtools.SAMFileWriterImpl.addAlignment(SAMFileWriterImpl.java:157)
at net.sf.picard.sam.SortSam.doWork(SortSam.java:67)
at
net.sf.picard.cmdline.CommandLineProgram.instanceMain(CommandLineProgram.jav
a:175)
at edu.utah.seq.data.sam.PicardSortSam.<init>(PicardSortSam.java:81)
at
edu.utah.seq.parsers.SamTranscriptomeParser.addHeaderAndSort(SamTranscriptom
eParser.java:482)
at
edu.utah.seq.parsers.SamTranscriptomeParser.doWork(SamTranscriptomeParser.ja
va:101)
at
edu.utah.seq.parsers.SamTranscriptomeParser.<init>(SamTranscriptomeParser.ja
va:55)
at
edu.utah.seq.parsers.SamTranscriptomeParser.main(SamTranscriptomeParser.java
:495)
I realise I'm working with a bad SAM file from your point of view, but do
you think this error is part of the same thing, or something new?
Jon
On 12/04/2012 14:12, David Nix wrote:
>
> Yes that's incorrect. Don't add the xxxTranscripts.fasta. All of the splice
> junctions are in the xxxSplices.fasta file. I'll cc Colin here to correct
> this in the Novocraft docs. See also
> http://useq.sourceforge.net/usageRNASeq.html
>
>
>
>
> Not sure about the chr1 vs 1 . Off the top of my head I don't think there
> should be a problem with USeq apps. But then again we haven't tested them.
> Most of the genome browsers will probably complain unless you register a
> synonyms table. Sounds like the ensembl browser wont though so maybe it isn't
> an issue.
>
>
>
>
> -cheers, D
>
>
>
>
> From: Jon Manning <Jon...@ed...>
> Date: Thu, 12 Apr 2012 14:04:45 +0100
> To: David Nix <dav...@gm...>
> Cc: <use...@li...>
> Subject: Re: [Useq-users] Error with USeq SamTranscriptomeParser while
> processing Novoalign RNA-seq outputs
>
>
>
>
>
>
> Hi David,
>
> Thanks for the quick reply. Following the Novoalign folks' instructions the
> transcripts were indeed added to the index. Excerpt from their docs:
>
> novoindex Transcriptome.nix geneMaskedGenome.fasta
> refFlatRad45Num60kMin10Splices.fasta refFlatRad45Num60kMin10Transcripts.fasta
> Is that not the right thing to do? Should it just be the genome and the
> splices?
>
> I'm working primarily with Ensembl data so I'd like to keep my chromosomes
> 'sans chr' - unless of course the USeq apps require it?
>
> Thanks,
>
> Jon
>
>
>
> On 12/04/2012 12:45, David Nix wrote:
>>
>> Did you by chance add the transcripts to your genome index from the
>> MakeTranscriptome App? These take the form of
>> ENSDARG00000012493:ENSDART00000126849:chr20:705345-705376_708...
>>
>>
>>
>>
>> That also could be the problem. -cheers, D
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> Ahh, looks like you've joined your gene name using a : . Use an _ . The STP
>> uses the : to split the splice junction chromosome name into it's component
>> parts. A good junction should look like
>>
>>
>>
>>
>> ENSDARG00000087418:chr20:6691-6707_9356-9386_9436-9463_9494-9513
>>
>>
>>
>>
>> Rps3:ENSRNOT00000023935:1:156811472-156811541.... should be
>> Rps3_ENSRNOT00000023935:1:156811472-156811541......
>>
>>
>>
>>
>> As such STP isn't able to recognize the alignment as needing conversion to
>> genomic coordinates.
>>
>>
>>
>>
>> Also, it would be a good idea to rename your chromosomes to the standard UCSC
>> nomenclature: chr1, chr2, chr3.... I've no idea why NCBI and others switched
>> a couple years back.
>>
>>
>>
>>
>> Yes, all splice junction header lines are stripped from the SAM header, they
>> aren't needed after genomic coordinate conversion.
>>
>>
>>
>>
>> -cheers, D
>>
>>
>>
>>
>> From: Jon Manning <Jon...@ed...>
>> Date: Thu, 12 Apr 2012 10:18:32 +0100
>> To: <use...@li...>
>> Subject: [Useq-users] Error with USeq SamTranscriptomeParser while
>> processing Novoalign RNA-seq outputs
>>
>>
>>
>>
>>
>>
>> Hello,
>>
>> I've been working through the Novoalign RNA-seq instructions
>> <http://www.novocraft.com/wiki/tiki-index.php?page=RNASeq+analysis%3A+mRNA+an
>> d+the+Spliceosome&structure=Novocraft+Technologies&page_ref_id=35> , and am
>> stuck at the last stage, where reads are converted back to genomic
>> coordinates with USeq SamTranscriptomeParser, and I'm hoping you may be able
>> to help.
>>
>> When it gets to the 'Adding SAM header, sorting, and writing bam output with
>> Picard's SortSam...' stage I'm getting errors like:
>>
>> Exception in thread "main" net.sf.samtools.SAMFormatException: Error parsing
>> text SAM file. RNAME
>> 'Rps3:ENSRNOT00000023935:1:156811472-156811541_156811891-156812088_156812500-
>> 156812688_156814773-156814868_156815362-156815456_156815668-156815799_1568167
>> 28-156816770' not found in any SQ record; Line 27
>> Line: EBRI093151:81:FC:1:1:3202:1108 133
>> Rps3:ENSRNOT00000023935:1:156811472-156811541_156811891-156812088_156812500-1
>> 56812688_156814773-156814868_156815362-156815456_156815668-156815799_15681672
>> 8-156816770 375 0 * = 375 0
>> AANAAGTGGCCACAANNNNNNNNNGNGCCATNGCCCAGNNNNNNNCTCNACGCNACAAACNCTNAGGAGGGCTTGCA
>> G
>> B=#==A>ABCCBBAB##############################################################
>> # PG:Z:novoalign ZS:Z:QC
>>
>> I've checked, and these lines ARE present in the input SAM file (made by
>> Novoalign), but not in the temporary SAM files I can see created by
>> SamTranscriptomeParser, so I suspect they may be lost somehow.
>>
>> I'm not sure how to go about debugging this myself, so all pointers
>> appreciated.
>>
>> Thanks,
>>
>> Jon Manning
>>
>>
>>
>> The University of Edinburgh is a charitable body, registered in Scotland,
>> with registration number SC005336.
>> -----------------------------------------------------------------------------
>> - For Developers, A Lot Can Happen In A Second. Boundary is the first to
>> Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try
>> it FREE!
>> http://p.sf.net/sfu/Boundary-d2dvs2__________________________________________
>> _____ Useq-users mailing list
>> Use...@li...https://lists.sourceforge.net/lists/listinfo/
>> useq-users
>
>
> --
> Dr Jonathan Manning
> Bioinformatics Team
> Centre for Cardiovascular Science
> University of Edinburgh
> Queens Medical Research Institute
> 47 Little France Crescent
> Edinburgh EH16 4TJ
> United Kingdom
> T: +44 131 242 6700
> F: +44 131 242 6782
> E: jma...@st...
>
>
> The University of Edinburgh is a charitable body, registered in Scotland,
> with registration number SC005336.
--
Dr Jonathan Manning
Bioinformatics Team
Centre for Cardiovascular Science
University of Edinburgh
Queens Medical Research Institute
47 Little France Crescent
Edinburgh EH16 4TJ
United Kingdom
T: +44 131 242 6700
F: +44 131 242 6782
E: jma...@st...
The University of Edinburgh is a charitable body, registered in Scotland,
with registration number SC005336.
|
|
From: Jon M. <Jon...@ed...> - 2012-04-12 13:43:25
|
The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. |
|
From: David N. <dav...@gm...> - 2012-04-12 13:13:14
|
Yes that's incorrect. Don't add the xxxTranscripts.fasta. All of the splice junctions are in the xxxSplices.fasta file. I'll cc Colin here to correct this in the Novocraft docs. See also http://useq.sourceforge.net/usageRNASeq.html Not sure about the chr1 vs 1 . Off the top of my head I don't think there should be a problem with USeq apps. But then again we haven't tested them. Most of the genome browsers will probably complain unless you register a synonyms table. Sounds like the ensembl browser wont though so maybe it isn't an issue. -cheers, D From: Jon Manning <Jon...@ed...> Date: Thu, 12 Apr 2012 14:04:45 +0100 To: David Nix <dav...@gm...> Cc: <use...@li...> Subject: Re: [Useq-users] Error with USeq SamTranscriptomeParser while processing Novoalign RNA-seq outputs Hi David, Thanks for the quick reply. Following the Novoalign folks' instructions the transcripts were indeed added to the index. Excerpt from their docs: novoindex Transcriptome.nix geneMaskedGenome.fasta refFlatRad45Num60kMin10Splices.fasta refFlatRad45Num60kMin10Transcripts.fasta Is that not the right thing to do? Should it just be the genome and the splices? I'm working primarily with Ensembl data so I'd like to keep my chromosomes 'sans chr' - unless of course the USeq apps require it? Thanks, Jon On 12/04/2012 12:45, David Nix wrote: > > Did you by chance add the transcripts to your genome index from the > MakeTranscriptome App? These take the form of > ENSDARG00000012493:ENSDART00000126849:chr20:705345-705376_708... > > > > > That also could be the problem. -cheers, D > > > > > > > > > > > > > > > > > > > > > > > > > > Ahh, looks like you've joined your gene name using a : . Use an _ . The STP > uses the : to split the splice junction chromosome name into it's component > parts. A good junction should look like > > > > > ENSDARG00000087418:chr20:6691-6707_9356-9386_9436-9463_9494-9513 > > > > > Rps3:ENSRNOT00000023935:1:156811472-156811541.... should be > Rps3_ENSRNOT00000023935:1:156811472-156811541...... > > > > > As such STP isn't able to recognize the alignment as needing conversion to > genomic coordinates. > > > > > Also, it would be a good idea to rename your chromosomes to the standard UCSC > nomenclature: chr1, chr2, chr3.... I've no idea why NCBI and others switched > a couple years back. > > > > > Yes, all splice junction header lines are stripped from the SAM header, they > aren't needed after genomic coordinate conversion. > > > > > -cheers, D > > > > > From: Jon Manning <Jon...@ed...> > Date: Thu, 12 Apr 2012 10:18:32 +0100 > To: <use...@li...> > Subject: [Useq-users] Error with USeq SamTranscriptomeParser while > processing Novoalign RNA-seq outputs > > > > > > > Hello, > > I've been working through the Novoalign RNA-seq instructions > <http://www.novocraft.com/wiki/tiki-index.php?page=RNASeq+analysis%3A+mRNA+and > +the+Spliceosome&structure=Novocraft+Technologies&page_ref_id=35> , and am > stuck at the last stage, where reads are converted back to genomic coordinates > with USeq SamTranscriptomeParser, and I'm hoping you may be able to help. > > When it gets to the 'Adding SAM header, sorting, and writing bam output with > Picard's SortSam...' stage I'm getting errors like: > > Exception in thread "main" net.sf.samtools.SAMFormatException: Error parsing > text SAM file. RNAME > 'Rps3:ENSRNOT00000023935:1:156811472-156811541_156811891-156812088_156812500-1 > 56812688_156814773-156814868_156815362-156815456_156815668-156815799_156816728 > -156816770' not found in any SQ record; Line 27 > Line: EBRI093151:81:FC:1:1:3202:1108 133 > Rps3:ENSRNOT00000023935:1:156811472-156811541_156811891-156812088_156812500-15 > 6812688_156814773-156814868_156815362-156815456_156815668-156815799_156816728- > 156816770 375 0 * = 375 0 > AANAAGTGGCCACAANNNNNNNNNGNGCCATNGCCCAGNNNNNNNCTCNACGCNACAAACNCTNAGGAGGGCTTGCAG > B=#==A>ABCCBBAB############################################################### > PG:Z:novoalign ZS:Z:QC > > I've checked, and these lines ARE present in the input SAM file (made by > Novoalign), but not in the temporary SAM files I can see created by > SamTranscriptomeParser, so I suspect they may be lost somehow. > > I'm not sure how to go about debugging this myself, so all pointers > appreciated. > > Thanks, > > Jon Manning > > > > The University of Edinburgh is a charitable body, registered in Scotland, > with registration number SC005336. > ------------------------------------------------------------------------------ > For Developers, A Lot Can Happen In A Second. Boundary is the first to > Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try > it FREE! > http://p.sf.net/sfu/Boundary-d2dvs2___________________________________________ > ____ Useq-users mailing list > Use...@li...https://lists.sourceforge.net/lists/listinfo/u > seq-users -- Dr Jonathan Manning Bioinformatics Team Centre for Cardiovascular Science University of Edinburgh Queens Medical Research Institute 47 Little France Crescent Edinburgh EH16 4TJ United Kingdom T: +44 131 242 6700 F: +44 131 242 6782 E: jma...@st... The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. |
|
From: Jon M. <Jon...@ed...> - 2012-04-12 13:05:05
|
The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. |
|
From: David N. <dav...@gm...> - 2012-04-12 11:46:03
|
Did you by chance add the transcripts to your genome index from the MakeTranscriptome App? These take the form of ENSDARG00000012493:ENSDART00000126849:chr20:705345-705376_708... That also could be the problem. -cheers, D Ahh, looks like you've joined your gene name using a : . Use an _ . The STP uses the : to split the splice junction chromosome name into it's component parts. A good junction should look like ENSDARG00000087418:chr20:6691-6707_9356-9386_9436-9463_9494-9513 Rps3:ENSRNOT00000023935:1:156811472-156811541.... should be Rps3_ENSRNOT00000023935:1:156811472-156811541...... As such STP isn't able to recognize the alignment as needing conversion to genomic coordinates. Also, it would be a good idea to rename your chromosomes to the standard UCSC nomenclature: chr1, chr2, chr3.... I've no idea why NCBI and others switched a couple years back. Yes, all splice junction header lines are stripped from the SAM header, they aren't needed after genomic coordinate conversion. -cheers, D From: Jon Manning <Jon...@ed...> Date: Thu, 12 Apr 2012 10:18:32 +0100 To: <use...@li...> Subject: [Useq-users] Error with USeq SamTranscriptomeParser while processing Novoalign RNA-seq outputs Hello, I've been working through the Novoalign RNA-seq instructions <http://www.novocraft.com/wiki/tiki-index.php?page=RNASeq+analysis%3A+mRNA+a nd+the+Spliceosome&structure=Novocraft+Technologies&page_ref_id=35> , and am stuck at the last stage, where reads are converted back to genomic coordinates with USeq SamTranscriptomeParser, and I'm hoping you may be able to help. When it gets to the 'Adding SAM header, sorting, and writing bam output with Picard's SortSam...' stage I'm getting errors like: Exception in thread "main" net.sf.samtools.SAMFormatException: Error parsing text SAM file. RNAME 'Rps3:ENSRNOT00000023935:1:156811472-156811541_156811891-156812088_156812500 -156812688_156814773-156814868_156815362-156815456_156815668-156815799_15681 6728-156816770' not found in any SQ record; Line 27 Line: EBRI093151:81:FC:1:1:3202:1108 133 Rps3:ENSRNOT00000023935:1:156811472-156811541_156811891-156812088_156812500- 156812688_156814773-156814868_156815362-156815456_156815668-156815799_156816 728-156816770 375 0 * = 375 0 AANAAGTGGCCACAANNNNNNNNNGNGCCATNGCCCAGNNNNNNNCTCNACGCNACAAACNCTNAGGAGGGCTTGC AG B=#==A>ABCCBBAB############################################################# ## PG:Z:novoalign ZS:Z:QC I've checked, and these lines ARE present in the input SAM file (made by Novoalign), but not in the temporary SAM files I can see created by SamTranscriptomeParser, so I suspect they may be lost somehow. I'm not sure how to go about debugging this myself, so all pointers appreciated. Thanks, Jon Manning The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. ---------------------------------------------------------------------------- -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2_________________________________________ ______ Useq-users mailing list Use...@li...https://lists.sourceforge.net/lists/listinfo /useq-users |
|
From: David N. <dav...@gm...> - 2012-04-12 11:34:50
|
Ahh, looks like you've joined your gene name using a : . Use an _ . The
STP uses the : to split the splice junction chromosome name into it's
component parts. A good junction should look like
ENSDARG00000087418:chr20:6691-6707_9356-9386_9436-9463_9494-9513
Rps3:ENSRNOT00000023935:1:156811472-156811541.... should be
Rps3_ENSRNOT00000023935:1:156811472-156811541......
As such STP isn't able to recognize the alignment as needing conversion to
genomic coordinates.
Also, it would be a good idea to rename your chromosomes to the standard
UCSC nomenclature: chr1, chr2, chr3.... I've no idea why NCBI and others
switched a couple years back.
Yes, all splice junction header lines are stripped from the SAM header, they
aren't needed after genomic coordinate conversion.
-cheers, D
From: Jon Manning <Jon...@ed...>
Date: Thu, 12 Apr 2012 10:18:32 +0100
To: <use...@li...>
Subject: [Useq-users] Error with USeq SamTranscriptomeParser while
processing Novoalign RNA-seq outputs
Hello,
I've been working through the Novoalign RNA-seq instructions
<http://www.novocraft.com/wiki/tiki-index.php?page=RNASeq+analysis%3A+mRNA+a
nd+the+Spliceosome&structure=Novocraft+Technologies&page_ref_id=35> , and am
stuck at the last stage, where reads are converted back to genomic
coordinates with USeq SamTranscriptomeParser, and I'm hoping you may be able
to help.
When it gets to the 'Adding SAM header, sorting, and writing bam output
with Picard's SortSam...' stage I'm getting errors like:
Exception in thread "main" net.sf.samtools.SAMFormatException: Error
parsing text SAM file. RNAME
'Rps3:ENSRNOT00000023935:1:156811472-156811541_156811891-156812088_156812500
-156812688_156814773-156814868_156815362-156815456_156815668-156815799_15681
6728-156816770' not found in any SQ record; Line 27
Line: EBRI093151:81:FC:1:1:3202:1108 133
Rps3:ENSRNOT00000023935:1:156811472-156811541_156811891-156812088_156812500-
156812688_156814773-156814868_156815362-156815456_156815668-156815799_156816
728-156816770 375 0 * = 375 0
AANAAGTGGCCACAANNNNNNNNNGNGCCATNGCCCAGNNNNNNNCTCNACGCNACAAACNCTNAGGAGGGCTTGC
AG
B=#==A>ABCCBBAB#############################################################
## PG:Z:novoalign ZS:Z:QC
I've checked, and these lines ARE present in the input SAM file (made by
Novoalign), but not in the temporary SAM files I can see created by
SamTranscriptomeParser, so I suspect they may be lost somehow.
I'm not sure how to go about debugging this myself, so all pointers
appreciated.
Thanks,
Jon Manning
The University of Edinburgh is a charitable body, registered in Scotland,
with registration number SC005336.
----------------------------------------------------------------------------
-- For Developers, A Lot Can Happen In A Second. Boundary is the first to
Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try
it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2_________________________________________
______ Useq-users mailing list Use...@li...
https://lists.sourceforge.net/lists/listinfo/useq-users
|
|
From: Jon M. <Jon...@ed...> - 2012-04-12 09:18:56
|
The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. |
|
From: Sergiusz W. <we...@gm...> - 2012-04-02 20:55:22
|
Hello I am currently working on a differential expression algorithm at Georgia Health Sciences Univeristy (USA) and I desperately need to test it on some benchmark dataset. I have found, that your project has such, but I have some problems with using it - I was wondering if you could help me: Is there any description available for the testDataset content available at: http://bioserver.hci.utah.edu/TestDatasets/ besides the included pptx file? What do particular columns represent in treatment and control files? I was trying to figure out what filetype the replicates are, but could not assign any. They look similar to SAM, but aren't, nor fasta/fastq nor SRA/SRF files. Do I understad correctly that they were generated by RNA-Seq Simulator? Regards Sergiusz Wesolowski PS: I greatly appreciate your work! Your are the only project I have found that made available some test dataset. I am surprised that so little concern is put into benchmarking the RNA-Seq methods in general, which, I thought, is the first thing you have to do when developing statistical method. |
|
From: David N. <Dav...@hc...> - 2012-03-02 21:30:22
|
Oh the headaches..... DESeq is being very strict in calling variance outliers when analyzing multiple replica RNA-Seq data. So much so that with human patient datasets many genes that are clearly differentially expressed (DE) are being dropped. This feature of DESeq can be disabled using the sharingMode='fit-only' when estimating dispersions unfortunately this leads to many false positives in the DE lists. The best solution I've been able to concoct so far is to run DESeq with and without the outlier filtering, present both sets of pvalues and FDRs and then provide (by default) the smallest of the all pair log2 ratio DE metrics. This smallest log2 ratio is a worst case estimate of DE. Thus to get a starting list of DE genes to work with from a multiple replica RNA-Seq experiment, filter for BH_FDR_NoVarOutFilt values > 10 (10% FDR) and Log2Ratio's of < or > 1. If the gene's BH_FDR_VarOutFilt also passes threshold great. These problems of over aggressive outlier filtering may only apply to human patient samples where the biological variation is quite large do to other confounding issues with each patient. Thanks to Don Delker and Curt Hagedorn for pointing out these particular issues. -cheers, D |
|
From: David N. <dav...@gm...> - 2012-03-02 16:35:13
|
Hello Richard, The pval is based not on the total bp but on the number of regions that intersect. The average is actually the average number of intersections observed from the random trials. This lets one calculate a fold enrichment over the random for a given real intersection between your region lists. Yes, the random intervals could be outputted to file. If this is something you would really really like then put in a feature request on USeq Sourceforge. -cheers, D On 3/1/12 7:52 AM, "Baker, Richard" <Ric...@um...> wrote: >I'm not sure I completely understand the output from IntersectRegions, >but it looks as though the randomization P value is the fraction of >trials in which the total bp intersected equals or exceeds the that of >the actual query. Is it possible to determine the average number of >random intervals "hit" per trial (as opposed to total bp)? >Alternatively, could the program be easily modified to output the random >regions into a file? This would be extremely useful, and I've not found >another tool that does this. > >-------------------------------------------------------------------------- >---- >Virtualization & Cloud Management Using Capacity Planning >Cloud computing makes use of virtualization - but cloud computing >also focuses on allowing computing to be delivered as a service. >http://www.accelacomm.com/jaw/sfnl/114/51521223/ >_______________________________________________ >Useq-users mailing list >Use...@li... >https://lists.sourceforge.net/lists/listinfo/useq-users |
|
From: Baker, R. <Ric...@um...> - 2012-03-01 14:53:04
|
I'm not sure I completely understand the output from IntersectRegions, but it looks as though the randomization P value is the fraction of trials in which the total bp intersected equals or exceeds the that of the actual query. Is it possible to determine the average number of random intervals "hit" per trial (as opposed to total bp)? Alternatively, could the program be easily modified to output the random regions into a file? This would be extremely useful, and I've not found another tool that does this. |
|
From: David N. <dav...@gm...> - 2012-02-22 14:36:05
|
OK Andrew, the latest release 8.1.6 fixes your java issue with the RNASeq and ChIPSeq apps. -cheers, D From: Nicholas Dickens <Nic...@gl...> Date: Tue, 7 Feb 2012 08:26:00 -0000 To: "Oler, Andrew (NIH/NIAID) [C]" <and...@ni...>, David Nix <dav...@hc...> Cc: <use...@li...> Subject: Re: [Useq-users] ChIPSeq java error RE: [Useq-users] ChIPSeq java error Can you edit your path (depending on your shell either export PATH= in bash or set PATH for tcsh) and reset it completely so it doesn't look in /usr/bin ... temporarily resetting it while you are using Useq. Best wishes, Nick Nick Dickens DPhil BSc ARCS Genome and Data Analyst Wellcome Trust Centre for Molecular Parasitology B6-21 Glasgow Biomedical Research Centre 120 University Place Glasgow G12 8TA, UK Tel: +44 (0)141 330 8282 -----Original Message----- From: Oler, Andrew (NIH/NIAID) [C] [mailto:and...@ni...] Sent: Mon 2012-02-06 19:37 To: David Nix Cc: use...@li... Subject: [Useq-users] ChIPSeq java error Hi David, I'm running the ChIPSeq application from USeq 8.0.7 and I'm getting this error: The following problems were encountered when processing your parameter file. Correct and restart. -> Your java application is not >= 1.6 (type 'java -version' on the cmd line). Install the most recent java from http://www.java.com/en/download/ . Your save results directory exits, may overwrite the files within. When I type java -version on the command line, I get this output: java -version java version "1.6.0_22" Java(TM) SE Runtime Environment (build 1.6.0_22-b04) Java HotSpot(TM) 64-Bit Server VM (build 17.1-b03, mixed mode) The java version is fine, so I'm not sure what the problem is. java is an alias for a locally installed version of java, which is 1.6. Could it be that the ChIPSeq program calls '/usr/bin/java' instead of 'java'? /usr/bin/java -version java version "1.4.2" gij (GNU libgcj) version 4.1.2 20080704 (Red Hat 4.1.2-46) Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. I'm running this on a system where I can't change the binaries in /usr/bin/. Any suggestions? Thanks, Andrew Andrew Oler, Ph.D. Contractor - Lockheed Martin High-Throughput Sequencing Bioinformatics Specialist Computational Biology Section Bioinformatics and Computational Biosciences Branch (BCBB) OCICB/OSMO/OD/NIAID/NIH 31 Center Drive, Room 3B62 Bethesda, MD 20892 Mobile: 240-507-3791 Office: 301-402-5685 http://bioinformatics.niaid.nih.gov<http://bioinformatics.niaid.nih.gov/> (Within NIH) http://exon.niaid.nih.gov<http://exon.niaid.nih.gov/> (Public) Disclaimer: The information in this e-mail and any of its attachments is confidential and may contain sensitive information. It should not be used by anyone who is not the original intended recipient. If you have received this e-mail in error please inform the sender and delete it from your mailbox or any other storage devices. National Institute of Allergy and Infectious Diseases shall not accept liability for any statements made that are sender's own and not expressly made on behalf of the NIAID by one of its representatives. ---------------------------------------------------------------------------- -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 _______________________________________________ Useq-users mailing list Use...@li... https://lists.sourceforge.net/lists/listinfo/useq-users ---------------------------------------------------------------------------- -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d_________________________________________ ______ Useq-users mailing list Use...@li... https://lists.sourceforge.net/lists/listinfo/useq-users |
2 messages has been excluded from this view by a project administrator.
