Here, I trimmed the input 150x2 pe files "20-03_1_sequence.txt.gz" and "20-03_2_sequence.txt.gz" and outputted them as "20-03_F/R.fq.gz", when you can see incorporated into the bwa mem line just below. I fastQC-ed the before and after files, and the following processing steps after the "20-03_initial.bam" is made proceed as expected.

However, when I try this exact same script with another set of files, bwa simply exists after an hour or so.

These files are 50x2 pe and similarly successfully underwent fastQC. However, these two input files "1306_MKcombined_pair1/2.fastq.gz" are actually concatenated fastq files from 4 different sequencing lanes, combined into the final two pairs.

the script exits, after an hour or so (it seems random), I'm left with a .bam file about half the size it should be, and none of the processing steps after the bwa mem command occur.
Breaking up the alignment step into two steps (generating a .sam file, then samtools view to generate the .bam file) halts the script halfway through generating the .sam file.

Running the script directly from the command line gives the same result, an incomplete .bam/.sam file.

Sorry for such a long description, but would anyone know why this is occurring and why bwa is not giving me any indication of what is going wrong with the alignment?

EDIT: After some fiddling around, it seems that SLURM (to which I am submitting the command) was the culprit. There are different queues I can use to submit jobs and just changing that overcome the problem.

Agathe, did you try running it twice on the same queue? Some of the NBI nodes were behaving strangely recently and if the problem can be pin-pointed to a node, then CIS will be happy if you let them know which node it is.

Also, you may want to consider using samtools view -buSh, so it doesn't compress the .bam data before passing them to samtools sort.