I'd like to get back to the notion of high-level protocols defined in terms of things like mixes, dilutions, thermocycling, and extraction (#48), with the actual placement determined automatically (though preferably deterministically).
To support compilation of protocols, I think I need an intermediate level between them and Paths, which I'm currently calling a Script. A Script can have multiple Phases, each of which has a number of Paths that can be performed sequentially or concurrently, each Path starting from a Well, and ExtractionPoint, or a Drop held over from a previous Path (likely in a previous Phase), and each Path either winding up in a Well or ExtractionPoint or becoming usable by the next Phase. A Phase may also have a set of Barriers and Triggers to assist in traffic control.
A Script can be run alone, pipelined, or multiply in parallel, parameterized to run in different sections of the board.
This would probably be simplified by the existence of Walkways (#53).
The overall idea is that a Protocol would compile down into a Script, figuring out placement and routing, and the Script would then be run. It would probably also be reasonable for a Script to be able to output itself as Python code (as a Task) to be imported and run. (This would guarantee determinism of compilation.) Scripts could also be the compilation target for special-purpose protocol languages, although it may be better off to go through the extra step of generating a Protocol object and compiling it to a Script.
Once Scripts are implemented, we will want to test them out by recasting the PCR protocols (CombSynth, Prepare, and MixPrep) using them.
Migrated from internal repository. Originally created by @EvanKirshenbaum on Oct 03, 2022 at 11:42 AM PDT.
I'd like to get back to the notion of high-level protocols defined in terms of things like mixes, dilutions, thermocycling, and extraction (#48), with the actual placement determined automatically (though preferably deterministically).
To support compilation of protocols, I think I need an intermediate level between them and
Paths, which I'm currently calling aScript. AScriptcan have multiplePhases, each of which has a number ofPaths that can be performed sequentially or concurrently, eachPathstarting from aWell, andExtractionPoint, or aDropheld over from a previousPath(likely in a previousPhase), and eachPatheither winding up in aWellorExtractionPointor becoming usable by the nextPhase. APhasemay also have a set ofBarriers andTriggers to assist in traffic control.A
Scriptcan be run alone, pipelined, or multiply in parallel, parameterized to run in different sections of the board.This would probably be simplified by the existence of
Walkways (#53).The overall idea is that a
Protocolwould compile down into aScript, figuring out placement and routing, and theScriptwould then be run. It would probably also be reasonable for aScriptto be able to output itself as Python code (as aTask) to be imported and run. (This would guarantee determinism of compilation.)Scripts could also be the compilation target for special-purpose protocol languages, although it may be better off to go through the extra step of generating aProtocolobject and compiling it to aScript.Once
Scripts are implemented, we will want to test them out by recasting the PCR protocols (CombSynth,Prepare, andMixPrep) using them.Migrated from internal repository. Originally created by @EvanKirshenbaum on Oct 03, 2022 at 11:42 AM PDT.