EichlerLab / smrtsv2

Structural variant caller
MIT License
53 stars 6 forks source link

Failed to assemble group(RuntimeError) #31

Closed jiey6596 closed 5 years ago

jiey6596 commented 5 years ago

my command is this"smrtsv run --batches 1 --threads 40 mm10.fa reads.fofn --min-coverage 10" but when it runs to assemble will report an error:RuntimeError in line 164 of /home/renchao/Packages/smrtsv2-master/rules/assemble.snakefile: Failed to assemble group gr-chr7-74000000-1000000: See log assemble/group/gr-chr7-74000000-1000000/contig_group.log File "/home/renchao/Packages/smrtsv2-master/rules/assemble.snakefile", line 164, in __rule_asm_assemble_group File "/public2/home/renchao/Packages/smrtsv2-master/dep/conda/build/envs/python3/lib/python3.6/concurrent/futures/thread.py", line 55, in run Exiting because a job execution failed. Look above for error message Shutting down, this might take some time. Exiting because a job execution failed. Look above for error message Complete log: /home/renchao/yuanjie/pacbio_20190125/SV/smrtsv2/.snakemake/log/2019-04-21T172410.920095.snakemake.log Failed to generate local assemblies it looks like a runtime limit,but when I changed --asm-rt to bigger(--asm-rt 1000), it didn't work. Could you please tell me how to solve this error or how to set --asm-rt ?

paudano commented 5 years ago

Assemblies are done in windows, and windows are grouped into 1 Mbp regions. Each assembly in the window has a default time limit of 30 min (--asm-rt). If an assembly fails, it goes on with the next one. This often happens in centromeres, where Canu can take an extremely long time to run. Not dropping those would stall assemblies, and the assemblies in these regions are often too noisy to be useful anyway.

Each group has a default runtime limit of 72 hours (--asm-group-rt), but that is only used if you are running the pipeline distributed on a cluster (it parses into cluster parameters).

You are not distributing this, so there should be no runtime limit for the whole group. Since the pipeline should continue if a single window fails, it should not be dying because of the window runtime limit. From this information, I don't yet see what runtime limit is causing the pipeline to die.

Can you share assemble/group/gr-chr7-74000000-1000000/contig_group.log? That probably has some important information in it.

jiey6596 commented 5 years ago

@paudano Attached changed log into an attachment:

Issue31_ErrorLog.gz

paudano commented 5 years ago

This is the same problem from issue #28. You'll need to cd into dep and rebuild (make clean then make). If the build process fails, then we can troubleshoot it from there.

It is finding a bamleftalign from your environment, not the one in dep/bin. The one in dep/bin is built against a C++ standard library that predates GLIBCXX_3.4.20 or GLIBCXX_3.4.21 (the conda GCC is older). Since the bamleftalign in your environment is requiring these ABI versions, it can't be the one in dep/bin. Something went wrong with the dependencies, or they were not built. Once it is built, SMTR-SV will find it's dependencies in dep/bin and dep/lib.

bamleftalign: /home/renchao/Packages/smrtsv2-master/dep/conda/build/envs/tools/bin/../lib/libstdc++.so.6: version `GLIBCXX_3.4.20' not found (required by bamleftalign)
bamleftalign: /home/renchao/Packages/smrtsv2-master/dep/conda/build/envs/tools/bin/../lib/libstdc++.so.6: version `CXXABI_1.3.9' not found (required by bamleftalign)
bamleftalign: /home/renchao/Packages/smrtsv2-master/dep/conda/build/envs/tools/bin/../lib/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by bamleftalign)

Try rebuilding dep and let me know if it works for you.

paudano commented 5 years ago

I am going to close this for now. If rebuilding dep does not solve the problem or if it fails, feel free to re-open.