Y25-025 - Maintain customer-requested number of repeats [DRAFT]

[KatyTaylor]

User story

As a user of the scRNA Core pipeline, I would like the 'number of cells per chip well' to be adjusted at point of pooling, if there have been well failures, so that the number of repeats and cell counts that were possible at submission are still achievable.

This is so that we can still deliver the service that was requested as much as possible - we believe it's more important that the number of repeats and cell counts is maintained, rather than number of cells per chip well. Also so that we don't have to go back to the customer at this point, because we cannot pause the pipeline.

Who are the primary contacts for this story

Katy, Abdullah, Abby

Who is the nominated tester for UAT

Abby

Acceptance criteria

Consider if these features can be featured flagged to decouple testing and deployment.

At point of cDNA prep submission (Sequencescape):

• Calculate the "allowance band" and save into a new field on request metadata. Allowance band can be:
  • "Full allowance" (or "2 pool attempts, 2 counts")
  • "2 pool attempts, 1 count"
  • "1 pool attempt, 2 counts"
  • "1 pool attempt, 1 count"

See further down for calculations.

When creating LRC PBMC Pools plate (Limber), after calculating the number and size of pools, for any pools with 5-8 samples:

• Check what the original "allowance band" met at point of submission was (request metadata - it should be the same for all requests in the pool)
• Calculate whether there is still enough material to meet the same allowance band (will only have changed if there have been well failures). (Technically, no need to check if the original band was "1 pool attempt, 1 count" - see additional context.)
• If not, the 'number of cells per chip well' to be used going forward (for each pool) is not taken from the value requested in the submission, but instead selected from the table below:
  
• As is done currently, the selected 'number of cells per chip well' is saved into polymetadata for each pool - this is necessary even if we are using the requested value from the submission.

Dependencies

This story is a change to / enhancement of #1992

"Allowance band" calculations:

There is already code in the submission upload that calculates whether there will be enough material for the "full allowance" (one of the bands) - added in story sanger/sequencescape#4460.
See Calculations section of that story for how.

The calculations for the other bands are similar:

"Full allowance" = ( "Chip loading volume" * 2) + (2 * 10) + 5
"2 pool attempts, 1 count" = ( "Chip loading volume" * 2) + 10 + 5
"1 pool attempt, 2 counts" = "Chip loading volume" + (2 * 10) + 5
"1 pool attempt, 1 count" = "Chip loading volume" + 10 + 5

Additional context

It is only possible for someone to request '1 pool attempt, 1 count' if they only want 5 samples/pool (>5 samples/pool and the max cells/chip well of 90K always results in at least '1 pool attempt, 2 counts' or more).
If 1 sample then failed the whole run would become no longer viable so we don't have to adjust any values for this, the fail would be captured by the <5 samples/pool flag.

If there was not enough at submission that would be caught by our restrictions to no. cells/chip well and samples/well size. If there was not enough at pooling recheck that would only be due to not enough samples/well which would fail as mentioned.