Thanks for the clarification , Hervé! That makes sense to me! I prefer option b and c.
Best, Julie > On Jul 5, 2016, at 6:05 PM, Hervé Pagès <hpa...@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 >> fusion? > > 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 > for. > > 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. > > H. > >> >> Best, >> >> Julie >> >> >> >> >> >> >>> On 7/4/16 12:28 AM, "Hervé Pagès" <hpa...@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. >>> >>> Cheers, >>> H. >>> >>>> On 07/01/2016 02:23 PM, Zhu, Lihua (Julie) wrote: >>>> Hi, >>>> >>>> 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. >>>> Cannot >>>> associate a strand to them. Note that the GAlignmentPairs container >>>> only >>>> supports pairs where the 2 alignments are on opposite strands of the >>>> same >>>> chromosome at the moment. >>>> >>>> Best regards, >>>> >>>> Julie >>>> >>>> [[alternative HTML version deleted]] >>>> >>>> _______________________________________________ >>>> Bioc-devel@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: hpa...@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: hpa...@fredhutch.org > Phone: (206) 667-5791 > Fax: (206) 667-1319 _______________________________________________ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
