GPL-758 location of the Heron negative controls is always between columns 9 and 16 of our 384 plates

[rl15]

Description
As R&D (Naomi & Louise A) we noticed that the location of the Heron negative controls is always between columns 9 and 16 of our 384 plates, we would also like to see them in 1-8 or 17-14

Who the primary contacts are for this work
Naomi P
Louise A

Knowledge or Stake holders
Other people that may have specific knowledge about this work or have a stake in how it is implemented. e.g. John Smith is an expert on x

Additional context or information
Louise A wrote (06 November 2020 11:03)

Naomi and I noticed that the location of the Heron negative controls is always between columns 9 and 16 of our 384 plates.

We know that originally some wells were avoided on purpose in order to not end up where the QC standard would be. However as far as I understand the process, it shouldn’t prevent the controls to be randomly picked towards the right or left third of a plate (it that correct?). Do you know why the negative controls are never picked into col 1-8 or 17-14?

Beside the new tail process doesn’t require any cDNA quant QC so the constrains on avoiding standard well locations could be lifted to allow complete randomness when choosing controls location. Would it be possible put that in place? Is that a big job?

The positive controls seem to be little bit more random but always gathered together on a 394 plate. Again they could be picked completely randomly like the negative controls now that there isn’t any cDNA QC.

[JamesGlover]

This is slightly redundant for the purposes of heron, as it will be replaced by the automated process. Still useful for other picks though, so I'll have a poke. I have my suspicions.

[JamesGlover]

Original column restrictions seem to have been put in place here:
#2902

[JamesGlover]

Oh wait, no, that's just a bug fix, but still, related.

[JamesGlover]

#2905 is the issue associated with that PR

[JamesGlover]

And the original column restrictions: #2833

[JamesGlover]

So its looking like the main behaviour problems set in when trying to calculate the offset for the second control, which happens to be the negative.

This translates to:

(batch_id / number_of_potential_control_wells) % (number_of_potential_control_wells - 1) 

However...

irb(main):001:0> number_of_potential_control_wells = 96 -24
=> 72
irb(main):002:0> 0.upto(384).map { |batch_id| (batch_id / number_of_potential_control_wells) % (number_of_potential_control_wells - 1) }
=> [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5]

This only increments very slowly.

[JamesGlover]

Got a test in place to make sure the negative controls have as much variation as the positive as batch id increases.

[JamesGlover]

Logic all figured out, but now have a load of failing tests as all the control well positions have moved. 😭 Plans moving forward:

• Update the tests to use the new well positions
• Make sure I don't break any explicit behaviours still being requested
• Adjust the free well constraints. Probably shouldn't remove completely, as may be needed for other pipelines with cDNA quants
• Fix the tests again, as now the controls will move about again
• Refactor pass to help take some steps towards GPL-570 Refactor cherrypick task #2831

Fortunately the last one shouldn't break any tests.

[JamesGlover]

Naomi requesting larger offset between plates in batch. Proposed 50, but selecting prime number 53 to avoid reusing control wells before every well combination has been used. Chasing on possibility of using option B (#2975) as that matches behaviour of Beckman. (Plus is overall simpler)

[JamesGlover]

As well as being a prime, the number needs to not be a factor of the plate size. With 53 this is incredibly unlikely to be an issue, but just in case, we have a fallback, and a final number of 1 if we still have issues. This is probably being overly cautious, but:

1. If we add a new plate size in future we're incredibly unlikely to remember to adjust this code
2. Errors could potentially go unnoticed for a a long time.

[JamesGlover]

Extracting out control layout.