Will alevin-fry support custom library structure?

[diyang1354]

Hi,
I'm wondering if alevin-fry can support customized single cell protocols? It would be great if we can change the barcode range and umi range accordingly. Thanks.
Best,
Di

[rob-p]

Hi @diyang1354,

Sorry to have missed this in the discussion! Yes; this is already possible. You can pass custom geometry for the UMI, barcode, and read for subsequent processing with alevin-fry. Strangely, the best documentation for this currently is in the release notes for salmon where this feature was added here. We should add the documentation of this syntax to the documentation proper. Please let me know if you have any further questions about this.

Best,
Rob

[diyang1354]

Thank you so much Rob.
I've found another issue in the doc related to the strandness, and I would be grateful if you'd like to discuss this.
In the doc here, library type is IU for chromium V3. However, in the doc here the library type is ISR for chromium V2. Is there a specific reason to set different library types for these two technologies? It seems that the library structure is exactly the same except for different umi length according to libstruct posted here
The strandness issue really confused me a lot when I try to use alevin with my library.
My library basically looks like this:

I have 150 bp paired-end data. The read 1 comes from the forward strand covering the cDNA. The read 2 comes from the reverse strand and the first 8bp is cell barcode followed by 8 bp umi.
Would my library be ISF then?
Best,
Di

[rob-p]

Hi @diyang1354,

Thank you for bringing this up. I can see how this can be confusing. Let me give a short answer and long answer:

• Short answer : Either library format (IU or ISR) in salmon is OK for both 10xV2 and 10xV3.

• Longer answer : Unlike the original alevin — the library type passed to salmon when generating a RAD file for alevin-fry does not filter out any mappings. Rather, in alevin-fry, any filtering mappings based on strandedness is performed in the generate-permit-list step, via the -d, --expected-ori options. That is, if you pass IU or ISR during creation of the RAD file, you should get essentially the same output. Whether or not you wish to filter out or keep "biological" reads that map in the reverse complement orientation is determined by whether you pass fw or both (respectively) to the alevin-fry generate-permit-list command. We'll try to clarify this further in the documentation.

Best,
Rob