[mira_talk] Re: condensed log file

  • From: Evan <evan@xxxxxxxxxxx>
  • To: mira_talk@xxxxxxxxxxxxx
  • Date: Fri, 2 Mar 2012 15:42:25 -0800

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
>

Other related posts: