-
Notifications
You must be signed in to change notification settings - Fork 20
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
EPACTS tool support of GRCh38 #20
Comments
Can you try using the |
What I found in the code from EPACTS/scripts/epacts.pm file, you can see that the tool is hard-coded for GRCh37 - chromosome names and lengths that correspond to 37 reference, but not 38.
With that in mind, are you sure that giving -ref as GRCh38 would result in correct values? |
It probably hasn't made it to the master branch yet, but this was fixed with 60fe5db. I would recommend using the latest pre-release (https://github.com/statgen/EPACTS/releases). |
Hello, thank you for your response. With that in mind, and the parts of code that are hardcoded (like the different chromosome lengths that correspond to 37 reference that I mentioned above), how does this affect the outputs? Do you have any experience with this? |
Which analysis are you trying to run? Can you attach the entire log file? |
For now I am trying a test run for EPACTS Single Variant Test. |
I see. It's because you have the |
Thank you, this solves the problem of the gene anottation.
For this to be compatible for 38, do we need to change this, or is there a workaround? |
It doesn't. The |
Hello, thank you for all the help so far. |
You can find a build 38 map file at http://csg.sph.umich.edu/locuszoom/download/recomb-hg38.tar.gz |
Hello, I have files run on both GRCh37 and 38 reference and would like to use EPACTS tools to process them.
In the post on the EPACTS Google Group ( here ) the question of tool support for GRCh38 was asked and the answer was given to change the EPACTS/scripts/epacts.pm file.
But modifying the file by hard coding for one or the other is not something that is compatible with my implementation.
Is there another way to achieve compatibility for both references?
Thank you.
The text was updated successfully, but these errors were encountered: