Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
RFC: prototyping papi transfer + engine core + pe load liquid class #16602
base: edge
Are you sure you want to change the base?
RFC: prototyping papi transfer + engine core + pe load liquid class #16602
Changes from all commits
2b00b61
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
Large diffs are not rendered by default.
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.
having the pipette id and tiprack id in here doesn't seem right to me. It means the command orchestration layer has to do a bunch of extra work to load the full liquid class and tie it back to a possibly-generated ID for the relevant pipette. It seems better to have the command take in the full liquid class, and then later when the command orchestration layer references the LC in a command like
aspirate
the engine is the one to verify that the LC has properties for the pipette specified by ID in the aspirate and the tip that pipette is using and pulls the right kind of properties.Also is
tiprackId
an engine instance ID? or is it a labware URI? If it's an instance ID, wouldn't you have to load a huge number of liquid classes?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.
You're totally right. Going to change this to accept the liquid class as is, and the engine then saves only the properties related to the pipette ID & tiprack uri in question. I want the engine to save only relevant parts of the liquid class so that the run summary doesn't get bloated because of parts of the liquid class that will be irrelevant not just to the transfer in question but the entire run. This will be definitely useful when handling built-in liquid classes which will have properties corresponding to all pipette+tiprack combos we support.
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.
Even trimming out unnecessary stuff strikes me as a bit of a premature optimization. IMO if we're going to put the data in the engine, we should put the entire data in the engine. Sure, the liquid classes are big, but you're gonna be using like 1-10ish of them per protocol, right?
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.
So, unlike other definitions like labware and modules, liquid class properties are going to be mutable. If the engine were to save the entire liquid class, then every time there's a change to the properties for a specific pipette+tip combination, the snapshots of the entire liquid class will need to be updated. If we save split properties per pipette+tip combination then only the snapshot of the specific combo will need to be updated.
But I understand your point about pre-mature optimization; maybe the optimization above isn't worth the code bloat. I'll change this to saving complete liquid class and if we run into the above issue more often than we'd like to then I'll add the optimization.
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.
Hey @sfoster1, I don't know if saving the entire LiquidClass is a good idea, and trying to save the whole thing is making me struggle with how to represent the data in the PE.
So LiquidClass starts out with the RECOMMENDED settings for every possible pipette and tip type, right? So it looks something like:
But for any given transfer, the user can customize the settings. So the user's code is going to look something like this:
Inside the implementation of
transfer_liquid()
, Sanniti is going to upload the settings for that transfer onto the PE. In her original proposal, she would upload something like this to record the settings we actually used:With your proposal to store the entire
LiquidClass
, Sanniti would have to upload the settings for every possible pipette/tip for every transfer, even though only one of the pipettes is used for each transfer. Semantically, I don't know what it means to store the settings for the all pipettes we did NOT use (especially since we would probably have modified the settings if we HAD used those pipettes instead).And in terms of implementation, if we have to store the entire
LiquidClass
, but we also want to know what settings were used for each particular transfer, then Sanniti wants me to build a fancy mechanism to compare theLiquidClasses
from transfer to transfer and assign a new UUID to each distinct version of theLiquidClass
we used (AUTH-851). It might make my life easier if we only had to store the settings we actually used for each transfer like in the original proposal here.