On Montag 15 Juni 2009 Kenta SHIRASAWA wrote: > 1) > We will use a mira_out.txt output for a further analysis. We are > happy if MIRA makes a result txt file one by one contig, or adds a > created contig to a result txt file, because we can check a part of > results without waiting for finishing whole assemblings. Well, MIRA has no other possibility ... to save memory, contig structures get freed and re-allocated once a contig has been finnished. The update of the files on the fly is merely a (very welcome) side effect :-) > 2) > Can you estimate how long time does MIRA take for finishing an > assemble 500,000 454-reads (ca. 200 Mb) with the options "-fasta > -job=denovo,est,draft,454 -notraceinfo -SB:lsd=yes -SK:pr=95 -SK:mnr=yes > -OUT:ort=yes"? > Our machine (64bit linux, 2 GHz CPU, 128 GB memory) has been running > for more than a week. Something's wrong there, plain wrong. May I ask you to send me the output log of the assembly to have a look at? > 3) > Please tell us a difference between conting headers, e.g., mira_c# > and mira_lrc#. I really need to document that: it's a remainder of larger changes that are currently made in the algorithms, it was introduced more for debugging purposes but a few users thought it could help them so I left it in. Basically, MIRA starts to build contigs in areas that are "rock solid", i.e., not a repetitive region (main decision point) and nice coverage of good reads. If during the assembly MIRA reaches a point where it cannot start building a contig in a non-repetitive region, it will name the contig "lrc" instead of "c". Of course, this naming convention is a bit weird (not to say: useless) when having to assemble ESTs, but at the moment I didn't build in code that switches of contig naming in these cases. Regards, Bastien -- You have received this mail because you are subscribed to the mira_talk mailing list. For information on how to subscribe or unsubscribe, please visit http://www.chevreux.org/mira_mailinglists.html