[ensembl-dev] trouble with ldFeatureContainerAdaptor->fetch_by_VariationFeature

[andrew126 at mac.com]

Hi Anja,

Perfect .. thanks for the explanation .. just wanted to make sure what I was seeing made sense .. smile.

Thanks for the help.

Best,

Andrew

> On Sep 13, 2018, at 7:10 AM, Anja Thormann <anja at ebi.ac.uk> wrote:
> 
> Hi Andrew,
> 
> for your example it is expected that Tabix.pm->query is not called anymore. We added genotype data for sheep and goat. Some of the new sheep and goat VCF files don’t have variant identifiers which we can use to match them against the variants in our database. We use the Tabix.pm->query step to look up the variants in the VCF file and match them by location and alleles. For human we only have genotype data from 1000 Genomes and we can match variants by identifier. However, the new code was also looking up data in other VCF files e.g. gnomAD even though gnomAD doesn’t provide genotypes. However, for gnomAD we also need to match variants by location and alleles because the identifier is not always provided in the gnomAD VCF file. This is now skipped with the latest code fix. We now check first if the VCF file contains the required samples to make up the population that is used in the LD calculation. Consequently gnomAD is skipped and no Tabix.pm->query performed. Please let me know if you need any further clarifications. I’m happy to explain more if needed.
> 
> Anja
> 
>> On 13 Sep 2018, at 13:30, andrew126 at mac.com <mailto:andrew126 at mac.com> wrote:
>> 
>> Hi Anja,
>> 
>> Thanks for the quick fix.  After pull'ing my checkout of the 93 branch, I no longer see the error and I seem to get good LD results.  But it seems like the Tabix.pm query method no longer gets called in the same way?  That is, the debug code I put in that function doesn't seem to get called anymore, so I can't positively confirm what region has been sent to the function.  Was there some change, such that Tabix.pm->query no longer gets called?
>> 
>> Thanks.
>> 
>> Best,
>> 
>> Andrew
>> 
>>> On Sep 13, 2018, at 2:24 AM, Anja Thormann <anja at ebi.ac.uk <mailto:anja at ebi.ac.uk>> wrote:
>>> 
>>> Hi Andrew,
>>> 
>>> this has been fixed on release/93 branch. We pushed the code fix  <https://github.com/Ensembl/ensembl-variation/pull/226>to the release/93 branch. Please refresh your checkout and let us know if you encounter any problems with the code. Thank you for reporting the error.
>>> 
>>> Best wishes,
>>> Anja
>>> 
>>>> On 11 Sep 2018, at 17:09, Anja Thormann <anja at ebi.ac.uk <mailto:anja at ebi.ac.uk>> wrote:
>>>> 
>>>> Hi Andrew,
>>>> 
>>>> thank you for the bug report. We are looking into what’s causing the error and will soon get back to you with a fix.
>>>> 
>>>> Thank you,
>>>> Anja
>>>> 
>>>>> On 10 Sep 2018, at 09:08, andrew126 at mac.com <mailto:andrew126 at mac.com> wrote:
>>>>> 
>>>>> Hi,
>>>>> 
>>>>> This applies to Ensembl API v93.
>>>>> 
>>>>> I am occassionally getting failures from ldFeatureContainerAdaptor->fetch_by_VariationFeature with the following message:
>>>>> 
>>>>> 	You must specify a region in the format chr, chr:start or chr:start-end at /usr/local/ensembl/ak_API93/Bio-DB-HTS/lib/Bio/DB/HTS/Tabix.pm line 104.
>>>>> 
>>>>> One of the failure instances occured for variation feature rs12445289 (its chr 16 mapping), and I was able to see that this region was provided to Tabix.pm:
>>>>> 
>>>>> 	16:-81648-918353
>>>>> 
>>>>> rs12445289 is at location 418,353 on chr 16, and I was using a max_snp_distance of 500000, which seems to explain the start and end values sent to Tabix, but Tabix.pm does not seem prepared to handle a negative start position (I think it wants to see only a digit after the first colon).
>>>>> 
>>>>> fetch_by_VariationFeature for chr-16 rs12445289 +/- 500,000 does not fail throw any error for Ensembl API v90, fwiw
>>>>> 
>>>>> Is there a fix possible for this?
>>>>> 
>>>>> Thanks for any help.
>>>>> 
>>>>> Best,
>>>>> 
>>>>> Andrew
>>>>> 
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> Dev mailing list    Dev at ensembl.org <mailto:Dev at ensembl.org>
>>>>> Posting guidelines and subscribe/unsubscribe info: http://lists.ensembl.org/mailman/listinfo/dev <http://lists.ensembl.org/mailman/listinfo/dev>
>>>>> Ensembl Blog: http://www.ensembl.info/ <http://www.ensembl.info/>
>>>> 
>>>> _______________________________________________
>>>> Dev mailing list    Dev at ensembl.org <mailto:Dev at ensembl.org>
>>>> Posting guidelines and subscribe/unsubscribe info: http://lists.ensembl.org/mailman/listinfo/dev <http://lists.ensembl.org/mailman/listinfo/dev>
>>>> Ensembl Blog: http://www.ensembl.info/ <http://www.ensembl.info/>
>>> 
>>> _______________________________________________
>>> Dev mailing list    Dev at ensembl.org <mailto:Dev at ensembl.org>
>>> Posting guidelines and subscribe/unsubscribe info: http://lists.ensembl.org/mailman/listinfo/dev <http://lists.ensembl.org/mailman/listinfo/dev>
>>> Ensembl Blog: http://www.ensembl.info/ <http://www.ensembl.info/>
>> 
>> _______________________________________________
>> Dev mailing list    Dev at ensembl.org <mailto:Dev at ensembl.org>
>> Posting guidelines and subscribe/unsubscribe info: http://lists.ensembl.org/mailman/listinfo/dev <http://lists.ensembl.org/mailman/listinfo/dev>
>> Ensembl Blog: http://www.ensembl.info/ <http://www.ensembl.info/>
> 
> _______________________________________________
> Dev mailing list    Dev at ensembl.org
> Posting guidelines and subscribe/unsubscribe info: http://lists.ensembl.org/mailman/listinfo/dev
> Ensembl Blog: http://www.ensembl.info/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ensembl.org/pipermail/dev_ensembl.org/attachments/20180913/56177012/attachment.html>