--init M9 yields no output SOMETIMES about carveme

[cdanielmachado]

Hi Ricardo,

Can you share the .fna file for one of the 13 models that failed? I will try to debug and see what is going on.

[rdmtinez]

Hi Daniel, after a bit more digging it seems that the problem is not with CARVE alone, but somehow there is miscommunication between LSF and carve when the jobs are being processed. There must be an underlying reason for the strange behavior given that it is always the same 13 files that do not finish processing (along with the other 33 other 'small' fna files) when submitted to our 'superheavy' queue (the only queue that isn't terminated automatically when running carve -r...).

I ran the 13 files through a for loop instead, and the output was created this time using --init M9. I'm going to do the same for the other 33 small fna and see if anything changes first. I'll let you know how that goes, but I'm beginning to think it's just our cluster though not playing nice :-/

[cdanielmachado]

In our cluster, I realized that using job arrays is more convenient than using the "-r" option. I think LSF also supports job arrays. Basically, you submit your script as a job array (one reconstruction per job, using the job array index to select the genome file), and the cluster does all the work of managing the parallel processes (instead of that work being done by the python multiprocessing library when you use the "-r" option).

[rdmtinez]

I will keep that in mind for the next reconstructions, Thanks!