Latest Release:9/18/18
Release Notes can be found here.

Mutect2 workflow bam out fails

Hi I've just run a clone of the Somatic-SNVs-Indels-GATK4 workspace, looking over the output of the WDL in the Monitor section Mutect2.sub_bamout_size has been flagged as failed with Started: reading Pending... the actual error appears to be message: Evaluating size(M2.output_bamOut, "GB") failed: Remote host closed connection during handshake. Is there a way of getting the bamOut working as obviously these files are very handy with respect to inspecting called variants. I understand M2 is sharded across multiple instances will the normal workflow collate the multiple bamOut outputs in to a per sample BAM?

Tagged:

Best Answer

Answers

  • KateNKateN Cambridge, MAMember, Broadie, Moderator

    Have you run this workflow again since receiving this error message? I believe that might be a temporary network error fixed by simply re-running. I will also double check with the author of that workflow to make sure he was able to run it with the bamOut, as well as get an answer to your question about collating the sharded bamOuts.

  • MattBMattB NewcastleMember

    Hi Kate, yes there was an alert which flashed up around about the time I submitted the jobs about FireCloud being slow. I'll try submitting the job again, I guess if there is not a gather step post the bamOut stage I'll simply end up with 50 or so bam files I can merge down the line.

  • MattBMattB NewcastleMember
    edited March 5

    So I re ran the analysis, this time it's run without error, however, in each of the sharded M2 output dirs: call-M2/shard-XX I find a bamout.bam file but it's zero in size, the logs appear to show the operation was successful:

    M2/shard-19/bamout.bam
    2018/02/22 14:42:46 I: Deleting log file
    2018/02/22 14:42:46 I: Running command: sudo rm -f /var/log/google-genomics/out.log
    2018/02/22 14:42:46 I: Switching to status: copied 1 file(s) to "<gs address>/Mutect2/8e9e9422-cb92-44ff-b911-b893b40420df/call-M2/shard-19/bamout.bam"
    2018/02/22 14:42:46 I: Calling SetOperationStatus(copied 1 file(s) to "<gs address>/Mutect2/8e9e9422-cb92-44ff-b911-b893b40420df/call-M2/shard-19/bamout.bam")
    2018/02/22 14:42:46 I: SetOperationStatus(copied 1 file(s) to "<gs address>/Mutect2/8e9e9422-cb92-44ff-b911-b893b40420df/call-M2/shard-19/bamout.bam") succeeded
    2018/02/22 14:42:46 I: Done copying files.
    

    Do I need to attache a specific size of storage bucket or something? I'm a bit stumped as to why this has not generated an error unless the bamout is genuinely zero in file size?

  • MattBMattB NewcastleMember
    edited March 6

    Hi Kate, ah yes, just checked I'd not set the make_bamout option to "True" have relaunched the analysis with this set! I guess I mistakenly assumed if the file exists then it must have been set to true by default, as with GATK3 command-line unless you specified -bamOut you would not get a bam file.

  • MattBMattB NewcastleMember

    Just to update this has now worked as expected with the merged bamOut present in thecall-MergeBamOuts directory.

  • KateNKateN Cambridge, MAMember, Broadie, Moderator

    Good to hear, I'm glad you got it working again.

Sign In or Register to comment.