[Bioc-devel] Build error in released version
Zhu, Lihua (Julie)
Julie.Zhu at umassmed.edu
Wed Jul 6 01:15:33 CEST 2016
Thanks for the clarification , Hervé!
That makes sense to me! I prefer option b and c.
> On Jul 5, 2016, at 6:05 PM, Hervé Pagès <hpages at fredhutch.org> wrote:
> Hi Julie,
>> On 07/05/2016 01:03 PM, Zhu, Lihua (Julie) wrote:
>> Dear Herve,
>> Thank you so much for the detailed explanation and quick fix!
>> When fusion occurs, the 2 alignments in a pair could be on different
>> chromosomes. Not sure what is the best way to handle this situation. If
>> set seqnames to *, then the mapping location is lost.
> The exact mapping location is stored in the GAligmentPairs object and
> will be preserved when the user coerces to GRangesList, either with
> grglist(.) or as(. , "GRangesList"). I was thinking in using * only
> when coercing to GRanges, either with granges(.) or as(. , "GRanges").
>> Maybe set seqnames
>> to one of the chromosome, and have a mcol seqname2? Indicating chromosome
> There is really no good way to represent features that span multiple
> chromosomes with a GRanges object. These features are better represented
> with a GRangesList object. That's really what GRangesList objects are
> So after giving it a 2nd thought, I'm tempted to either (a) just let
> coercion of GAligmentPairs to GRanges fail (with an informative error
> message) when some pairs span more than 1 chromosome, or (b) drop
> these pairs with a warning, or (c) add an extra argument to granges()
> to let the user decide between (a) and (b).
> Hopefully that makes sense.
>>> On 7/4/16 12:28 AM, "Hervé Pagès" <hpages at fredhutch.org> wrote:
>>> Hi Julie,
>>> The GAlignmentPairs container didn't support discordant strand until
>>> BioC 3.4 (current devel). In the current release (and in previous
>>> versions of BioC) strand discordance was not supported. I recently
>>> fixed a bug in the released version of GenomicAlignments where the
>>> strand() getter was returning an incorrect strand for pairs with
>>> discordant strand, instead of raising an error. This fix is what
>>> breaks the GUIDEseq vignette which creates and manipulates a
>>> GAlignmentPairs object with discordant strand.
>>> I just changed this again (in GenomicAlignments 1.8.4) so the
>>> strand() getter now returns * instead of raising an error in case
>>> of discordant strand (this is actually what strand() does in devel
>>> where strand discordance is now fully supported). That seems to
>>> fix GUIDEseq's vignette.
>>> I guess there was no solid reason for not supporting strand discordance.
>>> It was just a matter of deciding how the various GAlignmentPairs getters
>>> and extractors should handle this. Having strand() or granges() return
>>> * is probably the natural thing to do.
>>> A more complicated situation, which is also much less common, is
>>> chromosome discordance i.e. when the 2 alignments in a pair are on
>>> different chromosomes. Not clear what seqnames() or granges() should
>>> do in that case. Maybe return/set the seqname to * but that means
>>> introducing * as a special seqlevel. Still need to think about the
>>> implications of this.
>>>> On 07/01/2016 02:23 PM, Zhu, Lihua (Julie) wrote:
>>>> I just noticed that the released version of GUIDEseq failed at build
>>>> stage, which did not occur previously and I did not make any change to
>>>> the release version.
>>>> The error points to the GAlignmentPairs container. Is this an intended
>>>> change and should I modify my code to accommodate the change? If yes,
>>>> what is the rational to enforce the rule that
>>>> GAlignmentPairs container supports pairs where the 2 alignments are on
>>>> opposite strands of the same chromosome?
>>>> Thanks for your help!
>>>> Error in .local(x, ...) :
>>>> For some pairs in 'x', the 2 alignments are not on opposite strands.
>>>> associate a strand to them. Note that the GAlignmentPairs container
>>>> supports pairs where the 2 alignments are on opposite strands of the
>>>> chromosome at the moment.
>>>> Best regards,
>>>> [[alternative HTML version deleted]]
>>>> Bioc-devel at r-project.org mailing list
>>> 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 fredhutch.org
>>> Phone: (206) 667-5791
>>> Fax: (206) 667-1319
> 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 fredhutch.org
> Phone: (206) 667-5791
> Fax: (206) 667-1319
More information about the Bioc-devel