Remove Tecan parameter "area"

[nedru004]

Reference #552. One question I had was "area". This is defined as the distance to travel downward after submerging into the liquid before hitting the bottom. I believe that it is the distance traveled while aspirating a specific volume. It is currently hardcoded in the tecan resources and not calculated based on volume aspirated.

I believe you calculate a height from volume. Some resources seem to have this and some don't?
For example, Cor_96_wellplate_2mL_Vb has "compute_height_from_volume" while Cor_96_wellplate_360ul_Fb doesn't. Is there a default function for rectangular or circular resources? Or do I need to write a function for each resource? What happens close to the bottom of a tube when it is conical?

[rickwierenga]

This is defined as the distance to travel downward after submerging into the liquid before hitting the bottom.

As far as I can tell this is the only place it's used:

pylabrobot/pylabrobot/liquid_handling/backends/tecan/EVO_backend.py

Line 384 in 98ef632

zadd[channel] = round(ops[i].volume / par.area * 10)

it's simple geometry

but you are right, for other robots we simply use the height<>volume functions. there is no default (this would be possible for "flat-bottemed" resources but not possible for U or V shaped bottoms if we don't know the height of this shape. @BioCam found that even when you have some number provided by the oem software, it's not precise enough, and so he sometimes just calibrates height<>volume functions using a polynomial fit.

i am not opposed to default height<>volume functions for flat bottom resources. for others, we have to 1) leave them empty by default, and 2) rely on user-contributed functions.

It's not necessary to move the pipette during the aspiration/dispense. In fact, other robots don't do this by default. On hamiltons, the model is to do it at a fixed height unless the user defines the liquid following distance. I think we should define a similar model for EVO: no move by default, and have the user specify the following distance (optionally using the height<>volume functions we will provide).

also since we are talking about area, looking at the tecan plate resource definitions, it seems every well has its size defined as 9mm (or 4.5mm for 384, 2.3mm for 1536 well plates). This is certainly incorrect, since in PLR the well size refers to the inside of the well (not containing the container walls). It was simply imported as this from evoware. Sometimes, these programs just contain some semi-accurate information, together with hacks built into the program enough to make it work, but not really true to reality. Since our goal is a single universal resource model to rule them all, we need to very precisely and comprehensively describe what everything looks like. That is why we started the PLR Resource Library (PLR-RL) from scratch.

For removing the area attribute, I would make sure every well has the correct size x and y. Together with the CrossSectionType, you should be able to dynamically compute the area.

[nedru004]

Great. I can make some changes. When you say

On hamiltons, the model is to do it at a fixed height

Is that fixed height calculated based on the height of the liquid? How do you not overflow the container if you plunge too far and how do you get liquid from the bottom of the well?

i am not opposed to default height<>volume functions for flat bottom resources. for others, we have to 1) leave them empty by default, and 2) rely on user-contributed functions.

That makes sense and I can try to implement that for tecan.

As for this comment:

also since we are talking about area, looking at the tecan plate resource definitions, it seems every well has its size defined as 9mm (or 4.5mm for 384, 2.3mm for 1536 well plates).

I also saw this and I realized that it was a hack to get the correct span for the pipettes.

ys = int(ops[0].resource.get_absolute_size_y() * 10)

Based on browsing the attributes in plates, would this be "item_dy"?
resource.parent.item_dy? not sure how to extract that information.

[rickwierenga]

Is that fixed height calculated based on the height of the liquid?

bottom of the well. the liquid_height parameter says how far above that you want to go.

How do you not overflow the container if you plunge too far and how do you get liquid from the bottom of the well?

If that might happen, you can use lld or set the liquid height.

ys = int(ops[0].resource.get_absolute_size_y() * 10)

This is actually entirely incorrect, since we can't assume the resources are equally spaced.

At runtime, you don't actually know if the resources are all equally spaced wells, if they are in the same plate or even if they are all wells. You could also imagine aspirating from a single big Trough resource with multiple channels at the same time. Therefore, there is no resource.parent.item_dy. (the item_dy parameter of create_ordered_items_2d is how far equally spaced items are apart, but it's just a utility. At runtime, resources (including containers) can exist in any arbitrary location.

What you get is an ops array, each of which has a .resource. We should get the absolute location of this resource, add any offset that might be applied (op.offset) and then move the channels there.

This code should be refactored.

That makes sense and I can try to implement that for tecan.

Thanks!!