Conservation Track on hg38 (vs hg19/hg18) -unexpected 1bp shift

[Brian Lee]

Hi Browser folk,

This paper,  Chen H., et al. 2025. DOI: 10.1073/pnas.2500356122. describes how an AA mutation on a gene leads to a need for less sleep versus the 8 hours we all know about [ those wigs are really activity over time, where no signal means sleep]. 

The gene change is SIK3:N783Y and knowing the Browser's HGVS abilities I immediately wanted to try that and in fact, it worked perfectly, on hg18, which for some reason I had as my last genome when I opened a Browser tab (maybe where I had seen something unexpected on hg38 perhaps, and went to hg18 to compare previous behavior for something else).

Sessions to the searches:

https://genome.ucsc.edu/s/brianlee/hg18_SIK3%3AN783Y

https://genome.ucsc.edu/s/brianlee/hg19_SIK3%3AN783Y

https://genome.ucsc.edu/s/brianlee/hg38_SIK3%3AN783Y

On hg38, the SIK3:N783Y visit I noticedthat the conservation track looks off, perhaps from a 1bp alignment issue in work pipeline? Although other genes are fine, so something about this area.

So, there's some QC from the beyond for ya!

All the best,

Brian Lee

[Maximilian Haeussler]

Thanks for this detailed report, Brian!

I wonder if this is related to a question that we've had twice at the conference, people asked if we are sure or how they can they know whether we're using MANE as the transcript when we refer to a gene. Lou talked to a guy (forgot who, but Lou knows) who asked what the chrom-start-end is that we display when you search for a gene in the position box. He had an example where the position box jumps to the longest transcript, not the MANE transcript. 

The conservation tracks and the position box needs to pick a single transcript per gene and we may not have them switched to MANE yet?

--

---
You received this message because you are subscribed to the Google Groups "UCSC Genome Browser Public Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to genome+un...@soe.ucsc.edu.
To view this discussion visit https://groups.google.com/a/soe.ucsc.edu/d/msgid/genome/CAKuSS1L9XHNESLY7GMso3S_z1V4zt4zZYSEmAeGNOAZc8PsJkQ%40mail.gmail.com.

[Brian Lee]

Dear Browser folk,

I was looking at conservation tracks for a paper and saw something unusual, and am using this previous thread where I shared a similar story so it might be helpful to tie the observation together. 

A cool paper about Naked Mole Rat had an alignment picture in the supplemental files, and I went to recreate the 4 mutations on the UCSC Genome Browser using HGVS notation.   Surprisingly, on hg38 the AA for the human gene were not displaying similar to the paper. They do on hg18 and hg19, see these three links:

https://genome.ucsc.edu/cgi-bin/hgTracks?db=hg18&position=NP_612450.2(CGAS):p.K498T

https://genome.ucsc.edu/cgi-bin/hgTracks?db=hg19&position=NP_612450.2(CGAS):p.K498T 

https://genome.ucsc.edu/cgi-bin/hgTracks?db=hg38&position=NP_612450.2(CGAS):p.K498T   

**note no AA reading frame in hg38 conservation tracks** 

I ended up using panTro4 to push the Browser to the expected reading frame for hg38:

https://genome.ucsc.edu/cgi-bin/hgTracks?db=hg38&position=NP_612450.2(CGAS):p.K498T&speciesCodonDefault=panTro4  

 **note panTro4 returns the expected AA -also seen in hg18/hg19 so one can see it on hg38**

See more about the 4 mutations here if curious: https://genome.ucsc.edu/cgi-bin/hgPublicSessions?search=K498T

I think this prior item shared about what looks like a 1-off issue for a certain gene SIK3, and this new one here for CGAS gene where this isn't marked as a reading frame suggests something is up perhaps on the hg38 pipeline?  Maybe the hg38 pipeline is being influenced by hs1 data, or something trying to incorporate new more sophisticated data, and is resulting in slighting unexpected issues for less examined genes?

All the best,
Brian