Hello, I am trying to run the 1.3.0 metaTdenovo pipeline on 3 eukaryotic metatranscriptomic samples, using megahit assembler and transdecoder ORF caller. Everything went quite smoothly until the functionnal annotation step. The pipeline stops while trying to do the Kofamscan annotation, with the following error message.

ERROR ~ Error executing process > 'NFCORE_METATDENOVO:METATDENOVO:KOFAMSCAN:KOFAMSCAN_SCAN (megahit.transdecoder)'

Caused by:
  Process `NFCORE_METATDENOVO:METATDENOVO:KOFAMSCAN:KOFAMSCAN_SCAN (megahit.transdecoder)` terminated with an error exit status (1)


Command executed:

  exec_annotation \
      --profile profiles \
      --ko-list ko_list \
      --format detail-tsv \
      --cpu 24 \
      megahit_assembly.contigs.fa.transdecoder.pep \
      -o kofamscan_output.tsv

  # Create a cleaned up version for summary_tables
  echo "orfguerikometaT_thrshld0scoreestevaluesiko_definition" | gzip -c > kofamscan.tsv.gz
  grep -v '#' kofamscan_output.tsv | cut -f 2-7|sed 's/ "/      /' | sed 's/"$//' | gzip -c >> kofamscan.tsv.gz

  # Gzip the original file
  gzip kofamscan_output.tsv

  cat <<-END_VERSIONS > versions.yml
  "NFCORE_METATDENOVO:METATDENOVO:KOFAMSCAN:KOFAMSCAN_SCAN":
      kofamscan: $(echo $(exec_annotation --version 2>&1) | sed 's/^.*exec_annotation//' )
  END_VERSIONS

Command exit status:
  1

Command output:
  (empty)

Command error:
  INFO:    Environment variable SINGULARITYENV_TMPDIR is set, but APPTAINERENV_TMPDIR is preferred
  INFO:    Environment variable SINGULARITYENV_NXF_TASK_WORKDIR is set, but APPTAINERENV_NXF_TASK_WORKDIR is preferred
  INFO:    Environment variable SINGULARITYENV_NXF_DEBUG is set, but APPTAINERENV_NXF_DEBUG is preferred
  /usr/local/bin/lib/kofam_scan/parallel.rb:28:in `write': Broken pipe (Errno::EPIPE)
        from /usr/local/bin/lib/kofam_scan/parallel.rb:28:in `puts'
        from /usr/local/bin/lib/kofam_scan/parallel.rb:28:in `block in exec'
        from /usr/local/lib/ruby/2.7.0/open3.rb:219:in `popen_run'
        from /usr/local/lib/ruby/2.7.0/open3.rb:101:in `popen3'
        from /usr/local/bin/lib/kofam_scan/parallel.rb:27:in `exec'
        from /usr/local/bin/lib/kofam_scan/executor.rb:107:in `run_hmmsearch'
        from /usr/local/bin/lib/kofam_scan/executor.rb:35:in `execute'
        from /usr/local/bin/lib/kofam_scan/executor.rb:8:in `execute'
        from /usr/local/bin/lib/kofam_scan/cli.rb:21:in `run'
        from /usr/local/bin/exec_annotation:7:in `<main>'

Work dir:
  /scratch/guerin/metaT_vigo/210526_test/work/0b/c22502a2b90c1bd4429fcc7936e5b5

Container:
  /scratch/guerin/metaT_vigo/210526_test/work/singularity/depot.galaxyproject.org-singularity-kofamscan-1.3.0--hdfd78af_2.img

Tip: you can replicate the issue by changing to the process work dir and entering the command `bash .command.run`

 -- Check '.nextflow.log' file for details

I have seen that people had similar problems in the past. I tried to change the

versions.yml

file, that looked like this:

"NFCORE_METATDENOVO:METATDENOVO:KOFAMSCAN:KOFAMSCAN_DOWNLOAD":
    wget: 1.21.4

to make it look like this, as it was recommended on one of the previous threads:

"NFCORE_METATDENOVO:METATDENOVO:KOFAMSCAN:KOFAMSCAN_SCAN":
    kofamscan:  1.3.0

But I got the same error message. I tried to manually download KofamScan DB like described on the usage page of the pipeline and adding a

versions.yml

file, but got the same error again. I wonder if it could be linked to this reported bug? https://github.com/nf-core/metatdenovo/issues/365 I am getting stop on this issue, I re launched my test while skipping kofam annotation and it is running, but I would like to have it implemented at the end. Do you have any idea on what I could try to overcome this issue? Did some of you have met the same issue ? Thank you in advance for your help, Best regards, Nina Guerin

The problem with

versions.yml

is that if you download the database manually, you also need to make sure it exists and has certain content. In the next release, which I'll start on next week, this problem should disappear. Your current problem has nothing to do with this since the scan starts which it does when the download is done.

Hello Daniel, Thank you for your answer. I added a versions.yml when I manually downloaded the database, I tried with the 2 format I gave in my previous message and both failed.

Yes, he had problems that seemed to be related to the hardware he had that we never ironed out. In that case, running the pipeline with

--skip_kofamscan

and postprocessing the output would be an option.

Yes, I did run the pipeline by skipping kofamscan and it worked

You should let Nextflow schedule jobs using the

slurm

executor, see: https://docs.seqera.io/nextflow/executor#slurm. This will use resources better and allows better parallelization. Typically, you run Nextflow on the login/head node and then let it schedule the jobs one by one.

Surprisingly, I still get a legit counts.tsv and emapper.tsv files at the end of the pipeline, despite BBMAP_INDEX and EGGNOG_MAPPER failing...

The mapping and eggnog-mapper failures and correct tables is very surprising...

I looked at the logs more in details, apparently each steps failed a first time and then was tried a second time and worked. In the report, the tasks appear as failed but looking more in details, there is for each a failed version and a succeed version, so at the end it worked out

Yes, some processes are retried with more resources after they fail. If you run Nextflow like I describe above, i.e. interactively, you see this happening.

ok this is clearer now ! thank you