GPL-871 - quadrant metadata q0-3 (PSDTHV) [C=M, V=4*]

[KatyTaylor]

Describe the bug Metadata relating to which parent plates were the sources for which quadrants of a 384-well plate is 0-indexed in the Beckman process, but not on the previous (Sentinel) process. It causes confusion in the lab, as if you refer to 'quadrant 2', you would mean a different one depending on whether they are 0 or 1 indexed.

Reported by Anna G:

This problem can be seen on every Beckman pick in Sequenscape – plate summaries Here is an example http://sequencescape.psd.sanger.ac.uk/plate_summaries/HT-111183 It’s at the bottom and the information is from creation of LTHR -384 RT Q

Additional Information In the Sentinel process, the metadata is created by the Sequencescape quad stamping page: See quadrant_metadata_collection method in quad_creator.rb (Sequencscape repo)

SELECT cm.key, cm.value, l.`id`, l.created_at, l.name, p.name
FROM custom_metadata cm
JOIN custom_metadatum_collections cmc ON cm.`custom_metadatum_collection_id` = cmc.`id`
JOIN labware l ON cmc.`asset_id` = l.`id`
JOIN plate_purposes p ON p.id = l.`plate_purpose_id`
WHERE p.name = 'LTHR-384 RT'
ORDER BY l.created_at DESC
LIMIT 100;

Gives outcome such as:

key	value	id	created_at	name	name
Quadrant 3	DNxxxxxx1	1	23/01/2021 15:00	Plate DNxxxxxxA	LTHR-384 RT
Quadrant 4	DNxxxxxx2	1	23/01/2021 15:00	Plate DNxxxxxxA	LTHR-384 RT
Quadrant 1	DNxxxxxx3	1	23/01/2021 15:00	Plate DNxxxxxxA	LTHR-384 RT
Quadrant 2	DNxxxxxx4	1	23/01/2021 15:00	Plate DNxxxxxxA	LTHR-384 RT
Quadrant 1	DNxxxxxx5	2	23/01/2021 14:47	Plate DNxxxxxxB	LTHR-384 RT
Quadrant 2	DNxxxxxx6	2	23/01/2021 14:47	Plate DNxxxxxxB	LTHR-384 RT
Quadrant 3	DNxxxxxx7	2	23/01/2021 14:47	Plate DNxxxxxxB	LTHR-384 RT
Quadrant 4	DNxxxxxx8	2	23/01/2021 14:47	Plate DNxxxxxxB	LTHR-384 RT

In the Beckman process, the metadata is created by the Limber quad stamping page: add_stock_barcode_metadata / ‘stock_barcode_from_quadrant’ in quadrant_split_plate.rb (Limber repo)

SELECT cm.key, cm.value, l.`id`, l.created_at, l.name, p.name
FROM custom_metadata cm
JOIN custom_metadatum_collections cmc ON cm.`custom_metadatum_collection_id` = cmc.`id`
JOIN labware l ON cmc.`asset_id` = l.`id`
JOIN plate_purposes p ON p.id = l.`plate_purpose_id`
WHERE p.name = 'LTHR-384 RT-Q'
ORDER BY l.created_at DESC
LIMIT 100;

Gives outcome such as:

key	value	id	created_at	name	name
stock_barcode_q0	HT-000001	5	22/01/2021 16:54	Plate DNxxxxxxE	LTHR-384 RT-Q
stock_barcode_q1	HT-000002	5	22/01/2021 16:54	Plate DNxxxxxxE	LTHR-384 RT-Q
stock_barcode_q2	HT-000003	5	22/01/2021 16:54	Plate DNxxxxxxE	LTHR-384 RT-Q
stock_barcode_q3	HT-000004	5	22/01/2021 16:54	Plate DNxxxxxxE	LTHR-384 RT-Q
created_with_robot	Pre Bravo 1	5	22/01/2021 16:54	Plate DNxxxxxxE	LTHR-384 RT-Q
stock_barcode_q0	HT-000005	6	22/01/2021 14:44	Plate DNxxxxxxF	LTHR-384 RT-Q
stock_barcode_q1	HT-000006	6	22/01/2021 14:44	Plate DNxxxxxxF	LTHR-384 RT-Q
stock_barcode_q2	HT-000007	6	22/01/2021 14:44	Plate DNxxxxxxF	LTHR-384 RT-Q
stock_barcode_q3	HT-000008	6	22/01/2021 14:44	Plate DNxxxxxxF	LTHR-384 RT-Q
created_with_robot	Pre Bravo 1	6	22/01/2021 14:44	Plate DNxxxxxxF	LTHR-384 RT-Q

Consider: if the metadata key recorded by one or other of these pages is changed, consider whether to do a data migration to alter historical data to match.