Labels assigned doesn't match with the highest scoring label

[Rohit-Satyam]

I ran single R to transfer labels from a bulk reference time-series dataset (without replicates) to bulk rnaseq for QC purposes. This has worked nicely when the reference had replicates, but this is a public dataset that I am using now for the first time is without replicates. I run SingleR with de.method=classic and used de.n=200. I don't understand why if the score is higher for 10hpi label, the labels at the top use 4hpi

> res_tseries.kucharski[[1]]$scores
        10 hpi    12 hpi    14 hpi    16 hpi    18 hpi    22 hpi    24 hpi    26 hpi    28 hpi    30 hpi    32 hpi    34 hpi
[1,] 0.7805901 0.7626498 0.7357184 0.7012394 0.6679177 0.6722913 0.6739320 0.6699694 0.6823605 0.6858198 0.6886236 0.6964088
[2,] 0.7781633 0.7599447 0.7327808 0.6976559 0.6647156 0.6701460 0.6723079 0.6684611 0.6815441 0.6848084 0.6878125 0.6952748
[3,] 0.7769048 0.7589925 0.7320328 0.6977785 0.6645881 0.6694569 0.6708419 0.6669968 0.6789975 0.6830631 0.6865581 0.6949663
[4,] 0.6917643 0.6704914 0.6352635 0.5968737 0.5652588 0.5926529 0.6039086 0.6128310 0.6406161 0.6608708 0.6974002 0.7338453
[5,] 0.6909306 0.6697967 0.6340439 0.5959920 0.5641709 0.5916684 0.6029011 0.6119531 0.6398416 0.6601498 0.6965040 0.7330873
[6,] 0.6919027 0.6706385 0.6346216 0.5963225 0.5642694 0.5917624 0.6030512 0.6121527 0.6400616 0.6604229 0.6967972 0.7334301
        36 hpi    38 hpi     4 hpi    40 hpi    42 hpi    44 hpi     6 hpi     8 hpi
[1,] 0.6949067 0.7028567 0.7712020 0.7062238 0.7185048 0.7187610 0.7651569 0.7779828
[2,] 0.6935645 0.7020232 0.7681642 0.7047179 0.7172113 0.7160760 0.7617802 0.7751237
[3,] 0.6932498 0.7015000 0.7674498 0.7050899 0.7182130 0.7182876 0.7611400 0.7747185
[4,] 0.7559287 0.7823599 0.7153703 0.7904675 0.8061759 0.7945158 0.6853917 0.7006593
[5,] 0.7550686 0.7814470 0.7144866 0.7894614 0.8052048 0.7932714 0.6843170 0.6994038
[6,] 0.7554251 0.7821525 0.7154152 0.7902032 0.8061750 0.7938435 0.6850399 0.7002171

res_tseries.kucharski[[1]]$delta.next
[1] 0.012727303 0.013352256 0.009766989 0.001950804 0.002341300 0.001301832

[Rohit-Satyam]

I think this ti because the top scores are very close for multiple time points:

10 hpi = 0.7805901
8 hpi = 0.7779828
4 hpi = 0.7712020
6 hpi = 0.7651569
12 hpi = 0.7626498

These are all within a small range. With the default fine.tune=TRUE, 4 hpi can survive or win the fine-tuning step even though 10 hpi has the highest value in the displayed scores. I will set fine.tune=FALSE for now to avoid confusion in these plots for my collaborators.

[LTLA]

You're pretty much identified the cause. To recap: fine-tuning will take the top labels with near-tied scores and spend more effort in trying to distinguish between them. This is achieved by recomputing the scores with only the subset of marker genes in the pairwise comparisons between the top labels. The idea is to remove noise from irrelevant genes in the fine-tuned correlations, improve resolution of differences between closely-related labels, and thus improve accuracy of assignment.

However, the fine-tuned scores won't match up with the original scores (computed from all markers), so you can observe some minor discrepancies between the fine-tuned labels and the top scoring label in each row of scores. This is exacerbated by how plotScoreHeatmap() works by default - all values are normalized in a 0-1 range for each test sample so that small differences between near-tied labels are magnified.

I would recommend sticking to the fine-tuned labels, they're probably more accurate.