These are chat archives for dereneaton/ipyrad

22nd
Oct 2016
Deren Eaton
@dereneaton
Oct 22 2016 03:10 UTC
@edgardomortiz the bias in param estimates is very negligible, and may not change base calls at all, but it's ideal of course to have the estimates correct. If the error rate is underestimated, as it was in recent version, it could lead to more hetero site calls in theory. That's fixed now, but I'll try to find the bug in the paired-end code as soon as I can. I'll be traveling/busy the next few days, tho.
Edgardo M. Ortiz
@edgardomortiz
Oct 22 2016 06:03 UTC
Thanks @dereneaton, I think I found the problem, I was lowering mindepth_statistical after running step 3 which I assume produced the IndexError, please check my pull request and see if you agree with the solution. My paired-end datasets are now passing step 4 succesfully.
afrittspenniman
@afrittspenniman
Oct 22 2016 18:38 UTC
Hi @dereneaton, after updating to the new version, when I run step 3 I get the error 'Series' object has no attribute 'reads_passed_filter'. I see that the stats from step 2 do include a column 'reads_passed_filter' and there certainly are reads that passed, so, what's going on? I'm running it on 12 ezRAD libraries a using the "pairgbs" data type.
Deren Eaton
@dereneaton
Oct 22 2016 23:09 UTC
@afrittspenniman there was a slight incompatibility introduced between 0.3 and 0.4, related to the names of the step2 results stats columns, which coincides with big changes to how step 2 functions under the hood. The problem does not arise for assemblies passed step 3, but if you run the first few steps on an older assembly this error will arise. I would recommend restarting your assembly from step 1 demultiplexed data. And you may want to try the new step 2 filtering under its stringent setting.
i.e. I mean create a new assembly with '-n' to start from scratch.