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
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.
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.
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]]