CUTADAPT is only using 1 core?

[wolfgangrumpf]

Started running a job through metawrap today; I noticed that I'm only running one instance of cutadapt and it's at 100%, despite having 48 cores available. The log is currently at:

Now performing quality (cutoff 20) and adapter trimming in a single pass for the adapter sequence: 'TGGAATTCTCGG' from file RAW_READS/sample1_1.fastq <<<
10000000 sequences processed
20000000 sequences processed
30000000 sequences processed

Is cutadapt able to run on multiple threads?

UPDATE: moved on to bmfilter and it ALSO is using only one core....

[ursky]

Unfortunately, TrimGalore (the program calling Cutadapt) does not support multi-threading: FelixKrueger/TrimGalore#16. I still prefer to use TrimGalore because of their automatic adapter search. Bmtagger also does not support multi-threading, not sure why. They are also the best option for the job.

The rationale many of these programs not supporting multi-threading is that most people process many samples with one core each as opposed to one very big sample. Still annoying, however.

[wolfgangrumpf]

Ahhh, okay. I agree - annoying. But it's what it is....thanks for the quick reply!

[wolfgangrumpf]

A thought - in that thread you reference, the developer talks about spawning multiple jobs, one per sample. Could metawrap do the same thing? E.g. if I have 2 samples (really 4, 2 forward and 2 reverse), couldn't we at least run 4 threads to make things a bit faster?

[ursky]

I see what you are saying, but I feel like its much easier handled on the user's side of things. I added a section in the example instructions on how to quickly launch metawrap in parallel.

[wolfgangrumpf]

Ahhh, right. I could spawn multiple READ_SEQ jobs and fire off ASSEMBLY once they're all done. Makes sense. :)