Cell type annotation: scGPT workflow #832
Conversation
dorien-er
changed the title
dorien-er
changed the title
* update description concat component * Update src/dataflow/concatenate_h5mu/config.vsh.yaml Co-authored-by: Dries Schaumont <[email protected]> --------- Co-authored-by: Dries Schaumont <[email protected]>
Co-authored-by: Vladimir Shitov <[email protected]>
Co-authored-by: DriesSchaumont <[email protected]>
* Remove uses of auto: [publish: true] * Undo removal of publish component * Fix integration test
* add component to subset obsp * update changelog * update descriptions * fix tests * add comment
* update knn component * update changelog * update changelog * address pr comments * fix tests * fix tests
* update scanvi * typo * update changelog
#894) * Fix ingestion components not working when optional arguments are unset * update changelog * fix test
| model_dict = {} | ||
| model_dict["model_state_dict"] = f_model_dict | ||
| model_dict["id_to_class"] = {k: str(k) for k in range(15)} | ||
| torch.save(model_dict, ft_model_path) |
There was a problem hiding this comment.
do the test resources need to be updated for this PR?
There was a problem hiding this comment.
Unfortunately yes, to be able to run the integration tests.
The resources only contain the foundation model, but a finetuned model has a different file architecture and scGPT annotation strictly requires a finetuned model.
| "obsm_gene_tokens": "gene_id_tokens", | ||
| "obsm_tokenized_values": "values_tokenized" | ||
| ], | ||
| toState: {id, output, state -> ["output": output.output]} |
There was a problem hiding this comment.
the final output of this workflow will be an h5mu file with only the hvg files and the predicted celltypes & probabilities, correct?
Would it make sense to revert the h5mu back to the original input, but then copy the new outputs structures (predicted celltypes and probabilities) to the original input data.
Interested to hear your thoughts on this -- I can be convinced to not include this step in this PR.
There was a problem hiding this comment.
You're right, it should't output the file with hvg features only. In the bigger annotation workflow (where combining multiple methods is possible), this output file could be the input of another annotation workflow, where no hvg subsetting is desired.
I'm tempted to include the HVG subsetting logic inside the annotation component (it's also the case for e.g. scANVI), rather than coing the subsetting in a separate component. Then we can also copy the annotations back to the original input, wdyt?
Changelog
Issue ticket number and link
Closes #xxxx (Replace xxxx with the GitHub issue number)
Checklist before requesting a review
I have performed a self-review of my code
Conforms to the Contributor's guide
Check the correct box. Does this PR contain:
Proposed changes are described in the CHANGELOG.md
CI tests succeed!