a-ludi/dentist

Rule `ref_vs_reads_alignment_block` keeps failing

a-ludi opened this issue · 7 comments

I'd like this ticket to be reopened, please. The error is still there with Dentist 1.0.1

Error in rule ref_vs_reads_alignment_block:
    jobid: 977
    output: workdir/scaffolds_FINAL.non-hifi.1kb.128.las, workdir/non-hifi.1kb.128.scaffolds_FINAL.las
    log: logs/ref-vs-reads-alignment.128.log (check log file(s) for error message)
    shell:
        
            {
                cd workdir
                damapper -C '-T8' -e0.7 -mdust -mdentist-self -mtan scaffolds_FINAL non-hifi.1kb.128
                LAcheck -v scaffolds_FINAL non-hifi.1kb scaffolds_FINAL.non-hifi.1kb.128.las || { echo 'Check failed. Possible solutions:

Duplicate LAs: can be fixed by LAsort from 2020-03-22 or later.

In order to ignore checks entirely you may use the environment variable SKIP_LACHECK=1. Use only if you are positive the files are in fact OK!'; (( ${SKIP_LACHECK:-0} != 0 )); }
                LAcheck -v non-hifi.1kb scaffolds_FINAL non-hifi.1kb.128.scaffolds_FINAL.las || { echo 'Check failed. Possible solutions:

Duplicate LAs: can be fixed by LAsort from 2020-03-22 or later.

In order to ignore checks entirely you may use the environment variable SKIP_LACHECK=1. Use only if you are positive the files are in fact OK!'; (( ${SKIP_LACHECK:-0} != 0 )); }
            } &> logs/ref-vs-reads-alignment.128.log
        
        (one of the commands exited with non-zero exit code; note that snakemake uses bash strict mode!)
    cluster_jobid: 208494 logs/cluster/ref_vs_reads_alignment_block/block_reads=128/jobid977_e17a6776-b2a4-4570-aba0-d97bd422ba29.out

Error executing rule ref_vs_reads_alignment_block on cluster (jobid: 977, external: 208494 logs/cluster/ref_vs_reads_alignment_block/block_reads=128/jobid977_e17a6776-b2a4-4570-aba0-d97bd422ba29.out, jobscript: /lustre/scratch116/tol/teams/team308/users/mm49/tmp/non-hifi-reads2/.snakemake/tmp.4pilq3ef/snakejob.ref_vs_reads_alignment_block.977.sh). For error details see the cluster log and the log files of the involved rule(s).

Snakemake retries the jobs a few times, but they keep on failing for the same reason, and at some point snakemake gives up and quits.

The image is v1.0.1:

$ singularity inspect dentist_v1.0.1.sif 
org.label-schema.build-arch: amd64
org.label-schema.build-date: Thursday_22_April_2021_11:19:9_UTC
org.label-schema.schema-version: 1.0
org.label-schema.usage.singularity.deffile.bootstrap: docker
org.label-schema.usage.singularity.deffile.from: aludi/dentist:v1.0.1
org.label-schema.usage.singularity.version: 3.7.2

Originally posted by @muffato in #15 (comment)

@muffato Could you please inspect the contents of logs/ref-vs-reads-alignment.128.log? The real error message must be in there.

It's the same error: duplicate LAs

$ cat logs/ref-vs-reads-alignment.128.log
  scaffolds_FINAL.non-hifi.1kb.128: Duplicate LAs (14 vs 458088)
  scaffolds_FINAL.non-hifi.1kb.128: Not OK, see stderr
Check failed. Possible solutions:

Duplicate LAs: can be fixed by LAsort from 2020-03-22 or later.

In order to ignore checks entirely you may use the environment variable SKIP_LACHECK=1. Use only if you are positive the files are in fact OK!

This is a bug in damapper. Please just run Snakemake with SKIP_LACHEK=1:

SKIP_LACHEK=1 snakemake --configile=snakemake.yml ...

More details on this issue can be found in issue #14. I fixed this annoying issue in the develop branch at a97193c. The changes are not yet validated, so there may occur some other errors if you try the new Snakefile.

Not 100% sure, but it looks like it may need env, e.g.

env SKIP_LACHEK=1 snakemake --configile=snakemake.yml ...

I'll confirm once the other error (#17) is fixed and I can get a clean run

Using env is usually not required but may help in some cases. I deduce from #17 that this issue is fixed so I close this.

Dear Arne, any news on this? (muffato and I work in the same project at the Sanger). Thank you!

Dear Marcela, I guess you are refering to issue #17? I do not have any news on that, sorry.

I am working on a new release, though. So maybe that will change things. I will also take another look at the data muffato provided.

Cheers, Arne