Database storing common Labware (DWPs, etc.) specifications

I agree with @smohler, unfortunately I couldn’t make last night’s discussion but I too have the same worries. Slack is for communication but not for storage of definitions like this. Github or something like this is the best way forward- it is peer reviewed, versioned, public and searchable. It also exposes public URLs for downloads that can be used in scripts etc.

As I said, Slack is fine for communication and organisation, but surely it would make sense to have a subforum here for that purpose here?

I believe my earlier communication was insufficiently clear. I agree with everything said about open community processes and the importance of durable records. In my experience, it is also valuable to have different fora for different “speeds” of communication.

  • Synchronous meetings for in-depth tech wrangling
  • Instant messages (e.g., Slack) for organization & chat
  • Durable open list / forum (e.g., here or a google group) for technical discussion, announcements, and community building
  • Git or similar for actually maintaining any open technical artifact (code, data, or other)

The Slack channel is for getting things coordinated as a group; beyond that is all still as yet unformed.

2 Likes

Don’t forget www.draw.io or thelike for generating database relationship diagrams or diagrams in general!

1 Like

This is an interesting topic for Genie Life Sciences because it’s something we’ve been discussing and, as time permits, working towards. Even though we manufacture our own liquid handler, it’s always been our goal to keep our software platform instrument agnostic, so we can run the same protocols on various liquid handlers. One of the things this, of course, requires is an instrument agnostic labware definition. One of Genie’s components is the “Catalog Service”, which stores all labware (plates, tip racks, tubes, tube holders, lids, risers, magnets, etc.), including height rules on labware stacking. We’re a SaaS platform so whenever we publish a new labware, it’s immediately available to all customers. We’ve also successfully translated our labware definition to other liquid handlers (if your model is decent, these transformations are typically very easy to do).

The question I am now asking myself is whether we should enable open access to our Catalog Service so others can post new labware and download existing labware. It’s some work for us, but if there’s a true demand for this it’s really tempting to just do.

In either case, from my experience, here’s what is needed for a good labware model:

  • Dimensions, wells, well depth, tip minimums and maximums, etc. are all a given. I’ve looked at several models in the past and most vendors do between an OK and pretty good job at this.
  • Irregular labware support. Not everything is an N by M grid and not all wells have the same depth.
  • Estimated liquid level (e.g. if I have 20 ul in the well, what is the well offset). There was some discussion about this. The approach we took is to have a lookup table. It’s as reliable as you want it to be and definitely much more reliable than a math function since wells don’t always follow a perfect geometric shape.
  • Camera support (mostly because GLS has a built-in camera)
  • Stacking rules. When you put labware A on labware B, the combined height is not A+B.
  • Accessibility constraints – this is a really annoying one because it’s liquid handler specific, but some liquid handlers cannot access some wells with some of their channels when the plate is in specific deck locations (e.g. first row).
  • Gripper support (we didn’t do this yet because we haven’t had any trouble determining the right offset algorithmically as a function of the labware height)
  • Versioning. People may adjust labware definitions over time (e.g. they made a mistake) but if you’re already using the old definition, even if it’s broken, you don’t want to get the newest definition without explicitly choosing to update to a newer version. Without versioning the service’s reliability is lost.

I also believe that a cloud service is a far better way to go than a static repository. People should be able to publish labware definitions publicly (anyone can use it) or privately (only their company can use it). It would be good to have usage counts or ratings of some kind to indicate the maturity of a labware’s definition. Kind of like what npmjs is for JavaScript libraries.

6 Likes

Please do make your catalog available under a FOSS license!

As a community, we really need to be able to unify and harmonize across the disparate catalogs being built by you, by OpenTrons, by Strateos, by ECL, by etc., etc.

I see cloud vs. repository as a false dichotomy - if you have a good representation, you can have an integrated approach with views in different formats, as is often done with biomedical ontologies. In every case, however, there is a necessity for some sort of version control and review process.

2 Likes

It would be good to have usage counts or ratings of some kind to indicate the maturity of a labware’s definition.

I think peer review is the term here that we need to adopt. Here’s a definition that we’ve found to be optimized pretty well for this range of volumes and it has been tested and used by X,Y,Z.

Something this small can go a long way toward democratizing our shared knowledge.

1 Like

Excellent comment. I think that many if not the most important problems are mentioned here.
I was wondering, do you find disregarding well geometry and taking the lookup tables as you sugguest really that helpful? I assume it will be hard to standardize the offset measurement procedure: 1) The measured offsets will depend on the teaching accuracy, 2) liquid level sensing will probably not be instrument-agnostic and so the accuracies will also vary 3) liquid level sensing is not too accurate in the first place, is it? 4) laboratories differ in their “standard” temperatures and the same liquid will thus have different densities 5) and maybe other problems.

There’s automatic liquid level sensing, whether using conductive tips or air pressure. Most of my experience is with pressure based liquid level detection because that’s what the Genie liquid handler is using. I found it to be super accurate (as long as you don’t re-use tips). I suspect using conductive tips is also very accurate (note that it doesn’t work with some liquids) since a lot of the commercial liquid handlers use that technology. Good automatic liquid handling doesn’t, IMO, need any hints from the labware definition beyond maybe bottom of well and top of well locations.

The liquid detection I am referring to is “estimated liquid level”. If you know how much volume is in a well and the well’s geometry, it’s possible to estimate the liquid level. It will not as accurate as automatic liquid level detection, but it will be faster and is the right approach for some use cases. At Genie we automatically keep track of labware state (e.g. if you have a transfer that moves liquid from one plate to another, we automatically update the state of the labware with the amount of liquid that is removed and/or added) so using ELL is pretty simple without any additional work.

Here we need to start with some assumption about instrument accuracy. If the instrument, for example, cannot accurately move to well bottom + 1 mm, then things just won’t be accurate, regardless what you do. Our labware definition has a small lookup table of volume to offsets from well bottom, so for a particular well 50 ul may out you at 1.44 mm, 100 ul at 2.88 mm, etc. If a volume falls in-between an entry (e.g. 72 ul), then you just do a linear difference between the two points. The neat thing is that these tables don’t need to be large. If a well is fairly regular you’d only need 3-4 entries and if it’s highly irregular, then at most an entry per mm in height. I believe the overall accuracy of this approach is +/- 2mm (partly due to how it’s measured, whether the liquid level is bulging out or in, temperature, etc.).

We measure using water at room temperature. We measure using our liquid handler or, at times, by hand with an electronic pipette. Yes, all of these things have an aggregated affect, but it’s not an approach that will ever be perfect. You just need to acknowledge the precision of ELL, which I put at +/- 2mm.

2 Likes

As Denis said, this is something we’ve always wanted to do at Genie. It aligns very well with our vision for lab automation.

Is anyone interested in a virtual meet-up on this topic? We’d love to discuss what we currently have in our Catalog Service, and what people are looking for if we were to make this available. We want this feature to be as useable as possible for Automation Engineers, and rely on feedback for what’s expected/needed.

If anyone’s interested in a brief 30-min virtual meeting the last week of September, feel free to reply and I can coordinate!

Hi Christine, I and surely others would love to join. We already had a meeting with a couple people in here and it was great. We also decided to discuss things on this Slack: Slack. Next meeting was planned to be around next week, but we could additionally meet end of this month.

Hello, all! To find a good time for an ongoing biweekly meeting, starting next week, I have set up a when2meet poll. If you are interested in participating in labware catalog development, please indicate when could work for you for meeting once every two weeks: Biweekly Labware Meeting - When2meet

1 Like

Based on the responses to the poll, we will be meeting biweekly starting this Thursday, September 29th at 1pm Central / 2pm Eastern / 11am Pacific / etc. I have sent at calendar invitation to all poll respondents whose email address I could find. If you would like to be invited, send me a DM. The invitation information is also posted in the #collab-labware-database channel on the Bits-in-Bio Slack (See: https://bitsinbio.org/)

1 Like

Hi everyone, just wanted to chime in here and talk about how we solved in this in PyLabRobot.

We provide a very lightweight, hardware agnostic resource model as a part of the library. The idea here is that the Resource class and its subclasses capture all data and functionality that a resource has in an abstract way. When we added support for the Opentrons, we could immediately use all resources we imported from Hamilton’s VENUS. I talk about this a little bit more in depth in @Stefan’s and mine’s lab meeting, which you watch here (timestamp included).

An example of a resource definition (defined here) (imported from VENUS), that works with both the Opentrons and the Hamiltons:

def Cos_96_EZWash_P(name: str, with_lid: bool = False) -> Plate:
  return Plate(
    name=name,
    size_x=86.0,
    size_y=127.0,
    size_z=14.5,
    one_dot_max=11.3,
    with_lid=with_lid,
    lid_height=10,
    compute_volume_from_height=_compute_volume_from_height_Cos_96_EZWash_P,
    items=create_equally_spaced(Well,
      num_items_x=8,
      num_items_y=12,
      dx=11.5,
      dy=14.0,
      dz=1.0,
      item_size_x=9.0,
      item_size_y=9.0,
    ),
  )

In the future, we hope to host this data online and have the library pull from there. This database will be collaborative, with options for anyone to contribute their resources.

3 Likes

Are you available to join the meeting and discuss the potential use of your solution by the community?

If you’re able to make this available under an open license and open community process quickly, it could simplify the problem we are all facing.

Waiting indefinitely for such a resource or having it “owned” by some group, however, isn’t going to be a good solution for the larger community.

It’s already available under the MIT license at GitHub - PyLabRobot/pylabrobot: A hardware agnostic platform for liquid handling, I think that is as open as you should need right?

I think a database that others can post to should be available in a relatively short amount of time as well.

Are you available to join the meeting and discuss the potential use of your solution by the community?

Sure! Will DM you my email.

Hi there folks,

I wanted to close the loop with some feedback from the every-2-week meetings we’ve been having (mentioned above in this thread)

The notes of the discussions thus far are available here (view-only link):
https://docs.google.com/document/d/1f8EfWB4WLbU1I5EHOeNABkh4JKD6LOgxc6hCV98UAPo/edit?usp=sharing

Our current work item is comparing & contrasting the database models for pyLabRobot and Container Ontology (should probably include the Opentrons Labware Database as well):
https://docs.google.com/spreadsheets/d/1aVB2lm_QnJCXTxtP-PIkyG10IB8RQr348f_JhwmzPMo/edit?usp=sharing

DM me or join the meeting and let us know, if you’d like edit-access to those documents!

2 Likes

How’s the project been progressing @TimFallonUCSD ?

Slow and steady! The technical foundation is agreed upon & in development, hashing out all the attributes to potentiall store about labware, is the next step.

1 Like

I gave a short overview of LabOS’s labware model back in 2022. Today we published the full documentation of our model - https://genielifesciences.com/resources/developers-documents/labware-model/. All labware published in LabOS is of course available via REST API.
Hoping our model will contribute to the overall labware conversation.

2 Likes