cufflinks takes too long when multiple instances are run

[jwhite]

Has anyone else found that cufflinks run times are unacceptably large when multiple instances are run simultaneously? We are using an HPC cluster and running multiple jobs simultaneously. My cufflinks jobs are taking more than 3 days and not completing. Shouldn't cufflinks be done inside of a day?

Joe White

[Bukowski]

Cufflinks can get backed up in all kinds of places, so blaming the HPC architecture might be premature. Are they completing on their own in reasonable time frames on non-shared hardware?

What kind of volumes of data in terms of reads, samples, conditions are you talking about?

[jwhite]

Cufflinks can get backed up in all kinds of places, so blaming the HPC architecture might be premature. Are they completing on their own in reasonable time frames on non-shared hardware?

What kind of volumes of data in terms of reads, samples, conditions are you talking about?

As an example, here is the alignment summary for one of the samples:

Left reads:
Input : 129063888
Mapped : 72607783 (56.3% of input)
of these: 12721765 (17.5%) have multiple alignments (17373 have >20)
Right reads:
Input : 129063888
Mapped : 71558547 (55.4% of input)
of these: 12802384 (17.9%) have multiple alignments (17372 have >20)
55.9% overall read mapping rate.

Aligned pairs: 52240021
of these: 9310971 (17.8%) have multiple alignments
22683976 (43.4%) are discordant alignments
22.9% concordant pair alignment rate.


We haven't run them in other environments.

Joe White

[Bukowski]

Those metrics look... a bit off to me, I don't understand why your concordant pair alignment rate is so low, or why your mapping rate is so low. What organism are you working on? What QC are you doing prior to the run?