Recent changes to tickets

Ticket 15 discussion

2023-05-29T13:22:41.084000Z

did you ever find the solution to this problem?

I'm also using a non-dmel genome and i can only get piN/piS for ~200 genes. I'm guessing this has to do with the start/stop codons as well ...

Tajima's D denominator uses one function for alphastarcalc and betastarcalc

2020-02-08T00:09:37.887000Z

in get_ddivisor (lines 104-105) both alphastar and betastar use the same function. Is this correct?

...

$alphastarcalc=get_betastar_calculator() $betastarcalc=get_betastar_calculator()

...

subsampling gives error

2019-08-05T03:07:54.310000Z

When I am creating subsampled mpileup, I am seeing this error:
"size of sequence does not equal size of quality: AaAaAaAAAAAAAAaAAaaAAaaaAAaAaaAaAAaaaaaaaaAAaaaAAAAAaAAaaaAAAAAAAAAAaaAaaaaAaaaAaAAaaAaAAaaaaaaAAAAAaaaaaA, IJ<JJJJFJAJFJJFJJJJJJJJJJJJJJJJJJFJJJJJJJJJJJJJF7JJJJAJJJ<JJJJFJJJJJJJJJJJJJJJFJJJJJJJJJFJJJJ"
I know the problem is with my mpileup, but I am hoping you can provide a solution. Is manually deleting using grep a viable scientific option?

Ticket 3 discussion

2017-07-20T23:26:04.775000Z

Hello,
I have run into the same problem and was wondering if this was resolved?

Thank you

#18 Subsampling pileups with subsample-pileup.pl

2016-03-21T00:00:08.510000Z

Just to add: I can see that coverage isn't even across the whole contig in the example given. So I am guessing that the script only pumps out those loci that actually have enough initial coverage to do the subsampling? But why collapse into a single population with exact same quality scores per read?

Subsampling pileups with subsample-pileup.pl

2016-03-20T23:51:56.008000Z

Hey Ro,

I am confused as to what the subsample-pileup.pl script is doing.

I have a pileup with 2 populations. When I run the following command:

perl ~/Exes/popoolation1.dir/basic-pipeline/subsample-pileup.pl --input test.pileup --output test-sub.pileup --target-coverage 20 --max-coverage 45 --fastq-type sanger --min-qual 20 --method withoutreplace

I get an output that looks like this (original attached):

E2842_L394  81  N   20  AAAAAAAAAAAAAAAAAAAA    55555555555555555555
E2842_L394  320 T   20  TTTTTTTTTTTTTTTTTTTT    55555555555555555555
E2842_L394  321 A   20  AAAAAAAAAAAAAAAAAAAA    55555555555555555555
E2842_L394  323 C   20  CCCCCCCCCCCCCCCCCCCC    55555555555555555555

It's gotten rid of the population information, and it has made the quality scores exactly the same. Have I done something wrong? From what I can tell, it hasn't subsampled like expected and merged everything into one population?

Cheers,

~ Josh

#17 Scripts for calculating Dxy

2015-12-02T19:06:48.130000Z

To follow up:

as often seems to happen, once I submitted this ticket I discovered that I had confused the reference and the outgroup in the input to mauve-parser.pl. After correcting that mistake, the sixth column of calculate-dxy.pl has values of 0.0, and 0.6-1.0. Can you confirm that this is indeed coverage? And if so, how is it calculated? The calculate-dxy.pl script refers to "the minimum fraction of a window being between min-coverage and max-coverage in ALL populations," which doesn't seem to apply here.

Scripts for calculating Dxy

2015-12-02T00:45:10.270000Z

I've been using the mauve-parser.pl and calculate-dxy.pl scripts and identified one possible bug and one thing I'd like clarified:

1.) From mauve-parser.pl, I'm consistently getting the output along the lines of "Not fitting character states in chromosome KB667555; at position 266212; G not equal to C". However, the script seems to run to completion and the output of calculate-dxy.pl, downstream, is sensible and includes KB667555. Can you give me any more information about this warning so I can determine how to fix my pipeline?

2.) The output of calculate-dxy.pl has six columns: the chromosome, the position, three columns for distance, and a sixth with numbers ranging from 0.0 to 29.67. All the rows where the distance columns are "na" have either 0.0 or 0.01 in this sixth column, and all the rows where the distance columns have a value have at least 0.60 in this column, so I thought it might be the fraction covered (I did not change the default min-covered-fraction); however, the maximum is well over 1. The help for calculate-dxy.pl only documents five columns. Is this sixth column supposed to be there, is it sensible, and if so, what is it?

Thanks.

Ticket 1 discussion

2015-08-20T13:45:47.831000Z

no changes have been made, it's the number of chromosomes still. Thanks for pointing out this error in the walkthrough. I have to change this. Sorry for the confusion!
cheers ro

Ticket 1 discussion

2015-08-20T13:41:28.216000Z

I would like to follow up on this issue. I don't know what changes to the software have been made since the original query; however, I see that the walkthrough on this site uses the number of individuals as the pool size, while the slides Dr. Kofler graciously posted from a class last year use the number of chromosomes. I've seen it done both ways in the literature.

What's the current recommendation?

Thanks.