null value in mutect2 subworkflow

[maxulysse]

Description of the bug

A USER ERROR has occurred: Bad input: Sample E14_null is not in BAM header: [E14_E14_1_BM_T, E14_E14_2_BM_T, E14_E14_3_LN_T, E14_E14_N]

gatk --java-options "-Xmx29491M -XX:-UsePerfData" \ Mutect2 \ --input E14_2_BM_T.converted.cram --input E14_N.converted.cram --input E14_3_LN_T.converted.cram --input E14_1_BM_T.converted.cram \ --output E14.mutect2.vcf.gz \ --reference human_g1k_v37_decoy.fasta \ --panel-of-normals pon.vcf.gz \ --germline-resource af-only-gnomad.raw.sites.vcf.gz \ --intervals 1_65565-65573.bed \ --tmp-dir . \ --f1r2-tar-gz E14.mutect2.f1r2.tar.gz --normal-sample E14_null

I am also hitting this error with version 3.3.2. The weird thing is that some MUTECT2_PAIRED jobs finish successfully while others fail due to null normal_id . I checked the contents of the input_intervals in the somatic_mutect2 subworkflow and the normal_id meta values are set as they are supposed to. Very confusing...

Command used and terminal output

No response

Relevant files

No response

System information

No response

[berguner]

It looks like this happens when --joint_mutect2 is set to true because the normal_id is removed prematurely in these lines:

sarek/subworkflows/local/bam_variant_calling_somatic_mutect2/main.nf

Lines 42 to 49 in f034b73

	if (joint_mutect2) {
	// Separate normal cram files
	// Extract tumor cram files
	ch_cram = input.multiMap{ meta, cram, crai ->
	normal: [ meta - meta.subMap('normal_id', 'tumor_id') , cram[0], crai[0] ]
	tumor: [ meta - meta.subMap('normal_id', 'tumor_id') , cram[1], crai[1] ]
	}

@FriederikeHanssen do you remember why you removed the normal_id prior to running Mutect2?

[FriederikeHanssen]

probably for grouping reasons. I tried to be as conservative as possible in the end with removing stuff, looks like it wasn't good enough. I think I know how to fix it.

[asp8200]

I know we already have lots of tests, but would it perhaps make sense to add an extra test "covering" the error reported in this issue?

[FriederikeHanssen]

@asp8200 not really. We have to overwrite the normal id entry with a fixed value in the tests at the moment, so this won't bepicked up. Not overwriting it leads to other issues. Alternatively someone would need to sit down and regenerate a large chunk of the test data.

[berguner]

IIRC, we need to override the normal id because the sample names in the cram files (@sm tags) don't match the sample sheet. I considered updating them for Mutect2 tests but I wasn't sure how it would effect the other tests, so it still remains at the back of my mind...

[FriederikeHanssen]

right probably half of the checksums would be affected...

[FriederikeHanssen]

fixed in #1277