Closed MonsterLaplace closed 7 months ago
/mnt/z/miniconda3/envs/gap/bin/tgsgapcloser: line 645: 3044102 Aborted (core dumped) $GapCloser --ont_reads_a $FINAL_READS --contig2ont_paf $OUT_PREFIX.fill.paf --min_match=$MIN_MATCH --min_idy=$MIN_IDY --prefix $OUT_PREFIX > $OUT_PREFIX.fill.log 2>&1 My paf file is 10.9GB, and I have 2TB RAM to run. The end of the XXX.fill.log is: TGSGapCloser INFO CST 2023/12/17 20:59:6 : LoadPAF finish. used wall clock : 207 seconds, cpu time : 202.893051 seconds TGSGapCloser INFO CST 2023/12/17 20:59:6 : LoadScaffInfo start now ... TGSGapCloser INFO CST 2023/12/17 20:59:6 : LoadScaffInfo finish. used wall clock : 0 seconds, cpu time : 0.000276 seconds TGSGapCloser INFO CST 2023/12/17 20:59:6 : ParseAllGap start now ... terminate called after throwing an instance of 'std::bad_alloc' what(): std::bad_alloc Is their any suggesting to sovle this problem?
Hello, I'm having the same problem, have you solved it yet?
"what(): std::bad_alloc" normally refers to the memory allocation issue. It could be insufficient memory, physical address mismatch, or other problems. I cannot provide more details unless debug this process step by step.
But this is a known memory issue for the current form of TGS-GapCloser that has been reported frequently. This huge memory consumption comes from the large data size of input long reads. As it was originally designed for low depths, the algorithm cannot handle deep depths for long-read alignment.
You can try TGS-GapCloser2 (https://github.com/BGI-Qingdao/TGS-GapCloser2). The usage is the same as that of TGSGapCloser, and can dramatically reduce the memory. But note that it has not been fully tested.
Thanks, Mengyang
/mnt/z/miniconda3/envs/gap/bin/tgsgapcloser: line 645: 3044102 Aborted (core dumped) $GapCloser --ont_reads_a $FINAL_READS --contig2ont_paf $OUT_PREFIX.fill.paf --min_match=$MIN_MATCH --min_idy=$MIN_IDY --prefix $OUT_PREFIX > $OUT_PREFIX.fill.log 2>&1 My paf file is 10.9GB, and I have 2TB RAM to run. The end of the XXX.fill.log is: TGSGapCloser INFO CST 2023/12/17 20:59:6 : LoadPAF finish. used wall clock : 207 seconds, cpu time : 202.893051 seconds TGSGapCloser INFO CST 2023/12/17 20:59:6 : LoadScaffInfo start now ... TGSGapCloser INFO CST 2023/12/17 20:59:6 : LoadScaffInfo finish. used wall clock : 0 seconds, cpu time : 0.000276 seconds TGSGapCloser INFO CST 2023/12/17 20:59:6 : ParseAllGap start now ... terminate called after throwing an instance of 'std::bad_alloc' what(): std::bad_alloc Is their any suggesting to sovle this problem?
Hello, I'm having the same problem, have you solved it yet?
Sorry for late response. Unfortunately, I haven’t solved this memory problem until now. However, I can share another suggestion for you. I think the large size of assemble file (in my case, 5G primary assembled contigs file generated by verkko) may be the problem which was used for gap filling. When I split the contigs file into two parts (hap1 and hap2) and used them to fill the gap, respectively, this error was no longer happen and everything was fine.
Thank you for your reply, very happy for you, congratulations on finding a solution, then I'll try it with your method first and get back to you on the follow up
------------------ 原始邮件 ------------------ 发件人: "BGI-Qingdao/TGS-GapCloser" @.>; 发送时间: 2024年3月13日(星期三) 下午4:03 @.>; @.**@.>; 主题: Re: [BGI-Qingdao/TGS-GapCloser] tgsgapcloser: line 645: 3044102 Aborted (core dumped) (Issue #73)
/mnt/z/miniconda3/envs/gap/bin/tgsgapcloser: line 645: 3044102 Aborted (core dumped) $GapCloser --ont_reads_a $FINAL_READS --contig2ont_paf $OUT_PREFIX.fill.paf --min_match=$MIN_MATCH --min_idy=$MIN_IDY --prefix $OUT_PREFIX > $OUT_PREFIX.fill.log 2>&1 My paf file is 10.9GB, and I have 2TB RAM to run. The end of the XXX.fill.log is: TGSGapCloser INFO CST 2023/12/17 20:59:6 : LoadPAF finish. used wall clock : 207 seconds, cpu time : 202.893051 seconds TGSGapCloser INFO CST 2023/12/17 20:59:6 : LoadScaffInfo start now ... TGSGapCloser INFO CST 2023/12/17 20:59:6 : LoadScaffInfo finish. used wall clock : 0 seconds, cpu time : 0.000276 seconds TGSGapCloser INFO CST 2023/12/17 20:59:6 : ParseAllGap start now ... terminate called after throwing an instance of 'std::bad_alloc' what(): std::bad_alloc Is their any suggesting to sovle this problem?
Hello, I'm having the same problem, have you solved it yet?
Sorry for late response. Unfortunately, I haven’t solved this memory problem until now. However, I can share another suggestion for you. I think the large size of assemble file (in my case, 5G primary assembled contigs file generated by verkko) may be the problem which was used for gap filling. When I split the contigs file into two parts (hap1 and hap2) and used them to fill the gap, respectively, this error was no longer happen and everything was fine.
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.***>
/mnt/z/miniconda3/envs/gap/bin/tgsgapcloser: line 645: 3044102 Aborted (core dumped) $GapCloser --ont_reads_a $FINAL_READS --contig2ont_paf $OUT_PREFIX.fill.paf --min_match=$MIN_MATCH --min_idy=$MIN_IDY --prefix $OUT_PREFIX > $OUT_PREFIX.fill.log 2>&1 My paf file is 10.9GB, and I have 2TB RAM to run. The end of the XXX.fill.log is: TGSGapCloser INFO CST 2023/12/17 20:59:6 : LoadPAF finish. used wall clock : 207 seconds, cpu time : 202.893051 seconds TGSGapCloser INFO CST 2023/12/17 20:59:6 : LoadScaffInfo start now ... TGSGapCloser INFO CST 2023/12/17 20:59:6 : LoadScaffInfo finish. used wall clock : 0 seconds, cpu time : 0.000276 seconds TGSGapCloser INFO CST 2023/12/17 20:59:6 : ParseAllGap start now ... terminate called after throwing an instance of 'std::bad_alloc' what(): std::bad_alloc Is their any suggesting to sovle this problem?