[Bioc-devel] writeVcf performance

Hervé Pagès hpages at fhcrc.org
Tue Sep 9 23:47:46 CEST 2014


Hi Val,

On 09/09/2014 02:12 PM, Valerie Obenchain wrote:
> Writing 'list' data has been fixed in 1.11.30. fyi, Herve is in the
> process of moving SimpleList and DataFrame from IRanges to S4Vectors;
> finished up today I think.

I fixed VariantAnnotation's NAMESPACE this morning but 'R CMD check'
failed for me because of an unit test error in test_VRanges_vcf().
Here is how to quickly reproduce:

   library(VariantAnnotation)
   library(RUnit)
   source("path/to/VariantAnnotation/inst/unitTests/test_VRanges-class.R")

   dest <- tempfile()
   vr <- make_TARGET_VRanges_vcf()
   writeVcf(vr, dest)
   vcf <- readVcf(dest, genome = "hg19")
   perm <- c(1, 7, 8, 4, 2, 10)
   vcf.vr <- as(vcf, "VRanges")[perm]
   genome(vr) <- "hg19"
   checkIdenticalVCF(vr, vcf.vr)  # Error in checkIdentical(orig, vcf) : 
FALSE

Hard for me to tell whether this is related to DataFrame moving from 
IRanges to S4Vectors or to a regression in writeVcf(). Do you think
you can have a look? Thanks for the help and sorry for the trouble.

H.

> Anyhow, if you get VariantAnnotation from svn
> you'll need to update S4Vectors, IRanges and GenomicRanges (and maybe
> rtracklayer).
>
> I'm working on the 'chunking' approach next. It looks like we can still
> gain from adding that.
>
> Valerie
>
> On 09/08/2014 12:00 PM, Valerie Obenchain wrote:
>> fyi Martin found a bug with the treatment of list data (ie, Number =
>> '.') in the header. Working on a fix ...
>>
>> Val
>>
>>
>> On 09/08/2014 08:43 AM, Gabe Becker wrote:
>>> Val,
>>>
>>> That is great. I'll check this out and test it on our end.
>>>
>>> ~G
>>>
>>> On Mon, Sep 8, 2014 at 8:38 AM, Valerie Obenchain <vobencha at fhcrc.org
>>> <mailto:vobencha at fhcrc.org>> wrote:
>>>
>>>     The new writeVcf code is in 1.11.28.
>>>
>>>     Using the illumina file you suggested, geno fields only, writing now
>>>     takes about 17 minutes.
>>>
>>>      > hdr
>>>     class: VCFHeader
>>>     samples(1): NA12877
>>>     meta(6): fileformat ApplyRecalibration ... reference source
>>>     fixed(1): FILTER
>>>     info(22): AC AF ... culprit set
>>>     geno(8): GT GQX ... PL VF
>>>
>>>      > param = ScanVcfParam(info=NA)
>>>      > vcf = readVcf(fl, "", param=param)
>>>      > dim(vcf)
>>>     [1] 51612762        1
>>>
>>>      > system.time(writeVcf(vcf, "out.vcf"))
>>>          user   system  elapsed
>>>       971.032    6.568 1004.593
>>>
>>>     In 1.11.28, parsing of geno data was moved to C. If this didn't
>>>     speed things up enough we were planning to implement 'chunking'
>>>     through the VCF and/or move the parsing of info to C, however, it
>>>     looks like geno was the bottleneck.
>>>
>>>     I've tested a number of samples/fields combinations in files with >=
>>>     .5 million rows and the improvement over writeVcf() in release is
>>> ~ 90%.
>>>
>>>     Valerie
>>>
>>>
>>>
>>>
>>>     On 09/04/14 15:28, Valerie Obenchain wrote:
>>>
>>>         Thanks Gabe. I should have something for you on Monday.
>>>
>>>         Val
>>>
>>>
>>>         On 09/04/2014 01:56 PM, Gabe Becker wrote:
>>>
>>>             Val and Martin,
>>>
>>>             Apologies for the delay.
>>>
>>>             We realized that the Illumina platinum genome vcf files make
>>>             a good test
>>>             case, assuming you strip out all the info (info=NA when
>>>             reading it into
>>>             R) stuff.
>>>
>>>
>>> ftp://platgene:G3n3s4me@ussd-__ftp.illumina.com/NA12877_S1.__genome.vcf.gz
>>>
>>>
>>>
>>> <ftp://platgene:G3n3s4me@ussd-ftp.illumina.com/NA12877_S1.genome.vcf.gz>
>>>             took about ~4.2 hrs to write out, and is about 1.5x the size
>>>             of the
>>>             files we are actually dealing with (~50M ranges vs our
>>> ~30M).
>>>
>>>             Looking forward a new vastly improved writeVcf :).
>>>
>>>             ~G
>>>
>>>
>>>             On Tue, Sep 2, 2014 at 1:53 PM, Michael Lawrence
>>>             <lawrence.michael at gene.com
>>>             <mailto:lawrence.michael at gene.com>
>>>             <mailto:lawrence.michael at gene.__com
>>>             <mailto:lawrence.michael at gene.com>>> wrote:
>>>
>>>                  Yes, it's very clear that the scaling is non-linear,
>>>             and Gabe has
>>>                  been experimenting with a chunk-wise + parallel
>>> algorithm.
>>>                  Unfortunately there is some frustrating overhead with
>>> the
>>>                  parallelism. But I'm glad Val is arriving at something
>>>             quicker.
>>>
>>>                  Michael
>>>
>>>
>>>                  On Tue, Sep 2, 2014 at 1:33 PM, Martin Morgan
>>>             <mtmorgan at fhcrc.org <mailto:mtmorgan at fhcrc.org>
>>>                  <mailto:mtmorgan at fhcrc.org
>>>             <mailto:mtmorgan at fhcrc.org>>> wrote:
>>>
>>>                      On 08/27/2014 11:56 AM, Gabe Becker wrote:
>>>
>>>                          The profiling I attached in my previous email
>>>             is for 24 geno
>>>                          fields, as I said,
>>>                          but our typical usecase involves only ~4-6
>>>             fields, and is
>>>                          faster but still on
>>>                          the order of dozens of minutes.
>>>
>>>
>>>                      I think Val is arriving at a (much) more efficient
>>>                      implementation, but...
>>>
>>>                      I wanted to share my guess that the poor _scaling_
>>>             is because
>>>                      the garbage collector runs multiple times as the
>>>             different
>>>                      strings are pasted together, and has to traverse,
>>>             in linear
>>>                      time, increasing numbers of allocated SEXPs. So
>>>             times scale
>>>                      approximately quadratically with the number of rows
>>>             in the VCF
>>>
>>>                      An efficiency is to reduce the number of SEXPs in
>>>             play by
>>>                      writing out in chunks -- as each chunk is written,
>>>             the SEXPs
>>>                      become available for collection and are re-used.
>>>             Here's my toy
>>>                      example
>>>
>>>                      time.R
>>>                      ======
>>>                      splitIndices <- function (nx, ncl)
>>>                      {
>>>                           i <- seq_len(nx)
>>>                           if (ncl == 0L)
>>>                               list()
>>>                           else if (ncl == 1L || nx == 1L)
>>>                               list(i)
>>>                           else {
>>>                               fuzz <- min((nx - 1L)/1000, 0.4 * nx/ncl)
>>>                               breaks <- seq(1 - fuzz, nx + fuzz, length
>>>             = ncl + 1L)
>>>                               structure(split(i, cut(i, breaks,
>>>             labels=FALSE)), names
>>>                      = NULL)
>>>                           }
>>>                      }
>>>
>>>                      x = as.character(seq_len(1e7)); y = sample(x)
>>>                      if (!is.na <http://is.na>
>>>             <http://is.na>(Sys.getenv("__SPLIT", NA))) {
>>>                           idx <- splitIndices(length(x), 20)
>>>                           system.time(for (i in idx) paste(x[i], y[i],
>>>             sep=":"))
>>>                      } else {
>>>                           system.time(paste(x, y, sep=":"))
>>>                      }
>>>
>>>
>>>                      running under R-devel with $ SPLIT=TRUE R --no-save
>>>             --quiet -f
>>>                      time.R the relevant time is
>>>
>>>                          user  system elapsed
>>>                        15.320   0.064  15.381
>>>
>>>                      versus with $ R --no-save --quiet -f time.R it is
>>>
>>>                          user  system elapsed
>>>                        95.360   0.164  95.511
>>>
>>>                      I think this is likely an overall strategy when
>>>             dealing with
>>>                      character data -- processing in independent chunks
>>>             of moderate
>>>                      (1M?) size (enabling as a consequence parallel
>>>             evaluation in
>>>                      modest memory) that are sufficient to benefit from
>>>                      vectorization, but that do not entail allocation of
>>>             large
>>>                      numbers of in-use SEXPs.
>>>
>>>                      Martin
>>>
>>>
>>>                          Sorry for the confusion.
>>>                          ~G
>>>
>>>
>>>                          On Wed, Aug 27, 2014 at 11:45 AM, Gabe Becker
>>>                          <beckerg4 at gene.com <mailto:beckerg4 at gene.com>
>>>             <mailto:beckerg4 at gene.com <mailto:beckerg4 at gene.com>>
>>>                          <mailto:beckerg4 at gene.com
>>>             <mailto:beckerg4 at gene.com> <mailto:beckerg4 at gene.com
>>>             <mailto:beckerg4 at gene.com>>>> wrote:
>>>
>>>                               Martin and Val.
>>>
>>>                               I re-ran writeVcf on our (G)VCF data
>>>             (34790518 ranges,
>>>                          24 geno fields) with
>>>                               profiling enabled. The results of
>>>             summaryRprof for that
>>>                          run are attached,
>>>                               though for a variety of reasons they are
>>>             pretty
>>>             misleading.
>>>
>>>                               It took over an hour to write
>>>             (3700+seconds), so it's
>>>                          definitely a
>>>                               bottleneck when the data get very large,
>>>             even if it
>>>                          isn't for smaller data.
>>>
>>>                               Michael and I both think the culprit is
>>>             all the pasting
>>>                          and cbinding that is
>>>                               going on, and more to the point, that
>>>             memory for an
>>>                          internal representation
>>>                               to be written out is allocated at all.
>>>             Streaming
>>>                          across the object, looping
>>>                               by rows and writing directly to file (e.g.
>>>             from C)
>>>                          should be blisteringly
>>>                               fast in comparison.
>>>
>>>                               ~G
>>>
>>>
>>>                               On Tue, Aug 26, 2014 at 11:57 AM, Michael
>>>             Lawrence
>>>                          <michafla at gene.com <mailto:michafla at gene.com>
>>>             <mailto:michafla at gene.com <mailto:michafla at gene.com>>
>>>                               <mailto:michafla at gene.com
>>>             <mailto:michafla at gene.com> <mailto:michafla at gene.com
>>>             <mailto:michafla at gene.com>>>>
>>>                          wrote:
>>>
>>>                                   Gabe is still testing/profiling, but
>>>             we'll send
>>>                          something randomized
>>>                                   along eventually.
>>>
>>>
>>>                                   On Tue, Aug 26, 2014 at 11:15 AM,
>>>             Martin Morgan
>>>                          <mtmorgan at fhcrc.org <mailto:mtmorgan at fhcrc.org>
>>>             <mailto:mtmorgan at fhcrc.org <mailto:mtmorgan at fhcrc.org>>
>>>                                   <mailto:mtmorgan at fhcrc.org
>>>             <mailto:mtmorgan at fhcrc.org>
>>>                          <mailto:mtmorgan at fhcrc.org
>>>             <mailto:mtmorgan at fhcrc.org>>>> wrote:
>>>
>>>                                       I didn't see in the original
>>> thread a
>>>                          reproducible (simulated, I
>>>                                       guess) example, to be explicit
>>>             about what the
>>>                          problem is??
>>>
>>>                                       Martin
>>>
>>>
>>>                                       On 08/26/2014 10:47 AM, Michael
>>>             Lawrence wrote:
>>>
>>>                                           My understanding is that the
>>> heap
>>>                          optimization provided marginal
>>>                                           gains, and
>>>                                           that we need to think harder
>>>             about how to
>>>                          optimize the all of
>>>                                           the string
>>>                                           manipulation in writeVcf. We
>>>             either need to
>>>                          reduce it or reduce its
>>>                                           overhead (i.e., the CHARSXP
>>>             allocation).
>>>                          Gabe is doing more tests.
>>>
>>>
>>>                                           On Tue, Aug 26, 2014 at 9:43
>>>             AM, Valerie
>>>                          Obenchain
>>>                                           <vobencha at fhcrc.org
>>>             <mailto:vobencha at fhcrc.org>
>>>                          <mailto:vobencha at fhcrc.org
>>>             <mailto:vobencha at fhcrc.org>> <mailto:vobencha at fhcrc.org
>>>             <mailto:vobencha at fhcrc.org>
>>>                          <mailto:vobencha at fhcrc.org
>>>             <mailto:vobencha at fhcrc.org>>>>
>>>
>>>                                           wrote:
>>>
>>>                                               Hi Gabe,
>>>
>>>                                               Martin responded, and so
>>>             did Michael,
>>>
>>>
>>>
>>> https://stat.ethz.ch/______pipermail/bioc-devel/2014-______August/006082.html
>>>
>>>
>>>
>>> <https://stat.ethz.ch/____pipermail/bioc-devel/2014-____August/006082.html>
>>>
>>>
>>>
>>>
>>> <https://stat.ethz.ch/____pipermail/bioc-devel/2014-____August/006082.html
>>>
>>>
>>>
>>> <https://stat.ethz.ch/__pipermail/bioc-devel/2014-__August/006082.html>>
>>>
>>>
>>>
>>>
>>> <https://stat.ethz.ch/____pipermail/bioc-devel/2014-____August/006082.html
>>>
>>>
>>>
>>> <https://stat.ethz.ch/__pipermail/bioc-devel/2014-__August/006082.html>
>>>
>>>
>>> <https://stat.ethz.ch/__pipermail/bioc-devel/2014-__August/006082.html
>>>
>>> <https://stat.ethz.ch/pipermail/bioc-devel/2014-August/006082.html>>>
>>>
>>>                                               It sounded like Michael
>>>             was ok with
>>>                          working with/around heap
>>>                                               initialization.
>>>
>>>                                               Michael, is that right or
>>>             should we
>>>                          still consider this on
>>>                                               the table?
>>>
>>>
>>>                                               Val
>>>
>>>
>>>                                               On 08/26/2014 09:34 AM,
>>>             Gabe Becker
>>>             wrote:
>>>
>>>                                                   Val,
>>>
>>>                                                   Has there been any
>>>             movement on
>>>                          this? This remains a
>>>                                                   substantial
>>>                                                   bottleneck for us when
>>>             writing very
>>>                          large VCF files (e.g.
>>>                                                   variants+genotypes for
>>>             whole genome
>>>                          NGS samples).
>>>
>>>                                                   I was able to see a
>>>             ~25% speedup
>>>                          with 4 cores and  an
>>>                                                   "optimal" speedup
>>>                                                   of ~2x with 10-12
>>>             cores for a VCF
>>>                          with 500k rows  using
>>>                                                   a very naive
>>>                                                   parallelization
>>>             strategy and no
>>>                          other changes. I suspect
>>>                                                   this could be
>>>                                                   improved on quite a
>>>             bit, or
>>>                          possibly made irrelevant
>>>                                                   with judicious use
>>>                                                   of serial C code.
>>>
>>>                                                   Did you and Martin
>>>             make any plans
>>>                          regarding optimizing
>>>                                                   writeVcf?
>>>
>>>                                                   Best
>>>                                                   ~G
>>>
>>>
>>>                                                   On Tue, Aug 5, 2014 at
>>>             2:33 PM,
>>>                          Valerie Obenchain
>>>                                                   <vobencha at fhcrc.org
>>>             <mailto:vobencha at fhcrc.org>
>>>                          <mailto:vobencha at fhcrc.org
>>>             <mailto:vobencha at fhcrc.org>> <mailto:vobencha at fhcrc.org
>>>             <mailto:vobencha at fhcrc.org>
>>>                          <mailto:vobencha at fhcrc.org
>>>             <mailto:vobencha at fhcrc.org>>>
>>>
>>>               <mailto:vobencha at fhcrc.org <mailto:vobencha at fhcrc.org>
>>>                          <mailto:vobencha at fhcrc.org
>>>             <mailto:vobencha at fhcrc.org>> <mailto:vobencha at fhcrc.org
>>>             <mailto:vobencha at fhcrc.org>
>>>                          <mailto:vobencha at fhcrc.org
>>>             <mailto:vobencha at fhcrc.org>>>>>
>>>
>>>                                                   wrote:
>>>
>>>                                                         Hi Michael,
>>>
>>>                                                         I'm interested
>>>             in working on
>>>                          this. I'll discuss
>>>                                                   with Martin next
>>>                                                         week when we're
>>>             both back in
>>>                          the office.
>>>
>>>                                                         Val
>>>
>>>
>>>
>>>
>>>
>>>                                                         On 08/05/14
>>>             07:46, Michael
>>>                          Lawrence wrote:
>>>
>>>                                                             Hi guys
>>>             (Val, Martin,
>>>             Herve):
>>>
>>>                                                             Anyone have
>>>             an itch for
>>>                          optimization? The
>>>                                                   writeVcf function is
>>>                                                             currently a
>>>                                                             bottleneck
>>>             in our WGS
>>>                          genotyping pipeline. For
>>>                                                   a typical 50
>>>                                                             million row
>>>                                                             gVCF, it was
>>>             taking 2.25
>>>                          hours prior to
>>>                                                   yesterday's
>>> improvements
>>>
>>>               (pasteCollapseRows) that
>>>                          brought it down to
>>>                                                   about 1 hour, which
>>>                                                             is still
>>>                                                             too long by
>>>             my standards
>>>                          (> 0). Only takes 3
>>>                                                   minutes to call the
>>>                                                             genotypes
>>>                                                             (and
>>> associated
>>>                          likelihoods etc) from the
>>>                                                   variant calls (using
>>>                                                             80 cores and
>>>                                                             450 GB RAM
>>>             on one node),
>>>                          so the output is an
>>>                                                   issue. Profiling
>>>                                                             suggests
>>> that
>>>                                                             the running
>>>             time scales
>>>                          non-linearly in the
>>>                                                   number of rows.
>>>
>>>                                                             Digging a
>>>             little deeper,
>>>                          it seems to be
>>>                                                   something with R's
>>>
>>> string/memory
>>>                                                             allocation.
>>>             Below,
>>>                          pasting 1 million strings
>>>                                                   takes 6 seconds, but
>>>                                                   10
>>>                                                             million
>>>             strings takes
>>>                          over 2 minutes. It gets
>>>                                                   way worse with 50
>>>                                                             million. I
>>>                                                             suspect it
>>>             has something
>>>                          to do with R's string
>>>                                                   hash table.
>>>
>>>
>>> set.seed(1000)
>>>                                                             end <-
>>>             sample(1e8, 1e6)
>>>
>>>               system.time(paste0("END",
>>>                          "=", end))
>>>                                                                  user
>>>             system elapsed
>>>                                                                 6.396
>>>               0.028   6.420
>>>
>>>                                                             end <-
>>>             sample(1e8, 1e7)
>>>
>>>               system.time(paste0("END",
>>>                          "=", end))
>>>                                                                  user
>>>             system elapsed
>>>                                                             134.714
>>>               0.352 134.978
>>>
>>>                                                             Indeed, even
>>>             this takes a
>>>                          long time (in a
>>>                                                   fresh session):
>>>
>>>
>>> set.seed(1000)
>>>                                                             end <-
>>>             sample(1e8, 1e6)
>>>                                                             end <-
>>>             sample(1e8, 1e7)
>>>
>>>                          system.time(as.character(end))
>>>                                                                  user
>>>             system elapsed
>>>                                                                57.224
>>>               0.156  57.366
>>>
>>>                                                             But running
>>>             it a second
>>>                          time is faster (about
>>>                                                   what one would
>>>                                                             expect?):
>>>
>>>
>>>               system.time(levels <-
>>>                          as.character(end))
>>>                                                                  user
>>>             system elapsed
>>>                                                                23.582
>>>               0.021  23.589
>>>
>>>                                                             I did some
>>>             simple
>>>                          profiling of R to find that
>>>                                                   the resizing of
>>>                                                             the string
>>>                                                             hash table
>>>             is not a
>>>                          significant component of
>>>                                                   the time. So maybe
>>>                                                             something
>>>                                                             to do with
>>>             the R heap/gc?
>>>                          No time right now to
>>>                                                   go deeper. But I
>>>                                                             know Martin
>>>                                                             likes this
>>>             sort of
>>>             thing ;)
>>>
>>>                                                             Michael
>>>
>>>
>>>             [[alternative
>>>                          HTML version deleted]]
>>>
>>>
>>>
>>>
>>>             _______________________________________________________
>>>             Bioc-devel at r-project.org <mailto:Bioc-devel at r-project.org>
>>>             <mailto:Bioc-devel at r-project.__org
>>>             <mailto:Bioc-devel at r-project.org>>
>>>
>>>               <mailto:Bioc-devel at r-project.
>>>             <mailto:Bioc-devel at r-project.>____org
>>>                          <mailto:Bioc-devel at r-project.__org
>>>             <mailto:Bioc-devel at r-project.org>>>
>>>
>>>               <mailto:Bioc-devel at r-project
>>> <mailto:Bioc-devel at r-project>.
>>>                          <mailto:Bioc-devel at r-project
>>>             <mailto:Bioc-devel at r-project>.>______org
>>>
>>>               <mailto:Bioc-devel at r-project.
>>>             <mailto:Bioc-devel at r-project.>____org
>>>                          <mailto:Bioc-devel at r-project.__org
>>>             <mailto:Bioc-devel at r-project.org>>>>
>>>                                                             mailing list
>>>
>>>             https://stat.ethz.ch/mailman/________listinfo/bioc-devel
>>>             <https://stat.ethz.ch/mailman/______listinfo/bioc-devel>
>>>
>>>             <https://stat.ethz.ch/mailman/______listinfo/bioc-devel
>>>             <https://stat.ethz.ch/mailman/____listinfo/bioc-devel>>
>>>
>>>
>>>             <https://stat.ethz.ch/mailman/______listinfo/bioc-devel
>>>             <https://stat.ethz.ch/mailman/____listinfo/bioc-devel>
>>>
>>>             <https://stat.ethz.ch/mailman/____listinfo/bioc-devel
>>>             <https://stat.ethz.ch/mailman/__listinfo/bioc-devel>>>
>>>
>>>
>>>
>>>             <https://stat.ethz.ch/mailman/______listinfo/bioc-devel
>>>             <https://stat.ethz.ch/mailman/____listinfo/bioc-devel>
>>>
>>>             <https://stat.ethz.ch/mailman/____listinfo/bioc-devel
>>>             <https://stat.ethz.ch/mailman/__listinfo/bioc-devel>>
>>>
>>>
>>>             <https://stat.ethz.ch/mailman/____listinfo/bioc-devel
>>>             <https://stat.ethz.ch/mailman/__listinfo/bioc-devel>
>>>
>>>             <https://stat.ethz.ch/mailman/__listinfo/bioc-devel
>>>             <https://stat.ethz.ch/mailman/listinfo/bioc-devel>>>>
>>>
>>>
>>>
>>>
>>>             _______________________________________________________
>>>             Bioc-devel at r-project.org <mailto:Bioc-devel at r-project.org>
>>>             <mailto:Bioc-devel at r-project.__org
>>>             <mailto:Bioc-devel at r-project.org>>
>>>
>>>               <mailto:Bioc-devel at r-project.
>>>             <mailto:Bioc-devel at r-project.>____org
>>>                          <mailto:Bioc-devel at r-project.__org
>>>             <mailto:Bioc-devel at r-project.org>>>
>>>
>>>               <mailto:Bioc-devel at r-project
>>> <mailto:Bioc-devel at r-project>.
>>>                          <mailto:Bioc-devel at r-project
>>>             <mailto:Bioc-devel at r-project>.>______org
>>>
>>>               <mailto:Bioc-devel at r-project.
>>>             <mailto:Bioc-devel at r-project.>____org
>>>                          <mailto:Bioc-devel at r-project.__org
>>>             <mailto:Bioc-devel at r-project.org>>>> mailing
>>>                                                   list
>>>             https://stat.ethz.ch/mailman/________listinfo/bioc-devel
>>>             <https://stat.ethz.ch/mailman/______listinfo/bioc-devel>
>>>
>>>             <https://stat.ethz.ch/mailman/______listinfo/bioc-devel
>>>             <https://stat.ethz.ch/mailman/____listinfo/bioc-devel>>
>>>
>>>
>>>             <https://stat.ethz.ch/mailman/______listinfo/bioc-devel
>>>             <https://stat.ethz.ch/mailman/____listinfo/bioc-devel>
>>>
>>>             <https://stat.ethz.ch/mailman/____listinfo/bioc-devel
>>>             <https://stat.ethz.ch/mailman/__listinfo/bioc-devel>>>
>>>
>>>
>>>
>>>
>>>
>>>             <https://stat.ethz.ch/mailman/______listinfo/bioc-devel
>>>             <https://stat.ethz.ch/mailman/____listinfo/bioc-devel>
>>>
>>>             <https://stat.ethz.ch/mailman/____listinfo/bioc-devel
>>>             <https://stat.ethz.ch/mailman/__listinfo/bioc-devel>>
>>>
>>>
>>>             <https://stat.ethz.ch/mailman/____listinfo/bioc-devel
>>>             <https://stat.ethz.ch/mailman/__listinfo/bioc-devel>
>>>
>>>             <https://stat.ethz.ch/mailman/__listinfo/bioc-devel
>>>             <https://stat.ethz.ch/mailman/listinfo/bioc-devel>>>>
>>>
>>>
>>>
>>>
>>>                                                   --
>>>                                                   Computational
>>> Biologist
>>>                                                   Genentech Research
>>>
>>>
>>>
>>>
>>>
>>>                                                    [[alternative HTML
>>>             version
>>>             deleted]]
>>>
>>>
>>>
>>>             _____________________________________________________
>>>             Bioc-devel at r-project.org <mailto:Bioc-devel at r-project.org>
>>>             <mailto:Bioc-devel at r-project.__org
>>>             <mailto:Bioc-devel at r-project.org>>
>>>                          <mailto:Bioc-devel at r-project.
>>>             <mailto:Bioc-devel at r-project.>____org
>>>                          <mailto:Bioc-devel at r-project.__org
>>>             <mailto:Bioc-devel at r-project.org>>>
>>>                                           mailing list
>>>             https://stat.ethz.ch/mailman/______listinfo/bioc-devel
>>>             <https://stat.ethz.ch/mailman/____listinfo/bioc-devel>
>>>
>>>             <https://stat.ethz.ch/mailman/____listinfo/bioc-devel
>>>             <https://stat.ethz.ch/mailman/__listinfo/bioc-devel>>
>>>
>>>
>>>             <https://stat.ethz.ch/mailman/____listinfo/bioc-devel
>>>             <https://stat.ethz.ch/mailman/__listinfo/bioc-devel>
>>>
>>>             <https://stat.ethz.ch/mailman/__listinfo/bioc-devel
>>>             <https://stat.ethz.ch/mailman/listinfo/bioc-devel>>>
>>>
>>>
>>>
>>>                                       --
>>>                                       Computational Biology / Fred
>>>             Hutchinson Cancer
>>>                          Research Center
>>>                                       1100 Fairview Ave. N.
>>>                                       PO Box 19024 Seattle, WA 98109
>>>
>>>                                       Location: Arnold Building M1 B861
>>>                                       Phone: (206) 667-2793
>>>             <tel:%28206%29%20667-2793>
>>>                          <tel:%28206%29%20667-2793>
>>>             <tel:%28206%29%20667-2793>
>>>
>>>
>>>
>>>
>>>
>>>
>>>                               --
>>>                               Computational Biologist
>>>                               Genentech Research
>>>
>>>
>>>
>>>
>>>                          --
>>>                          Computational Biologist
>>>                          Genentech Research
>>>
>>>
>>>
>>>                      --
>>>                      Computational Biology / Fred Hutchinson Cancer
>>>             Research Center
>>>                      1100 Fairview Ave. N.
>>>                      PO Box 19024 Seattle, WA 98109
>>>
>>>                      Location: Arnold Building M1 B861
>>>                      Phone: (206) 667-2793 <tel:%28206%29%20667-2793>
>>>             <tel:%28206%29%20667-2793>
>>>
>>>
>>>
>>>
>>>
>>>             --
>>>             Computational Biologist
>>>             Genentech Research
>>>
>>>
>>>         _________________________________________________
>>>         Bioc-devel at r-project.org <mailto:Bioc-devel at r-project.org>
>>>         mailing list
>>>         https://stat.ethz.ch/mailman/__listinfo/bioc-devel
>>>         <https://stat.ethz.ch/mailman/listinfo/bioc-devel>
>>>
>>>
>>>
>>>
>>>
>>> --
>>> Computational Biologist
>>> Genentech Research
>>
>> _______________________________________________
>> Bioc-devel at r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>
> _______________________________________________
> Bioc-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel

-- 
Hervé Pagès

Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024

E-mail: hpages at fhcrc.org
Phone:  (206) 667-5791
Fax:    (206) 667-1319



More information about the Bioc-devel mailing list