-
Notifications
You must be signed in to change notification settings - Fork 8
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
base: develop
Are you sure you want to change the base?
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
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
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
…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? |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
…c_gem_x_5p_bcr_enrich2_2xspri_to_lrc_gem_x_5p_bcr_dil_2 and hamilton_lrc_gem_x_5p_tcr_enrich2_2xspri_to_lrc_gem_x_5p_tcr_dil_2
There was a problem hiding this 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
config/pipelines/high_throughput_scrna_core_library_prep_chromium_bcr.yml
Outdated
Show resolved
Hide resolved
@@ -15,7 +15,7 @@ def filter_by_state(requests) | |||
end | |||
|
|||
def filter_requests(requests, well) | |||
return nil if well.requests_as_source.empty? |
There was a problem hiding this comment.
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
… handle mid-pipeline concentration binning labware
# |E1| conc=33.7 x10=337 (bin 2) | | | | | ||
# +--+--+--~ +--+--+--~ | ||
# |G1| conc=25.9 x10=259 (bin 2) | | | | | ||
class ConcentrationBinnedPlateStamp < StampedPlate |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this 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.
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. |
…ous config from scrna core library prep
Closes #2265, #2280
Changes proposed in this pull request
scRNA Core Chromium GEM-X 5p BCR
andscRNA Core Chromium GEM-X 5p BCR MX
pipelinesscRNA Core Chromium GEM-X 5p TCR
andscRNA Core Chromium GEM-X 5p TCR MX
pipelinesInstructions for Reviewers
Sequencescape PR: sanger/sequencescape#4814
Integration suite PR: https://gitlab.internal.sanger.ac.uk/psd/integration-suite/-/merge_requests/236