I received an answer to the topic on SeqAnswers. I'll paste it here just in case someone is interested.

Devon Ryan:

"Since tophat isn't written to use MPI, the instances run on each node will be blind to each other. There is no way around this without rewriting the program (actually, you'd need to rewrite bowtie as well). If you really want to use tophat, then just split your fastq files into small enough versions and then push a large number of tophat jobs onto the cluster (normally one would create a script to do this). If you're going that route anyway, just switch to STAR (you might have enough RAM, I'm not sure) and you'll get your results in a fraction of the time. The last alternative here would by Myrna, which seems to be designed with this sort of scenario in mind.

You'll have the same problems with cufflinks, namely that increasing the number of instances with MPI won't decrease runtime since the instances won't talk to each other. Your best bet there would be eXpress or to just use count-based methods. "

I received an answer to the topic on SeqAnswers. I'll paste it here just in case someone is interested.

Devon Ryan:

"Since tophat isn't written to use MPI, the instances run on each node will be blind to each other. There is no way around this without rewriting the program (actually, you'd need to rewrite bowtie as well). If you really want to use tophat, then just split your fastq files into small enough versions and then push a large number of tophat jobs onto the cluster (normally one would create a script to do this). If you're going that route anyway, just switch to STAR (you might have enough RAM, I'm not sure) and you'll get your results in a fraction of the time. The last alternative here would by Myrna, which seems to be designed with this sort of scenario in mind.

You'll have the same problems with cufflinks, namely that increasing the number of instances with MPI won't decrease runtime since the instances won't talk to each other. Your best bet there would be eXpress or to just use count-based methods. "

Under the circumstances, is there any reason you cannot contact the sysadmin for the cluster and simple ask to have the walltime increased? Or find out if you can do it yourself for your own userid jobs with the qalter command?

If that cluster is being used for various NGS analyses, then a hard default walltime of only 6hours seems a bit ridiculous. The whole point of multicore large memory nodes is that they can each run a large, non-parralelizable process.

My little 4-node LifeScope cluster has 8-cores and 24GB RAM per node, and I have the default walltime set to 96 hours (some specific process will amend that when they launch, based on past experience, but the default is set high for single long running processes).

Hello Michael,

Thank you for your quick reply.

This particular cluster was not meant originally for NGS analysis, but it is being used by others for molecular dynamics computations and other industrial projects. I was allowed to use it and had tuxedo suite installed.

In fact, I can send jobs to an other queue where i can ask for 24h walltime which is the maximum allowed, but couldn't get to the end of tophat run on a single node and the process was killed after that time. (I might contact sysadmins but I don't think they will give me more then 24h at this time)

As for tophat, a temporary solution would be splitting fastq files and then running separate jobs and merging the results together.

What about cufflinks? What happens if I split the bam files by chromosome? And then run 23 cufflinks jobs? Will I face serious problems in the quantification of the isoforms/normalization?

Thank you,

Marco

Hi Marco,

I have tested TopHat2 using several parameter and tried to find out the fastest solution for us. However, we had not the problem with the time on the cluster, because it was ours :) What we find out is that it doesn't matter how many threads you give TopHat2. Everthing over 8 threads is just producing CPU-Time, while the walltime is nearly the same!! There are also many computing peaks but also times where nearly nothing happens than writing and reading, that was quiet strange compared to other mapping tools. So in your case split your dataset or try another splice mapper!!!

Thank you Stefan for you answer,

At the end, I realized I had enough RAM per node and thus decided to switch to STAR instead of Tophat2. It took less than 30 mins to map all the paired-end reads to the genome! Impressing!

Hi Marco, InSilico DB has multiple nodes cluster and we have pre-processed many of the public RNA-Seq datasets in SRA. They are all available for download, as a cummeRbund object, and export to Ingenuity iReport.

The parameters we used for Tophat, cuflinks, and cuffdiff are available by selecting the "visualization pipeline".

Hope this helps.

About Star and Tophat2, I believe Tophat2+cufflinks is the best current choice to find unknown transcripts. If you are only interested in known transcripts you might want to have a look at sailfish and eXpress which I heard are very fast.

Ressources:

InSilicoDB: https//insilicodb.com

SailFish: http://www.cs.cmu.edu/~ckingsf/software/sailfish/

eXpress: http://bio.math.berkeley.edu/eXpress/overview.html

Hope this helps, Alain