GATK module failing in docker image

[aledj2]

Description of bug:

We are using docker images from dockerhub (docker pull ewels/multiqc:1.10.1) but the app is failing at the GATK module. We do not have any files for the GATK module

MultiQC Error log:

[INFO   ]         multiqc : This is MultiQC v1.10.1
[INFO   ]         multiqc : Template    : default
[INFO   ]         multiqc : Searching   : /usr/src/multiqc/multiqc
[INFO   ]         multiqc : Searching   : /home/dnanexus
[INFO   ]           peddy : Found 300 reports
[INFO   ]     verifybamid : Found 24 reports
[ERROR  ]         multiqc : Oops! The 'gatk' MultiQC module broke... 
  Please copy the following traceback and report it at https://github.com/ewels/MultiQC/issues 
  If possible, please include a log file that triggers the error - the last file found was:
    multiqc/modules/gatk/varianteval.py
============================================================
Module gatk raised an exception: Traceback (most recent call last):
  File "/usr/lib/python3.8/site-packages/multiqc/multiqc.py", line 594, in run
    output = mod()
  File "/usr/lib/python3.8/site-packages/multiqc/modules/gatk/gatk.py", line 42, in __init__
    n_reports_found += self.parse_gatk_varianteval()
  File "/usr/lib/python3.8/site-packages/multiqc/modules/gatk/varianteval.py", line 20, in parse_gatk_varianteval
    parsed_data = parse_single_report(f["f"])
  File "/usr/lib/python3.8/site-packages/multiqc/modules/gatk/varianteval.py", line 118, in parse_single_report
    d[headers[i]] = s
IndexError: list index out of range

File that triggers the error:
We do not have any output files from GATK

MultiQC run details (please complete the following):

• Command used to run MultiQC:
• docker run -v /home/dnanexus:/home/dnanexus ewels/multiqc:1.10.1 multiqc /home/dnanexus/ -n /home/dnanexus/out/multiqc/QC/multiqc/002_210407_A01229_0014_BH3GVTDRXY_NGS397E_WES68-multiqc.html -c /home/dnanexus/dnanexus_multiqc_config.yaml
• MultiQC Version: We have used docker pull ewels/multiqc:1.10.1 and docker pull ewels/multiqc:latest
• Operating System: Linux-5.4.0-1043-aws-x86_64-with-Ubuntu-16.04-xenial
• Python Version: docker
• Method of MultiQC installation: docker

[aledj2]

same issue with docker image v1.10 and v1.9
We are trying with -e gatk in the command line

[ewels]

Hi, this looks like you are telling MultiQC to search it's own installation directory. Please only provide paths to your data and that should solve the problem.

Phil

[ewels]

Yes - I think that it's because you don't need the multiqc command after the Docker image name. Let me know if this isn't the case and I'll try to replicate locally.

I do have some code that is meant to detect this and give a nicer error message, I guess I need to make it more lenient as it's not kicking in here..

[skchronicles]

@ewels

I see what is happening here. I am cc-ing @kopardev so he is aware of the issue/solution as well. I looked through a few similar issues in your Github repo to understand what you meant in your comment above:

MultiQC to search it's own installation directory

It looks like it is an issue related to the sandbox that Singularity is creating in the cache directory via the following environment variable:$SINGULARITY_CACHEDIR. I have set that variable to /path/to/mutliqc/output/directory/to/parse/.singularity. Depending on how singularity was installed on the target system or cluster, this can be an issue. I will not get into the fine details but I know that across the two clusters Singularity was installed differently, and this difference is leading to singularity to create the sandbox seen in the failed job. As you mentioned above, Singularity is parsing the sandbox directory.

I will tell MultiQC to ignore the .singularity directory so the error will not occur, and MultiQC will not parse itself. I am not sure if anyone else has run into this singularity sandbox issue, but it is good to be aware of it regardless. Please feel free to ignore my comment above.

[ewels]

Thanks for the detective work @skchronicles!

I'm hoping that we can get MultiQC itself to ignore these paths as they should be fairly recognisable most of the time. I've added a few things to the config to ignore in 4fabef9

Could you please give that a test and see if it solves the issue? Then hopefully no changes will be needed for your pipeline 🤞🏻

[skchronicles]

Hey @ewels,

Yes, that sounds good. I will test the changes on both clusters tomorrow, and I will let you know how it goes.

Thank you for implementing a patch so quickly!

[ewels]

Sounds good - I'll leave this issue open until then 👍🏻 Thanks!

[skchronicles]

It worked @ewels, and it is ignoring the singularity sandbox directory!

Thank you for taking the time to look into this issue. I appreciate it.

[ewels]

Brilliant! Thanks for letting me know 🙏🏻