Standardized labware naming convention discussion

[CamilloMoschner]

@rickwierenga

I think Resource library is best, because it’s broad and because the base class in PLR is already called Resource.

Perfect, then I will try to only use this term, and the pylabrobot/resources/README.md documentation is already named like that as well

@rickwierenga

@CamilloMoschner

Note: I suggest adding unit tests to flag new resource definition submissions that do not follow the PLR naming convention - if we want to enforce consistency as opposed to recommended “best practices”.

Agree for resources in a well-defined set of libraries. In the general case, as a general principle, we should be flexible, and only constrain on what is physically impossible.

I understand; so we do not want to make any naming convention compulsory but only have recommended naming conventions?

@rickwierenga

Nothing prevents you from assigning the LiquidHandler itself to a higher level object like Lab or Workcell in an encompassing coordinate space. (actually, get_absolute_location may prevent you, but I want to refactor that to get_absolute_location(in:))

Absolutely love this and can’t wait for the refactor

@rickwierenga

Plates

@CamilloMoschner

(MTP: “micro-titer plate” [=<500ul]; DWP: “deep-well plate”; reservoir; MWL: “multi-well plate”)

What is the difference between these? Why is not every plate a multi-well plate?

That is an excellent question… this is taken from Hamilton nomenclature.
I guess there is a point to saying this is closer to everyday-language in the lab where DWP is a common acronym, but there is a reason why Opentrons seems to have chosen against his nomenclature.
My best guess is, like you mention, every plate is a wellplate (as Opentrons puts it).
I also had to dig quite a bit to find somewhere that gave the arbitrary distinction of “micro-titer plate” [=<500ul].

Okay, let’s remove _MTP_ and _DWP_ from the discussion board.

Next question: Should we then simply adopt the Opentrons plate naming convention and add the bottom type to the end?:
e.g.: ThermoScientific_96_wellplate_1200ul_Rd

Should manufacturer abbreviations be acceptable?
e.g.: Cos_96_wellplate_2mL_Vb (instead of Costar_96_wellplate_2mL_Vb)

@rickwierenga

PLR labware is actually defined as functions, that return an instance of a class (they used to be classes, a long long time ago.)

That’s why I wrote “represent”, i.e. I meant the capital letter of the function represents the data type it returns

@rickwierenga

Carrier (- MFX)

About the “version” part of the name (A00, A01): preferably we reach a consensus resource in PLR that works for everyone. If this refers to version of resource definition (with a fixed underlying resource), I agree we should just keep the latest version.

But what if a manufacturer has two version of the carrier with the same specifications? This could be a new version of a product they already have. In that case, perhaps PLR should add V2 etc.?

I agree. Do you think we should remove sample and reagent carriers, @rickwierenga ?

Sample carriers (i.e. carriers for tubes) are even in VENUS defined as racks and I am inclined to do the same in PLR, i.e. make them TubeRacks.

Reagent carriers… I am not sure. All these should be able to do is take Troughs / reservoirs as children in pre-defined sites.

@rickwierenga

We should have “building blocks” that you see in the MFX program (camillo has already contributed two), but construct the higher level “module” at runtime. I guess in a way this is similar to other resources in PLR, which are just classes instantiated at runtime.

I mean to say this is different from the hamilton MFX program, which exports specific definition files for each configuration. Not a problem for specific users, but not a general solution for us.

Thanks Camillo for illustrating the niceness of this with code.

You are welcome. You guys created a wonderfully simple and fast definition system here.

@evwolfson, you might not want to explicitly declare all of this every single time you write a new protocol.
PLR got you covered here too. The above example of a carrier instantiation can also be stored wherever you want as…

def special_carrier():
    mfx_carrier_1 = MFX_CAR_L5_base(name='mfx_carrier_1')

    # Assign DWP_modules
    mfx_carrier_1[0] = DWP_module_1 = MFX_DWP_rackbased_module(name="DWP_module_1")
    mfx_carrier_1[1] = DWP_module_2 = MFX_DWP_rackbased_module(name="DWP_module_2")
    
    # Assign TIP_modules
    mfx_carrier_1[2] = TIP_module_1 = MFX_TIP_module(name="TIP_module_1 ")
    mfx_carrier_1[3] = TIP_module_2 = MFX_TIP_module(name="TIP_module_2")
    mfx_carrier_1[4] = TIP_module_2 = MFX_TIP_module(name="TIP_module_3")
    return mfx_carrier_1

special_carrier_instance = special_carrier()
lh.deck.assign_child_resource(special_carrier_instance, rails=14)

…and then simply imported into your protocol as a pre-designed carrier configuration

But as Rick said, PLR is giving the “building blocks”, due to the combinatorial explosion of MFXModules available, it is up to users to create these special configurations themselves and import them / define them as users want.

@rickwierenga

Meta data / documentation

+1 on Florian’s searchability.

Unless meta data is needed at runtime, I think this information should go in the documentation. I am not a huge fan of resource_metadata tbh, because it’s not a functional or readable field. This documentation can be in the doc string (useful!) and extra information can go in supporting files.

I understand, and agree on the runtime need part and that therefore I agree this information is not needed as a class attribute.
I can write a docstring guide that includes a template for different Resources to accelerate information addition to new definitions by users.

@rickwierenga

Actionable todo for me:

• I shall write a script to include in the doc-making process (already automated) that goes through the pylabrobot.resources submodule and copies all README files into the docs folder. They will then be included in the HTML exports.
• I will use the resource-converter script for the venus and tecan and opentrons labware libraries to create READMEs for all resources there. This will dramatically expand the documentation.

That is a fantastic idea. Thank you, @rickwierenga!

I have had a couple of occasions where I was interested in a VENUS-originated plate definition, but I had to abandon using it because I could not figure out what manufacturer and/or catalogue number it was.
These definitions are therefore arguably wasted code space.
Documentation that associates every Resource definition at least with its manufacturer and catalogue number will prevent this from happening in the future.