-
Notifications
You must be signed in to change notification settings - Fork 54
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Indexing tools unable to handle large MAF files #8
Comments
I think pushing the version is the right solution. Somebody just needs to -- jt On Fri, Jul 29, 2016 at 12:41 PM, Daniel Blankenberg <
|
Thanks for looking into this. |
Any progress on this? (base) /mnt/e/genemod/better_dNdS_models/drosophila/11_6_2020/cactus_work$ python /home/jodyhey/miniconda3/bin/maf_build_index.py drosophila_cactus.maf drosophila_cactus.mafindex Traceback (most recent call last): |
@jodyhey No one is working on this issue, sorry, but pull requests are welcome! |
Is there any update on this issue? with how .maf files have gotten bigger lately, this might become a more common issue. here I ran the script on a 30 Gb .lzo file (85 Gb uncompressed)
|
One example is the hg38 projected chr1 multiz100way from UCSC: http://hgdownload.soe.ucsc.edu/goldenPath/hg38/multiz100way/maf/chr1.maf.gz (5.9G gz'd, 66G gunzip'd)
One possibility is to up the version number and store unsigned integers as unsigned long long
>Q
, which would max out at 18446744073709551615 vs 4294967295. Would double the packed size though.Another potential workaround could be to break the MAF up into multiple files, but I haven't tested this.
xref: https://biostar.usegalaxy.org/p/18196/
The text was updated successfully, but these errors were encountered: