Hello everyone,

I've been encountering an issue with my Snakemake workflow when running it on our computing cluster. Specifically, I'm facing challenges with resource allocation for the MarkDuplicatesSpark rule. Let me provide some context and details:

1. GATK Version and Command: I'm using GATK version 4.5.0 and have a Snakemake rule (mark_duplicates) that runs the MarkDuplicatesSpark tool to mark duplicate reads in BAM files.

2. Rule Configuration: Here's a snippet of the rule configuration:

   rule mark_duplicates:
       input:
           bam_processed="results/{sample}/{sample}.aligned_fixmates_sorted.bam",
           temp_dir = "pwd",
           bam_index="results/{sample}/{sample}.aligned_fixmates_sorted.bam.bai"
       output:
           bam_dedup="results/{sample}/{sample}.aligned_dedup.bam",
           dedup_metrics="results/{sample}/{sample}.dedupmetrics.txt"
       threads:8
       conda:
           "envs/gatk.yaml"
       shell:
           """
           gatk MarkDuplicatesSpark -I {input.bam_processed} \
           -O {output.bam_dedup} \
           --metrics-file {output.dedup_metrics} \
           --QUIET --tmp-dir {input.temp_dir} \
           --conf 'spark.executor.cores=6' \
           --conf 'spark.executor.memory=8g' \
           --conf 'spark.driver.memory=4g' \
           --conf 'spark.driver.cores=1' \
           --conf 'spark.task.cpus=1' \
           --conf 'spark.dynamicAllocation.enabled=false' \
           --conf 'spark.local.dir="pwd"'\
           --spark-master local[8]
           """
   
   

    

   Snakemake Command: Here's the Snakemake command I'm using to execute the workflow on our cluster:

   snakemake -s workflow/Snakefile --sdm conda --cores 8 --jobs 22 --latency-wait 100 --rerun-triggers mtime \
   --executor cluster-generic --cluster-generic-submit-cmd "qsub -P project -pe omp {threads} -l mem_per_core=8G -cwd -j y -N varcallpipeline" \
   --directory "pwd"

    

   Problem: Despite requesting only 8 cores (--cores 8) in the Snakemake command and specifying 8 cores in the rule (threads: 8), the MarkDuplicatesSpark tool sometimes utilizes 9 or 10 cores, causing the job to be shut down by the cluster due to resource overconsumption.

    

   Any insights or suggestions on how to address this issue would be greatly appreciated!

   Thank you.