<div dir="ltr">Hi Josh,<div><br></div><div>This isn't the first time this has been reported. I have committed fixes for it to release/83, so they should be in release/84 too, so I'm surprised this is still an issue.</div><div><br></div><div>Basically, it happens for users that have the Sereal perl module installed. The info.txt file that you refer to gets modified by the <a href="http://convert_cache.pl">convert_cache.pl</a> script (the chr column gets added, which is what tabix uses to try and index it). However, it should be reverted to it's original state after the tests, and this works fine for me every time I test it.</div><div><br></div><div>Line 42 of convert_cache.t makes a backup of info.txt to info.txt.bak, then the backup is reinstated on lines 98 an 99. This then happens again on line 144 and 145.</div><div><br></div><div>Can you check if you have info.txt.bak in [install_dir]/t/testdata/vep-cache/homo_sapiens/78_GRCh38/, and if so do:</div><div><br></div><div>mv  [install_dir]/t/testdata/vep-cache/homo_sapiens/78_GRCh38/info.txt.bak  [install_dir]/t/testdata/vep-cache/homo_sapiens/78_GRCh38/info.txt</div><div><br></div><div>Then try running the test script manually from the VEP directory (here's my output after a fresh install):</div><div><br></div><div>> perl t/convert_cache.t</div><div><div>ok 1 - script exists</div><div>ok 2 - run script</div><div>ok 3 - info.txt - var_type tabix</div><div>ok 4 - info.txt - variation_cols</div><div>ok 5 - info.txt - first col chr</div><div>ok 6 - all_vars.gz</div><div>ok 7 - all_vars.gz.tbi</div><div>ok 8 - all_vars.gz - column number</div><div>ok 9 - all_vars.gz - start int</div><div>ok 10 - run script with --sereal</div><div>ok 11 - info.txt - serialiser_type sereal</div><div>ok 12 - transcript file exists</div><div>ok 13 - regfeat file exists</div><div>ok 14 - parsed transcript file</div><div>ok 15 - transcript hash index</div><div>ok 16 - transcript isa</div><div>ok 17 - transcript stable_id</div><div>ok 18 - parsed regfeat file</div><div>ok 19 - regfeat hash index 1</div><div>ok 20 - regfeat hash index 2</div><div>ok 21 - regfeat hash index 3</div><div>ok 22 - regfeat isa</div><div>ok 23 - regfeat stable_id</div><div>1..23</div></div><div><br></div><div>Thanks for your help with this</div><div><br></div><div>Will McLaren<br>Ensembl Variation</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 10 March 2016 at 17:40, Joshua Randall <span dir="ltr"><<a href="mailto:joshua.randall@sanger.ac.uk" target="_blank">joshua.randall@sanger.ac.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I’ve been struggling to install VEP (originally started trying with release 84 but now have reverted to trying release 83), but the tests are failing. This happens with both GRCh37 and GRCh38.<br>
<br>
I’ve dug in a bit deeper to what is going wrong in the current attempt, which is release 83 with GRCh38, and the problem seems to be with the tests of convert_cache.<br>
<br>
What seems to happen is that the first time the <a href="http://convert_cache.pl" rel="noreferrer" target="_blank">convert_cache.pl</a> script is called by convert_cache.t, it successfully runs bgzip on the all_vars file in the cache and then successfully indexes it with tabix. However, the next time it is called, it fails to tabix index it.<br>
<br>
This appears to be because on the first invocation, it is calling tabix like this:<br>
```<br>
tabix -s 1 -b 5 -e 5 /software/hgi/pkglocal/ensembl-vep-release-83-GRCh38/lib/perl5//t/testdata//vep-cache//homo_sapiens/78_GRCh38/21/all_vars.gz<br>
```<br>
<br>
Whereas on all subsequent invocations, it calls tabix like this:<br>
```<br>
tabix -s 1 -b 6 -e 6 /software/hgi/pkglocal/ensembl-vep-release-83-GRCh38/lib/perl5//t/testdata//vep-cache//homo_sapiens/78_GRCh38/21/all_vars.gz<br>
```<br>
<br>
This causes an error message like this:<br>
```<br>
ERROR: tabix failed<br>
[E::get_intv] failed to parse TBX_GENERIC, was wrong -p [type] used?<br>
The offending line was: "21     rs753123870     .       .       25973491        .       G/C     .       .       .       .       .       .       .       .       .       .       .       .       .       .       .       .       .       .       .       .       .  .<br>
"<br>
```<br>
<br>
As you can see, the “offending line” (which is the first line of all_vars) does indeed have position in the 5th column as opposed to the 6th. Something that the first invocation of <a href="http://convert_cache.pl" rel="noreferrer" target="_blank">convert_cache.pl</a> is doing is changing the configuration such that it tries to index the wrong column.<br>
<br>
<br>
I’ve checked the info.txt in the cache before and after running <a href="http://convert_cache.pl" rel="noreferrer" target="_blank">convert_cache.pl</a> for the first time, and the differences are:<br>
<br>
```<br>
# diff -y -W 200 --suppress-common-lines fresh-info.txt.sort broken-info.txt.sort<br>
# CACHE UPDATED 2014-11-20 10:08:53                                                                |    # CACHE UPDATED 2016-03-10 17:16:31<br>
regulatory      1                                                                                  <<br>
source_gencode  GENCODE 22                                                                         |    source_gencode  GENCODE<br>
variation_cols  variation_name,failed,somatic,start,end,allele_string,strand,minor_allele,minor_   |    variation_cols  chr,variation_name,failed,somatic,start,end,allele_string,strand,minor_allele,mi<br>
>  var_type        tabix<br>
```<br>
<br>
<br>
I’ve tracked this down to: <a href="https://github.com/Ensembl/ensembl-tools/blob/release/84/scripts/variant_effect_predictor/convert_cache.pl#L283" rel="noreferrer" target="_blank">https://github.com/Ensembl/ensembl-tools/blob/release/84/scripts/variant_effect_predictor/convert_cache.pl#L283</a><br>
<br>
Why does this line exist (forcing the first column to be “chr”, which seems to break when the “chr” has actually been called “variation_name”) and why is it only a problem for me?<br>
<br>
I am also confused why release 83 is using test cache data from release 78 - is that normal, or might that be part of the problem?<br>
<br>
Perhaps it is useful to note the installer command line I am running:<br>
```<br>
# perl scripts/variant_effect_predictor/INSTALL.pl --DESTDIR /software/hgi/pkglocal/ensembl-vep-release-83-GRCh38/lib/perl5 --CACHEDIR /software/hgi/resources/ensembl/vep --VERSION 83 --AUTO acfp --SPECIES homo_sapiens_merged --ASSEMBLY GRCh38 --PLUGINS all<br>
```<br>
<br>
Cheers,<br>
<br>
Josh.<br>
<br>
<br>
<br>
_______________________________________________<br>
Dev mailing list    <a href="mailto:Dev@ensembl.org">Dev@ensembl.org</a><br>
Posting guidelines and subscribe/unsubscribe info: <a href="http://lists.ensembl.org/mailman/listinfo/dev" rel="noreferrer" target="_blank">http://lists.ensembl.org/mailman/listinfo/dev</a><br>
Ensembl Blog: <a href="http://www.ensembl.info/" rel="noreferrer" target="_blank">http://www.ensembl.info/</a><br>
</blockquote></div><br></div>