[Bioc-devel] writeVcf performance
Hervé Pagès
hpages at fhcrc.org
Wed Sep 10 02:03:04 CEST 2014
Ah, ok. I should have 'svn up' and re-tried 'R CMD check' before
reporting this. Thanks and sorry for the noise.
H.
On 09/09/2014 03:09 PM, Valerie Obenchain wrote:
> Hi Herve,
>
> This unit test passes in VA 1.11.30 (the current version in svn). It was
> related to writeVcf(), not the IRanges/S4Vector stuff. My fault, not yours.
>
> Val
>
> On 09/09/2014 02:47 PM, Hervé Pagès wrote:
>> 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