Casava 1.7 demultiplex.pl slowness

[FredG]

Hi,

We notided that the Casava 1.7 demultiplex.pl software take 3 days to demultiplex a paired-end run (2x51) where only 3 lanes was indexed. He spent two days on not indexed lanes (so, normally, just to rename the read3 to read2 I think ?) (config : Linux/Red Hat Sun Fire X4140 server with 2 CPU AMD Opteron 2384 quadri-core, RAM 64 GB ... parallelization 'make -8' used).

Apparently, there is a problem with the "demultiplexTile" program , which apparently spent 50% of its CPU time to do the system command "stat" :

stat("./001/s_7_1_0041_qval.txt.gz.tmp", 0x7fff85fea4e0) = -1 ENOENT (No such file or directory)
stat("/env/export/nfs9/solexa/TRANSFERT/110406_MERCURE_B01LEABXX/Data/Intensities/BaseCalls/s_7_1_0041_qval.txt.gz", 0x7fff85fea6e0) = -1 ENOENT (No such file or directory)
stat("/env/export/nfs9/solexa/TRANSFERT/110406_MERCURE_B01LEABXX/Data/Intensities/BaseCalls/s_7_2_0041_qval.txt.gz",0x7fff85fea6e0) = -1 ENOENT (No such file or directory)

Illumina's tech support solved my problem with an incremental version of this software include in the CASAVA-1.7.1a5 package.

This version is actually much more efficient : 2 hours instead of 3 days

I don't know if I am an isolated case ... maybe this will help some of you

bye

[lletourn]

I solved that problem in january after 2 weeks of thinking our nfs server was collapsing. One email to tech support fixed it.

I would have liked for them to acknowledge the problem and notify their clients about it. Oh well, Casava 1.8 is out now, so back to the drawing board.