No Locus contains enough reads to extract read length about gangstr

[eudesbarbosa]

Hi, Nima.

It worked! Thanks a lot for the help =)

--
Eudes

[nmmsv]

Hello,
Can you please check if the ref name (chromosome names) match between alignment (bam) file, the regions (bed) file, and the reference genome (fasta/fa) that you're using? (i.e., if the convention is chr1:100-200 or just simply 1:100-200)
Also, is the bam file whole-genome or is it just limited to a region? How large is that region?
Thanks for reporting this issue!
Nima

[eudesbarbosa]

Hi,

I had the same error: "[GangSTR-1.4] ERROR: No Locus contains enough reads to extract read length. (Possible mismatch in chromosome names)"
Everything seems to be working fine when I use the whole genome, but when I extract a region and run it again, I receive the error message.

BAM Region: 4:3076000-3078000
RepeatId:* HTT
TargetRegion: 4:3076604-3076660
OS: CentOS Linux 7 (Core)

Is there an argument I should pass?

Thanks for the help!

Eudes

[nmmsv]

Hi,
In order to find the read length, GangSTR tries to find 10 consecutive reads with the same length in a 20k window around the repeat. Based on what you describe, this shouldn't be an issue in your run.
But you can go around this problem by manually setting the read length directly from command line (use --readlength ).
Please let me know if that didn't work.
Best,
Nima

[eudesbarbosa]

Hi,

Thanks for the quick reply. Even manually defining it (--readlength) I stumble on the same error =/
For the whole genome, it runs regardless of the parameter.

Process:
$ samtools view file.bam | head -n 10000 | awk '{print length($10)}' | sort -n | uniq -c #10000 150
$ samtools view -b file.bam "4:3076000-3078000" > region.bam
$ samtools view region.bam | awk '{print length($10)}' | sort -n | uniq -c #414 150
$ GangSTR --bam region.bam --ref genome.fa --regions HTT_hg19.bed --out test --readlength 150

Thanks for the help so far,
Cheers.
Eudes

[nmmsv]

Hi Eudes,
Can you please check if the bed file that you're using HTT_hg19.bed has chromosome names formatted similar to your bam file? It seems like your bam file uses single numbers as chromosome IDs (4 as opposed to chr4).
If the chromosome IDs in bed and bam match, can you please run GangSTR in --verbose mode and send the log? That will help me narrow down the source of the problem.
Thanks,
Nima

[eudesbarbosa]

Hi, Nima.

The Fasta file I'm using has single numbers/character as identifiers, so it was easier to just modify the repeat definitions.

I attached the log for the whole bam (whole_bam.log) and restricted region (region_bam.log)

$ GangSTR --bam whole.bam --ref genome.fa --regions HTT_hg19.bed --out test_whole --verbose
$ GangSTR --bam region.bam --ref genome.fa --regions HTT_hg19.bed --out test _region --readlength 150 --verbose

Let me know if you need something else,
Cheers.
Eudes

[nmmsv]

Thank you for sending the logs.
It seems to me that the error is in the computation of coverage and mean and standard deviation of insert size. This is expected as the number of reads in the smaller bam file is probably not enough to pass the threshold for computing these parameters. The threshold is set to 300 in the released version, and it is not exposed to the user. While it is possible to lower this threshold, I think a better solution is to supply coverage and mean and standard deviation of insert size as parameters in input. You can use the values computed in the whole genome log.
Parameters to set:
--insertmean <float>: Fragment length mean. Default: -1
--insertsdev <float>: Fragment length standard deviation. Default: -1
--coverage <float>: Average coverage. must be set for exome/targeted data. Default: -1

[nmmsv]

Perfect!
No problem.