"Miniprep queued?" on GG and Assembly tabs needs to handle failed inoculations or preps

[bthuronyi]

Currently, if an mID has been queued but failed in some way, the "Miniprep queued?" columns for gIDs and aIDs don't reflect this. Instead, if preps occur but failed, the aID/gID should revert back to "need to queue". Defining "failed" here will take some thought/work because it includes cultures not growing and minipreps failing QC (but not sequencing problems).

[evelynqi]

Thoughts: -Should include code for abandon constructs because some abandoned constructs show as "need to queue" -Requeueing minipreps would be difficult because it also depends on having the transformation plates available to innoculate -When minipreps fail, we would need to troubleshoot the error instead of just requeueing the construct. In some cases this means a new aID/gID for the same construct that would need to be queued for minipreps eventually, so I'm not sure the old aID/gID would need to say "need to queue" for failed minipreps...

[evelynqi]

Discussion with B: -runs faster if you added a list to lookup lists and tabulations -should still generate a pipeline task regardless of whether the plate is there or not (the person doing the miniprep could figure that out and manually suggest what to do with it rather than the miniprep just appearing "done".)

[evelynqi]

Update: -In golden gate sheet (DF - Miniprep queued?), where "done" is should have another if statement that looks at whether any of the minipreps queued were good using regexmatch to pull information from the status of the minipreps (in theory, there is not circular logic but it is a concern). -We discussed xmatch($B3,Minipreps_m_Source_ID)>0 replacing len(IFERROR(FILTER(Minipreps_m_Source_ID,Minipreps_m_Source_ID=B6)))>0 but xmatch($B3,Minipreps_m_Source_ID)>0 doesn't work because when xmatch can't find it, there is no index, so it produces an error. We would need an iferror to catch when minipreps of a construct are are not queued yet.

[evelynqi]

https://docs.google.com/spreadsheets/d/1YSqAdAVy6jYu_-Nbnop_aQOGMjjLDXzNKm5-Ur23Pcc/edit?usp=sharing

Turns out I should have just looked at the existing material a little more. There is a col in the Golden Gate and Assemblies sheet that is "Successful miniprep achieved?" (DL)

change: in Golden Gate "Miniprep Queued?" (DF) if(len(IFERROR(FILTER(Minipreps_m_Source_ID,Minipreps_m_Source_ID=B7)))>0,if(len(IFERROR(FILTER(Minipreps_m_Source_ID,Minipreps_m_Source_ID=B7,Minipreps_m_Date_inoculated="")))>0,"queued", "done"), to if(iferror(xmatch($B7,Minipreps_m_Source_ID)>0,FALSE),if(len(IFERROR(FILTER(Minipreps_m_Source_ID,Minipreps_m_Source_ID=B7,Minipreps_m_Date_inoculated="")))>0,"queued",if($DL7="yes","done","need to queue")),

The code works. Example is g605. 3 inconclusive minipreps --previous message in "miniprep queue?" (DF) was "done" -- now is "need to queue". It might be best to say "need to re-queue". Also wanted to add that this changes nothing else except for this cell... I believe the status stays the same so no new pipeline task is added.

---

Same change implemented in the assemblies sheet (BX). change: if(len(IFERROR(FILTER(Minipreps_m_Source_ID,Minipreps_m_Source_ID=B3)))>0,if(len(IFERROR(FILTER(Minipreps_m_Source_ID,Minipreps_m_Source_ID=B3,Minipreps_m_Date_inoculated="")))>0,"queued","done"), to if(iferror(xmatch($B3,Minipreps_m_Source_ID)>0,FALSE,if(len(IFERROR(FILTER(Minipreps_m_Source_ID,Minipreps_m_Source_ID=B3,Minipreps_m_Date_inoculated="")))>0,"queued",if($BY3="yes","done","need to queue")),

This change however is reflected in conditional formatting, where the cell turns green when it says "need to queue".

[evelynqi]

Change conditional to be more relaxed: my previous note noted changes that identified a miniprep being "done" after sequence verification. The new criteria is that at least one miniprep with that aID/gID source has the status "done".

if(iferror(xmatch($B3,Minipreps_m_Source_ID)>0,FALSE),if(len(IFERROR(FILTER(Minipreps_m_Source_ID,Minipreps_m_Source_ID=B3,Minipreps_m_Date_inoculated="")))>0,"queued",if(counta(iferror(filter(Minipreps_m_Construct_name,Minipreps_m_Source_ID=B3,regexmatch(Minipreps_m_Status,"done"))))>0,"done","need to queue")),

[evelynqi]

Implemented into main Clone Coordinate.

[ethanjeon]

wait it's v0.95 now? 😭

[bthuronyi]

wait it's v0.95 now? 😭

I might have moved it thinking it was a different issue -- if this is what you were planning to implement ASAP, definitely go ahead with that!

[bthuronyi]

I merged this code into Status for Assemblies, and also added the criterion that the non-failed miniprep needed to consider minipreps completed needed to have a date purified later than the date when this assembly was last transformed (actually, when plates were last scored).

In doing this, though, I realized an unintended interaction with how we have been handling miniprep sequencing. When an mID came back from sequencing in a way that suggested most/all colonies from that assembly would be bad, I manually marked the other mIDs "Discard (don't use)" or similar in What to do with this. However, the code I just added that @evelynqi worked on now considers those to be failed preps because we are only counting them as "done".

Instead, I think the "completed successfully" criterion that Assemblies / GG uses to check mIDs should be narrower: potentially searching for not "failed!" in the Status is appropriate. The other dropdown options don't suggest a technical problem in doing the preps, but rather problems with the DNA that turned out to be in them. The ambiguous one is "QC issue! (don't use)". We've used it a handful of times (~8 of 3000 preps) for various random reasons, maybe filling in for failed automatic designation in the past.

I kind of want there to be a single unambiguous What to do with this > Status option that identifies preps that failed for technical reasons, and I think that should be the option that contains "failed!". I'll proceed accordingly.

[bthuronyi]

More notes and revisions when checking that new Status gives similar output to old Status:

• Caught a number of examples where a retransformation occurred but was never marked "Ready to queue miniprep" due to no previous date checking -- good!
• "Stalled" in Status is also a failure mode
• "Failed" not "failed" in Status is also a failure mode -- from low concentration measurement

[bthuronyi]

Implemented in Assemblies and Golden Gate tabs. "Miniprep queued?" columns are now redundant -- deleted.