Add cellhash demux results

[jashapiro]

This PR adds the basic demux results from cellhash tables to the script integrating multiplexed data.

It does this by adding flags to the add_demux_sce.R script to indicate whether the demultiplexing should be performed, along with the option to include a file containing a table of the cellhash sample ids. That file is found in the new cellhash_pool_file param, which is set in the ccdl profile.

This file is not currently documented, so we should probably add that either before merging or as a next step, which might include more documentation about running multiplexed samples.

One other future thought is that while we don't currently have any samples that don't have cellhash data, that is possible. It is also possible (maybe more likely?) that we could get cellhash samples without matched bulks samples for genetic demultiplexing. Right now the workflow doesn't really support that at all. Changing that is probably also related to #100.

Leaving this as a draft for now.

[jashapiro]

Updating with some comments on the way this has changed since the initial draft:

• I am using the same single R script as before, but I have split adding the cellhash demux and the vireo integration into two separate processes. This allows me to do the cellhash demux results first, right after the feature mapping happens. The main reason for this is that it may (in the future) allow more flexible handling of the case where we might not have bulk RNA-seq data for a multiplexed sample. For now, it has the benefit of working with mulitplexed samples that don't have cellhash data (which we also don't have, but it should work!).
• I split feature_techs into two separate lists, again for more potential flexibility later. I actually thought I was going to use that to sort out the feature samples with cellhash data, but I ended up using the feature_type flag that gets set in the metadata as part of the generate_merged_sce process, so there may not be any benefit to this, but I left it anyway.

[allyhawkins]

This looks good to me. I just had one minor suggestion about staying consistent with the use of the cellhash_techs, but I'm not 100% sure if that will work as I think it will. I'm also not crazy about the organization of the addition of processes where the demux results are added to the SCE's being incorporated to the same script where there is generation of SCEs and filtering, since now things are definitely not as linear as they used to be, but I can't think of a better option since they are all related to sce processing.

[allyhawkins]

Suggested change

	cellhash: it[0]["feature_type"] == "cellhash"
	cellhash: it[0]["technology"] in cellhash_techs

Would you maybe be able to do this instead? I just found it generally confusing to map back where this was coming from while being able to use the cellhash_techs that you defined earlier seems like it would be cleaner.

[jashapiro]

Unfortunately, this won't work (this was what I tried to use first!). meta.technology is set for the "primary" technology after we add feature data, so it is just 10Xv3 or whatever. generate_merged_sce adds meta.feature_type, which retains the kind of feature that us in the altexp of the SCE, so we have to use that.

I could maybe modify generate_merged_sce to add feature_technology without changing the string... that might be a better solution, come to think of it... I will try that.

[jashapiro]

Alternatively, I could use it[0]["feature_meta"]["technology"] as that is already set by the generate_merged_sce workflow (all of meta from feature mappings ends up in meta.feature_meta when the objects are combined). Do you have any thoughts on which is less confusing?

[allyhawkins]

I think that option makes sense (or at least to me). That way you would be able to do it[0]["feature_meta"]["technology"] in cellhash_techs correct? What was originally confusing to me was where the value of cellhash was coming from.

[jashapiro]

Yes, that is what it would be. I will test to make sure it works as expected.