CTAT-Splicing different calls in different genomes version

[Rodrigo de Alexandre]

Hi guys, we were testing CTAT-Splicing for both hg19 and hg38 using the ready to use kit from the website: 

• https://data.broadinstitute.org/Trinity/CTAT_RESOURCE_LIB/CANCER_SPLICING_LIB_SUPPLEMENT/ 

and the newest versions of genome library from:

• https://data.broadinstitute.org/Trinity/CTAT_RESOURCE_LIB/
  GRCh37_gencode_v19_CTAT_lib_Mar012021.STAR_v2.7.11a.plug-n-play.tar.gz and  GRCh38_gencode_v44_CTAT_lib_Oct292023.plug-n-play.tar.gz

we enriched the hg19 and hg38  cancer_introns.*.tsv.gz files with the AR-V3 and AR-V7 coordinates such

hg38:

chrX:67686127-67694672 AR ARV7
chrX:67643408-67680719 AR ARV3

hg19:

chrX:66905969-66914514 AR ARV7
chrX:66863250-66900561 AR ARV3

and the variants V3 and V7 were both called on the hg19, but only the V7 was called in the hg38.

It seems that in both alignment the reads are there identically (hg38.png and hg19.png), the regions were confirmed, the sample is the same and known to have this variant (22Rv1 - https://link.springer.com/article/10.1186/s12935-025-03948-y).

I am suspecting that the miss call can be of the  Genome library GRCh38_gencode_v44_CTAT_lib_Oct292023?

Would you recommend something to investigate and be able to call the same variant on hg38 as we were able to call on hg19?

Thanks! 

[Brian Haas]

Hi,

It's not obvious why it wouldn't call it on hg38 assuming the alignments look good at the donor site as well as the acceptor site there.  It should all be working the same way. Maybe double check the coordinates and the genome lib.  For hg38, the v22 annotation one is the 'default' lib that we usually use for our clinical applications in case you want to explore that instead of the newer one.

--
You received this message because you are subscribed to the Google Groups "Trinity_CTAT_users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to trinity_ctat_us...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/trinity_ctat_users/07e74882-c2c0-4385-a745-34ddb5d0fc16n%40googlegroups.com.

--

--
Brian J. Haas
The Broad Institute
http://broadinstitute.org/~bhaas

 

[Yves Konigshofer]

Maybe it has to do with the following logic. The fusion caller will not call exon skipping because it is not a fusion. For splicing related, the splicing caller detects unusual splicing in transcripts. However, if what you think would be unusual splicing is actually found in an official transcript (as I think is the case with AR, and hg38 is often more up to date with transcripts) then it may not be called. -Yves

To view this discussion visit https://groups.google.com/d/msgid/trinity_ctat_users/CAJCu8qMpC5TnTUzy3cUW9e%3DgqnG0Y35DGkEhMmTxN2VAF50VGw%40mail.gmail.com.

[Brian Haas]

If the splicing event shows up in either the splicing tab file or the chimeric junctions file and the splicing event is listed as one of the targets to annotate, then I think it should light it up.

[Rodrigo de Alexandre]

Hi there, thanks for the response.

So for this case this AR alternative splicing is not in an official transcript, they inherit a novel intronic exons that eventually leads for a frameshift and lof. Therefore, I was originally expecting it to find on the fusion pipeline and not a splicing variant, but indeed this is only located on the `SJ.out` file.

But everything else you guys mentioned help me debug the issue and now I am, somehow... embarrassed... but I am to test it to make sure.

So the variant is there, I've found it with another label. I think that the issue was that the file `cancer_introns.GRCh38.Jun232020.tsv.gz` already contains the line for this variant:
`chrX:67643408-67680719 AR^ENSG00000169083.14 BRCA:7:0.58,PRAD:1:0.19 NA NA`

which was my variantan we were adding it again on the bottom as 
chrX:67643408-67680719 AR^ENSG00000169083.14 NA NA AR-V3

so CTAT-Splicing was annotating using the first line that did not contained the AR-V3 name. However, what is strange is that this same line is present on the hg19 files and it  annotated correctly even if we duplicated the coordinates info at the bottom of the file.

just for closure, I will update you guys after the re-run relabeling the variant line name.

Thanks in advance