-
Notifications
You must be signed in to change notification settings - Fork 10
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
std::bad_alloc in ataqv1.1.1 #10
Comments
Hi Sergey, Glad you all have found it useful. That command looks good to me so it's not immediately clear what the issue is. If you could send the bam file along with the TSS + autosomal reference files you've passed in the above command I'll see if I can identify the problem. Also -- based on the chromosome names in the peak file above, I'm guessing this is human data? If so, you shouldn't need to pass an autosomal reference file as long as you indicate it's human and the autosomes are either 1 - 22 or chr1 - chr22 (which, based on the peak file you've shared, they are). You will still need to indicate the mitochondrial reference name (as you've correctly done above), since the built-in human mitochondrial reference name is 'chrM'. |
Hi @porchard ! Thanks for the quick response! Here are the files to reproduce the issue: This is human data aligned to grch37.
it works fine not throwing bad_alloc for ataqv1.0.0 and for ataqv1.1.1. Sergey |
Hello, Just adding to this as we have gotten the same problem with the hg38-bwa-based atac-seq run. Here is the error file I have extracted. Do you need extra bamfiles and tss files for the error? Best, P.S. I'm sorry, should I add this as a new post? It seems this is appropriate as I have solved my problem at the moment with the same solution you have provided. |
This has an issue ParkerLab/ataqv#10 so we can skip it when we don't need it. Thanks to @yoonsquared for testing the fix.
Hi @porchard ! Sorry for bugging you again, we are hitting
I tried to submit it with 50G and 100G of RAM. Could you please help us debug? Sergey |
Hi Sergey (and Yoon), Sure, happy to have a look at this. Are you allowed to share the files used in that last command? I'll also set about a fix for the issue noted in the previous comments in this thread. |
Also -- can you share an autosomal reference file you were using? Looks like that Google Drive link above is dead. |
Hello, This is Joon.
I will be happy to send in the necessary files when our servers open up
after maintenance today.
How would you want me to share the narrowPeak file and the bam/bai files?
Also, we are not using a separate autosomal reference file, but we are
using the option:
--tss-extension 1000 mouse (similar to --tss-extension 1000 human,
which solved the problem last time)
Thanks!
Best,
Joon
…On Tue, Jul 7, 2020 at 8:06 AM porchard ***@***.***> wrote:
Also -- can you share an autosomal reference file you were using? Looks
like that Google Drive link above is dead.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#10 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AKE7ZAN4BI2VAYO7JGNWH3LR2MFVPANCNFSM4KCC23NA>
.
--
Joon Yoon
Post Doctoral Research Associate
Harvard T.H. Chan School of Public Health
Ph.D. in Bioinformatics (Seoul National University)
B.S. in Exercise Biology (U.C. Davis)
jyoon@hsph.harvard.edu // joonyoon.jay@gmail.com
617-777-4157
USA
|
Hi Joon, Google Drive/Dropbox/etc would be fine, if that works for you? Regarding the autosomal reference file: I was referring to the earlier comments in this thread. Sorry for the confusion. If you happen to have any of those lying around, I'd be curious to see them as well -- just wondering if the formatting for those might have been incorrect or something. |
Hi @porchard, These are the input files. I can't get the autosomal reference until tomorrow, but let me know if these files work for you. Best, |
Hi Joon, Thanks! Running your command, I do trigger a
I think the empty |
Hi @porchard, I give it a go after removing it, I will report if the run went through. For the same study, my run stopped with the same error for a different sample under bowtie also. I will check if it has the same issue with the empty ST tags. Thanks! Update: I saw the same empty ST: in the bowtie run of another sample. It gave a bad_alloc also. |
Hi @porchard, The run went through for that particular sample, but my run threw another bad:alloc in another sample with the same problem. Can you go ahead and push the issue? I'll try going through all the bam files to check all the samples with the same problem. Best, |
Hi Joon, Ok, give commit 1a2e8c5 a shot. Let me know how it goes. |
Thanks @porchard, It will take a bit to update the system and re-run, I will keep you posted. Best, |
Thanks, @porchard! The fix works. I've compiled it manually and patched our bcbio installation with
@yoonsquared is running the whole bcbio run to double-check the fix. Do you plan to release a new version? Sergey |
Hi @naumenko-sa and @yoonsquared, Excellent, thanks for letting me know. Yes, I'll see about getting a new release up |
Thanks for the prompt replies and solution! All the best, |
Hi @naumenko-sa and @yoonsquared, I've published a new release - thanks again for your help. |
Thanks! It is already in bioconda: |
Hello!
Thanks for the useful tool!
We are using ataqv in bcbio (https://github.com/bcbio/bcbio-nextgen)
In a project with many samples one sample failed ataqv step with std::bad_alloc.
I updated ataqv to the latest 1.1.1 (built it manually).
It allowed me to pass this sample, but it failed another one.
Call:
Output:
Could you please help to resolve?
I'm attaching the peak file.
S72941_2007_Naive-NF_peaks.narrowPeak.gz
I can also share a bam file if you need it.
Thanks!
Sergey
The text was updated successfully, but these errors were encountered: