Remove drops that disappear from DML variables

[EvanKirshenbaum]

Writing up the work on futures (#283), I realized that for merge operations (and probably things like extractions and well entry), I should probably actually remove the drop from any variables that contain it. This would mean calling reset() on future drop variables and setting drop variables to MISSING. To track this, we'll need to keep track, probably in the drop, of all of the environment/variable combinations that contain it. This should probably be kept as a WeakKeyDictionary[Environment, list[str]] hung off the Drop. This will allow the environments to disappear if the drops outlive them.

Originally posted by @EvanKirshenbaum in https://github.com/HPInc/HP-Digital-Microfluidics/issues/282 [comment by @EvanKirshenbaum on Jul 06, 2023 at 2:22 PM PDT]

Migrated from internal repository. Originally created by @EvanKirshenbaum on Jul 06, 2023 at 4:37 PM PDT.

[EvanKirshenbaum]

Thinking about this a bit more, what might make more sense is to change Drop.status to be a MonitoredProperty with a change handler filtered to trigger when the value becomes DropStatus.OFF_BOARD.

Then, when a drop is assigned to a variable, it can add a callback that holds the name and a weak reference to the environment (for non-future variables) or a weak reference to the FutureValue for future variables. When it fires, the variable or FutureValue is cleared. Special care will have to be taken when a new value is asserted, as the callback will have to be removed from the old value's callback list.

Migrated from internal repository. Originally created by @EvanKirshenbaum on Jul 06, 2023 at 4:42 PM PDT.

[EvanKirshenbaum]

One of the messy things is going to be that when it comes to merging and processes that involve repeated mixing and splitting, with inferred drop motion, it becomes difficult to maintain identity correctly.

• When you do a merge (#262), you need to make sure that the resulting drop is the one being merged into, not the one merging.
• When you run a mix/split process, you'd like the drops that reappear to get assigned to the same variables (and, in fact, be the same drops) that were there to start.
  • Probably the best way to handle this is to annotate the Pad with "This is the drop I expect to show up here, eventually", and when the motion says that a pad now has a drop, it uses that one and reasserts it. Also, when the status goes back to "on board", the change callbacks should reassert the drop in any (still-empty) variables that contained it before it went away.

This will either simplify or greatly complicate the drop motion inference.

Migrated from internal repository. Originally created by @EvanKirshenbaum on Jul 06, 2023 at 5:00 PM PDT.

[EvanKirshenbaum]

While I'm thinking about it, the whole notion of DropStatus was a kludge to be able to capture the question of why a drop didn't have a location in order to have it reappear correctly when it came to processes. In the current code, it's pretty much just either ON_BOARD or OFF_BOARD (with the exception of WellPadMonitor.current_drop, which doesn't appear to be used), so it probably makes sense to simply make Drop._pad be an Optional[DropLoc] with an on_board property that checks to see whether it's None, with a change monitor filtered to leave out changes where one side or the other isn't None.

Migrated from internal repository. Originally created by @EvanKirshenbaum on Jul 06, 2023 at 5:11 PM PDT.