AlexsLemonade / AlexsLemonade/OpenScPCA-nf
Consensus module: duplicate columns and missing ontologies
- Dominant language
- R
- Stars
- 2
- Forks
- 0
- PR merge metrics
- No merged PRs in 30d
Description
I'm opening this issue to point out a couple items that I noticed in our consensus files. I've been working with results files associated with the `2025-06-30` data release.
### Duplicate columns
Because we committed some light tautology, we have double consensus columns. The goal of [this script](https://github.com/AlexsLemonade/OpenScPCA-nf/blob/main/modules/cell-type-consensus/resources/usr/bin/assign-consensus-celltypes.R) is to add consensus cell types to objects, but the SCE objects (as of June!) now contain consensus cell types. This module is therefore producing files with all these columns:
```
[1] "project_id" "sample_id"
[3] "library_id" "barcodes"
[5] "sample_type" "singler_celltype_ontology"
[7] "singler_celltype_annotation" "cellassign_celltype_annotation"
[9] "cellassign_celltype_ontology" "consensus_celltype_annotation"
[11] "consensus_celltype_ontology" "panglao_ontology"
[13] "panglao_annotation" "blueprint_annotation_cl"
[15] "consensus_annotation" "consensus_ontology"
```
You'll notice this includes:
- Columns already in ScPCA objects: `"consensus_celltype_annotation"` & `"consensus_celltype_ontology"`
- Columns added by this script: `"consensus_annotation"` & `"consensus_ontology"`
An action item we _could_ take at this point is to just rip out the code that is assigning consensus cell types, and just export the TSV by reading from the SCE. We would still make the expression files. Worth noting that code in OpenScPCA is going to assume that these _TSV files_ have column names `"consensus_annotation"` & `"consensus_ontology"` (sans `_celltype_`).
### All ontologies are `NA`
It seems that every single value in _both_ `consensus_ontology` and `consensus_celltype_ontology` is `NA`, and not just for the `Unknown` cells! This is certainly not what we intend.
I downloaded some SCE objects to hope that this problem isn't there - and indeed it's not! Seems to only be an issue in the bucket _results_, not in the data, so that's good!
Here's one example:
```
## first run in terminal:
# ./download-data.py --samples SCPCS000495
# ./download-results.py --modules cell-type-consensus --samples SCPCS000495
> sce <- readRDS("../../data/current/SCPCP000015/SCPCS000495/SCPCL000827_processed.rds")
> colData(sce) |>
as.data.frame() |>
dplyr::pull(consensus_celltype_ontology) |>
unique()
# [1] NA "CL:0000066"
> consensus_table <- readr::read_tsv("../../data/current/results/cell-type-consensus/SCPCP000015/SCPCS000495/SCPCL000827_processed_consensus-cell-types.tsv.gz")
names(consensus_table)
# [1] "project_id" "sample_id"
# [3] "library_id" "barcodes"
# [5] "sample_type" "singler_celltype_ontology"
# [7] "singler_celltype_annotation" "cellassign_celltype_annotation"
# [9] "cellassign_celltype_ontology" "consensus_celltype_annotation"
# [11] "consensus_celltype_ontology" "panglao_ontology"
# [13] "panglao_annotation" "blueprint_annotation_cl"
# [15] "consensus_annotation" "consensus_ontology"
> all.equal(
consensus_table$consensus_celltype_annotation,
consensus_table$consensus_annotation
)
# [1] TRUE
> all.equal(
consensus_table$consensus_celltype_ontology,
consensus_table$consensus_ontology
)
# [1] TRUE
> unique(consensus_table$consensus_ontology)
# [1] NA
```
I have not looked into the source of this bug yet, just noting it here first.
Contributor guide
No contributing guide indexed for this repository
Research direction
Start with modules/cell-type-consensus/resources/usr/bin/assign-consensus-celltypes.R and reproduce the issue using the documented download commands for sample SCPCS000495. Compare the SCE colData values with the generated consensus-cell-types.tsv.gz columns, focusing on duplicate consensus fields and missing ontology values. Done means the exported TSV has the intended columns and retains the ontology values present in the SCE.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- r
- Domain
- data
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 35/100