Unconfigured Ad

Collapse
X
 
  • Time
  • Show
Clear All
new posts

  • sushant
    replied
    Originally posted by maubp View Post
    Sushant - what does line 2305 of your SAM file look like? Unless the quality entry is the special value '*' only then it is a likely an unrelated issue.
    Actually, I did see that SAM file. The problem is that my sequence string & its respective sequence quality string is not of equal length.
    However, I converted my fastq files to fasta and then performed the alignment, which solved this problem.

    But the mapping percentage I'm getting with SHRiMP is too low(2.77%), for the mirna aligning to mature.
    What parameters should I consider?

    Leave a comment:


  • maubp
    replied
    Sushant - what does line 2305 of your SAM file look like? Unless the quality entry is the special value '*' only then it is a likely an unrelated issue.

    Leave a comment:


  • sushant
    replied
    Originally posted by Simon Anders View Post
    Sorry, it seems we made some mix-up between version 0.5.3p4 and 0.5.3p5. Essentially, p5 undid some fixes in p4, including the one for "*" qualities. Now, there is version 0.5.3p6, which should clean up this mess. Please let me know if you still have problems.
    Hello, I have performed the mapping of miRNA reads to the mirbase precursor file by SHRiMP. But I'm facing a probem in HTSeq while taking the read counts from the output.sam file.

    The error which I'm trying to solve is;

    Error occured when processing SAM input (line 2305 of file HBI_10.sam): ("'seq' and 'qualstr' do not have the same length.", 'line 2305 of file HBI_10.sam') [Exception type: ValueError, raised in _HTSeq.pyx:808]

    Has anyone of you come across this error? What might be the solution?

    Leave a comment:


  • EGrassi
    replied
    Thanks, 0.5.3p9 has produced counts different from zero. Let's see what deSeq thinks of this data!

    Leave a comment:


  • Simon Anders
    replied
    The bug with the NH flags, which was introduced during some refactoring in the version of a week ago or so is now fixed in version 0.5.3p8. Sorry that the recent changes turned out to be so volatile.

    Leave a comment:


  • EGrassi
    replied
    Ok, on the whole data it falls back to all 0:
    samtools view S1.sorted.bam.bam | sed 's/NM:i:\d//g' | htseq-count --stranded=no - /rogue/bioinfotree/prj/ewing-rnaseq/local/share/data/Homo_sapiens/UCSC/hg19/Annotation/Genes/genes.gtf > counts_S1_htseqq

    I'm really a little surprised by the amount of errors and other glitches in rna seq software (this is a generic rant, not focused on htseq!)...it's a really complicated and new area, that's true, but right now using any of the existing tool seems a bet and to tell the truth I never feel confident on the results, as long as with every version results changes, and when something runs without errors I never know if that means that it worked or that an exception just had not screamed enough :/

    Leave a comment:


  • EGrassi
    replied
    Yep, I can confirm you that removing the NH flags from a subset of my sam files I get some counts different from 0. This could be a temporary workaroud.

    Leave a comment:


  • EGrassi
    replied
    Originally posted by Simon Anders View Post
    Was this by any chance a TopHat output? Somebody alerted me recently to a bug that causes mishandling of SAM lines that contain the "NH" flag, and that seems to appear in newer tophat output. I'll try to fix this ASAP.
    Tophat 2.0 output, yes!

    Thank you,
    E.

    Leave a comment:


  • Simon Anders
    replied
    Originally posted by EGrassi View Post
    Woa, I used samtools -n and htseq-count gave me all counts of zero...that's strange, I will check with IGV or similar tools but cuffdiff gave me fpkg values with the same gtf and bam file...
    Was this by any chance a TopHat output? Somebody alerted me recently to a bug that causes mishandling of SAM lines that contain the "NH" flag, and that seems to appear in newer tophat output. I'll try to fix this ASAP.

    Simon

    Leave a comment:


  • EGrassi
    replied
    Originally posted by TEFA View Post
    Hi EGrassi,

    Did you solve this issue??????
    Actually no, right now I'm trying to avoid using '-' as an htseq-count argument without using it in a pipeline with samtools view, I'll let you know what happens...

    Leave a comment:


  • TEFA
    replied
    Originally posted by EGrassi View Post
    Woa, I used samtools -n and htseq-count gave me all counts of zero...that's strange, I will check with IGV or similar tools but cuffdiff gave me fpkg values with the same gtf and bam file...
    Hi EGrassi,

    Did you solve this issue??????

    Cheers,
    TEFA

    Leave a comment:


  • EGrassi
    replied
    Woa, I used samtools -n and htseq-count gave me all counts of zero...that's strange, I will check with IGV or similar tools but cuffdiff gave me fpkg values with the same gtf and bam file...

    Leave a comment:


  • vyellapa
    replied
    Thanks Paul, using -n produced no differences.

    Leave a comment:


  • Dethecor
    replied
    Sort by position or name

    Hi vyellapa,

    if you run htseq-count on paired-end reads then you might want a .sam file sorted by name. Your Unix sort command does this (I hope it deals with the header properly), samtools sort sorts by position unless you specify the -n option.

    That would be one likely source of the disparity between the counts you observed.

    Cheers,
    Paul

    Leave a comment:


  • vyellapa
    replied
    I'm curious what the best way to sort the sam file to give as input to htseq-count
    I have sorted using samtools and UNIX sort as shown below
    Code:
    sort 1:
    sort -T /scratch/vyellapantula -s -k 1,1 input.sam > sorted.sam
    
    sort 2:
    samtools sort input.bam sorted
    samtools view -h -o sorted.sam sorted.bam
    Ive used the same htseq-count command on these sams and ran a diff on these outputs.There are some differences and would like to know of the best way to sort the bam/sam file for htseq.

    Code:
    < ENSG00000259158	   14
    ---
    > ENSG00000259158	   23
    51905c51905
    < ENSG00000259165	   15
    ---
    > ENSG00000259165	   30

    Leave a comment:

Latest Articles

Collapse

  • SEQadmin2
    Multiomic Liquid Biopsy: What DNA/RNA Panels Reveal That DNA Alone Can’t
    by SEQadmin2



    Tumors contain complex mixtures of cell populations that evolve in response to treatment and host-specific factors. Tissue biopsies provide only static snapshots of a tumor’s state. But what if we could follow that evolution over time using a minimally invasive technique?

    Liquid biopsies can detect tumor-derived material circulating in the bloodstream, providing a way to study treatment response, detect emerging resistance, and discover new biomarkers. Circulating
    ...
    10-14-2026, 09:55 AM
  • SEQadmin2
    New Genomics Technologies Take Aim at Long-Standing Limits
    by SEQadmin2


    Researchers using sequencing and genomics tools often have to make trade-offs. They can choose between speed or scale, short reads or long-range information, or targeted panels or a view of the whole transcriptome. New technologies that have been released this year are built to address those tough choices.

    We asked six companies the same four questions to learn about their latest products. The new technologies bring a lot to the table, including rethinking sequencing
    ...
    09-28-2026, 10:25 AM

ad_right_rmr

Collapse

News

Collapse

Topics Statistics Last Post
Started by SEQadmin2, 10-22-2026, 11:13 AM
0 responses
34 views
0 reactions
Last Post SEQadmin2  
Started by SEQadmin2, 10-22-2026, 10:48 AM
0 responses
25 views
0 reactions
Last Post SEQadmin2  
Started by SEQadmin2, 10-15-2026, 10:52 AM
0 responses
41 views
0 reactions
Last Post SEQadmin2  
Started by SEQadmin2, 10-14-2026, 05:39 AM
0 responses
45 views
0 reactions
Last Post SEQadmin2  
Working...