[protocols] Comments on protocols

[Adina Chuang Howe]

Under "Run the first round of diginorm", on the second bit catching the
single reads, I think if you exclude the hash size, it will use the
defaults (which aren't that useful), I'd suggest putting size in here
consistent with the first one.  I believe the default is 1e9 which is
inconsistent with the 5e8 anyways.

-a


On Wed, Aug 21, 2013 at 1:35 PM, Adina Chuang Howe <howead at msu.edu> wrote:

> Just a few minor comments on metagenome assembly tutorial.
>
> 1)  I like to have the report printing with the -R option but maybe it is
> excluded here for simplification, but I also like to see it to see how
> things are proceeding (e.g., how much longer things will take)
>
> 2)  Digression:  For metagenome assembly, the protocol "as is" is  what I
> usually run if I have a pretty large insert size and my reads aren't
> expected to overlap.  For the more complex environments, I've opted to have
> more overlapping reads (smaller insert sizes) and do a merge of these
> paired prior to any diginorm, assembly, etc.  I dont know if needs to be in
> the manual, but I wanted to bring it up as a distinguishment on what I
> would at least recommend based on library prep.   In the case that I have a
> lot of merged pairs (>80%), I run those through diginorm first and then
> grab the orphans and put them in as paired ends (no merge).  This leaves
> trimmomatic orphans as bastardized files and a p.i.t.a to deal with --
> since they typically make up less than 1% of my reads, I usually exclude
> trimmomatic se files from any other analysis.
>
> 3)  Do we need more explanation of what -V is, i.e., just put in that
> we're only trimming from high coverage and not everything?  I had to go
> look at the code to understand the new option.
>
> Probably more to come as I run through this...but it looks nice!
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.idyll.org/pipermail/protocols/attachments/20130822/4294b2a6/attachment.html>