Skip to content

Y25-202 - scRNA Library Prep Chromium BCR and TCR pipeline config #2299

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 10 commits into
base: develop
Choose a base branch
from

Conversation

BenTopping
Copy link
Contributor

@BenTopping BenTopping commented Apr 2, 2025

Closes #2265, #2280

Changes proposed in this pull request

  • Adds scRNA Core Chromium GEM-X 5p BCR and scRNA Core Chromium GEM-X 5p BCR MX pipelines
    • Adds pipeline purposes and bed verifications.
  • Adds scRNA Core Chromium GEM-X 5p TCR and scRNA Core Chromium GEM-X 5p TCR MX pipelines
    • Adds pipeline purposes and bed verifications.
  • Adds custom workflows for BCR and TCR pipelines.

Instructions for Reviewers

Sequencescape PR: sanger/sequencescape#4814
Integration suite PR: https://gitlab.internal.sanger.ac.uk/psd/integration-suite/-/merge_requests/236

Copy link

codecov bot commented Apr 2, 2025

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 81.40%. Comparing base (86dcc97) to head (59638f8).
Report is 102 commits behind head on develop.

Additional details and impacted files
@@             Coverage Diff             @@
##           develop    #2299      +/-   ##
===========================================
+ Coverage    81.04%   81.40%   +0.35%     
===========================================
  Files          476      479       +3     
  Lines        18224    18721     +497     
  Branches       269      283      +14     
===========================================
+ Hits         14770    15240     +470     
- Misses        3452     3479      +27     
  Partials         2        2              
Flag Coverage Δ
javascript 74.86% <ø> (+0.63%) ⬆️
pull_request 81.27% <100.00%> (+0.23%) ⬆️
push 81.06% <100.00%> (+0.01%) ⬆️
ruby 91.79% <100.00%> (-0.10%) ⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

…esenter

- Changes LRC GEM-X 5p TCR/BCR Dil 2 plate creator to use ConcentrationBinnedPlatePresenter
- Updates partial_stamped_plate to accept 'started' request_state for well filter
- Updates WellFilterAllowingPartials filter_requests method to check requests exist, not that the parent plate contains requests
@@ -15,7 +15,7 @@ def filter_by_state(requests)
end

def filter_requests(requests, well)
return nil if well.requests_as_source.empty?
Copy link
Contributor Author

@BenTopping BenTopping Apr 3, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This has been looked at before by @andrewsparkes: e4d9e2f. I don't think the existing behaviour is correct because this checks that the parent well contains the request (source of request is parent well). This means this can only be valid if the parent plate is the first plate in the pipeline (submitted on) and I don't think that is correct? I think it just happens that the other pipelines that use this meet that condition.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Interesting, so it will only work if used in the labware creator configured on the second plate in a pipeline (so that the parent plate is the first plate)? e.g. LBC TCR Dil 1 and LRC GEM-X 5p GE Dil.

This line has been flip flopping back and forth - well.requests_as_source.empty? --> requests.empty? --> well.requests_as_source.empty? and here, back again!

It does seem odd to pass in a list of requests, and then re-requery the requests using well.requests_as_source.

Looks like it's called a bit further down the same file:
filter_requests(well.active_requests&.uniq, well)

Need to think/discuss more

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah we can discuss.
The labware creator was built for a specific plate at a branch point on the cherrypick plate in a specific pipeline, and works for that. It's not been designed to be generic.
I cannot remember why I had to change that line to get it to work though!
active_requests seems to use requests_as_source about 3 or 4 levels of method calls in. it's horribly complicated though.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

for chromium they would create the cherrypick, then do partial submissions on the wells in the cherrypick depending on which of 3 library prep types they wanted to do, hence partials. plus the same well could be submitted for more than one library prep. plus they might come back and repeat.
the well filter is having to filter on request type, library type and state to identify the right wells.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the requests were not in the the aliquots on the cherrypick plate, because as you spotted that is the submission plate, they are in requests_as_source only.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah Katy and I discussed this yesterday and thought it best to create a new labware creator instead of modifying this because at the step we are interested in we aren't using partials so it doesnt make sense to use a partial stamp creator.

@BenTopping BenTopping requested a review from KatyTaylor April 8, 2025 09:48
@BenTopping BenTopping linked an issue Apr 8, 2025 that may be closed by this pull request
2 tasks
@BenTopping BenTopping marked this pull request as ready for review April 8, 2025 09:49
Copy link
Contributor

@KatyTaylor KatyTaylor left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Still need to think about that requests one

@@ -15,7 +15,7 @@ def filter_by_state(requests)
end

def filter_requests(requests, well)
return nil if well.requests_as_source.empty?
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Interesting, so it will only work if used in the labware creator configured on the second plate in a pipeline (so that the parent plate is the first plate)? e.g. LBC TCR Dil 1 and LRC GEM-X 5p GE Dil.

This line has been flip flopping back and forth - well.requests_as_source.empty? --> requests.empty? --> well.requests_as_source.empty? and here, back again!

It does seem odd to pass in a list of requests, and then re-requery the requests using well.requests_as_source.

Looks like it's called a bit further down the same file:
filter_requests(well.active_requests&.uniq, well)

Need to think/discuss more

# |E1| conc=33.7 x10=337 (bin 2) | | | |
# +--+--+--~ +--+--+--~
# |G1| conc=25.9 x10=259 (bin 2) | | | |
class ConcentrationBinnedPlateStamp < StampedPlate
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't like the naming here.
'Binning' means rearranging the samples on transfer into the child plate into new well locations depending on some parameter (by concentration in the original).
'Stamp' means source well = destination well, i.e. A1 to A1, B1 to B1 etc. They are not compatible terms.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah ok I wasn't aware thats what binning meant. The only difference in this labware creator is that it inherits from StampedPlate instead of PartialStampedPlate.

Copy link
Member

@andrewsparkes andrewsparkes left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we discuss this story? You can't have a binned stamp, so confused what you are trying to do.
Does the original not work for you? it just looks for wells with the right request type (partial submissions for the original pipeline). But if all the wells have the right request won't it just take them all? Assuming that's what you are after.

@BenTopping
Copy link
Contributor Author

BenTopping commented Apr 16, 2025

Can we discuss this story? You can't have a binned stamp, so confused what you are trying to do. Does the original not work for you? it just looks for wells with the right request type (partial submissions for the original pipeline). But if all the wells have the right request won't it just take them all? Assuming that's what you are after.

Yes sure. The only difference in this new labware creator compared to the existing one (ConcentrationBinnedPlate) is that it inherits from StampedPlate instead of PartialStampedPlate. This is because partial stamped plate uses a well filter that checks the parent plate is a submitted plate (start of the pipeline / has requests_as_source present). Which this pipeline does not match because we are doing this concentration binning half way down the pipeline. So in essence its the same but we are just changing the wellfilter logic to suit via StampedPlate instead.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
3 participants