If raw disk space usage is the concern something like this would save/compress the log file as it is created. mira-command *| tar -cvzf my-compressed-log-file.tar.gz* * * On Fri, Mar 2, 2012 at 3:36 PM, Bastien Chevreux <bach@xxxxxxxxxxxx> wrote: > On Mar 2, 2012, at 10:28 , Marcus Claesson wrote: > > I ran a Sourceforge binary of mira-3.4.0.1 with these parameters: > > I see your point. Short answer: no, there is currently no way to reduce > that output. Most of it is indeed pretty boring for users who just want > their stuff assembled, but in case there is a problem or some kind of > unexpected behaviour, it helps me to at least get an idea of what is going > on. This is somewhat vital for larger assemblies where I cannot ask people > to constantly rerun things for 2 weeks on their computers. > > I'm sorry, but for projects like yours, you will have to live with logs of > >= 1GiB. But then again, what's a GiB disk space anyway. > > In case you wonder: there is a way to make the log even more verbose, I'd > guess around 200 to 300x larger, but it involves recompiling and I do have > the feeling that this is quite opposite of what you wanted :-) > > > I had another case with an even bigger log file due to solexa file names > being too long. > > I now know how to avoid that using -MI:somrnl=0 but there was an error > message for every solexa read... > > Hrm ... I think that this could be remedied, perhaps have MIRA report just > the first 1000 names which are too long. Or something like that. Could ease > the pressure a bit. I'm puttinhg that on my TODO (but no promises). > > > I couldn't help but quickly scan through the rest of the log, noticing a > couple of things: > > 1) you're doing an assembly with unpaired 454 and unpaired Illumina, is > that correct? > 2) where did you get those ~200bp Illuminas from? By the look of the > statistics, they must be pretty good in quality ... clipped only some 4% of > the total bases and that's not worse than the 100bp reads I have seen so > far. > > B. > > PS: and would you like to test drive the current development version with > your data set to comment on whether you think it's better or worse? > -- > 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 >