Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

refactor(api): redefine well geometry structure #16392

Merged
merged 35 commits into from
Oct 9, 2024

Conversation

caila-marashaj
Copy link
Contributor

@caila-marashaj caila-marashaj commented Sep 30, 2024

Overview

After discovering some new shapes and generally interacting with the new well geometry data structures, I think it would be better to reshape the geometry data a little bit. Rather than having each section of a well be represented by its top cross-section and top height, let's just represent a section in its entirety, with bottom and top cross-sections and bottom and top heights being present in every shape that is not a SphericalSegment.

Changelog

  • add RoundedRectangle class
  • add TruncatedCircle class
  • add CircularFrustum and RectangularFrustum classes
  • adjust frustum_helpers and tests to use the new data structure

TODO

@caila-marashaj caila-marashaj marked this pull request as ready for review September 30, 2024 22:47
@caila-marashaj caila-marashaj requested review from a team as code owners September 30, 2024 22:47
Copy link
Contributor

@SyntaxColoring SyntaxColoring left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed with Seth on avoiding Any.

Other than that, looks correct. Thank you! Here are some questions and comments on the underlying data shapes.

shared-data/labware/schemas/3.json Show resolved Hide resolved
shared-data/labware/schemas/3.json Outdated Show resolved Hide resolved
shared-data/labware/schemas/3.json Outdated Show resolved Hide resolved
shared-data/labware/schemas/3.json Show resolved Hide resolved
shared-data/labware/schemas/3.json Outdated Show resolved Hide resolved
shared-data/labware/schemas/3.json Show resolved Hide resolved
Comment on lines 149 to 150
# A truncated circle is a square that is trimmed at the corners by a smaller circle
# that is concentric with the square.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suggest centralizing documentation like this inside the JSON schema, and thinking of the Python bindings as dumb references to it. Basically just for single-source-of-truth reasons.

I would even go as far as to delete the pydantic.Field descriptions in labware_definition.py, though others have disagreed with me on that.

@ryanthecoder ryanthecoder requested a review from a team as a code owner October 2, 2024 21:03
@ryanthecoder ryanthecoder requested review from brenthagen and removed request for a team October 2, 2024 21:03
Copy link
Member

@sfoster1 sfoster1 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Inline changes.

I also don't quite get the point of taking this data from a labware definition, to a pydantic model, and then out to a typed dict. What does the typed dict give us that the pydantic model doesn't? It kind of seems like it just makes us define everything twice.

shared-data/python/opentrons_shared_data/labware/types.py Outdated Show resolved Hide resolved
shared-data/python/opentrons_shared_data/labware/types.py Outdated Show resolved Hide resolved
shared-data/python/opentrons_shared_data/labware/types.py Outdated Show resolved Hide resolved
shared-data/python/opentrons_shared_data/labware/types.py Outdated Show resolved Hide resolved
api/src/opentrons/protocol_engine/state/frustum_helpers.py Outdated Show resolved Hide resolved
api/src/opentrons/protocol_engine/state/frustum_helpers.py Outdated Show resolved Hide resolved
api/src/opentrons/protocol_engine/state/frustum_helpers.py Outdated Show resolved Hide resolved
api/src/opentrons/protocol_engine/state/frustum_helpers.py Outdated Show resolved Hide resolved
api/src/opentrons/protocol_engine/state/frustum_helpers.py Outdated Show resolved Hide resolved
@ryanthecoder ryanthecoder force-pushed the EXEC-736-well-geometry-refactor branch from 2396daa to 965ccb4 Compare October 4, 2024 16:00
Copy link

codecov bot commented Oct 4, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 81.14%. Comparing base (5658b8a) to head (05fb103).
Report is 274 commits behind head on edge.

Additional details and impacted files

Impacted file tree graph

@@             Coverage Diff             @@
##             edge   #16392       +/-   ##
===========================================
+ Coverage   63.28%   81.14%   +17.85%     
===========================================
  Files         300      106      -194     
  Lines       15786     3786    -12000     
===========================================
- Hits         9990     3072     -6918     
+ Misses       5796      714     -5082     
Flag Coverage Δ
g-code-testing 92.43% <ø> (ø)
hardware ?
shared-data 75.34% <100.00%> (+2.01%) ⬆️
system-server ?
update-server ?
usb-bridge ?

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines Coverage Δ
.../python/opentrons_shared_data/labware/constants.py 100.00% <100.00%> (+100.00%) ⬆️
...pentrons_shared_data/labware/labware_definition.py 100.00% <100.00%> (ø)
...data/python/opentrons_shared_data/labware/types.py 100.00% <100.00%> (ø)

... and 194 files with indirect coverage changes

shared-data/labware/schemas/3.json Outdated Show resolved Hide resolved
shared-data/labware/schemas/3.json Outdated Show resolved Hide resolved
shared-data/labware/schemas/3.json Outdated Show resolved Hide resolved
shared-data/labware/schemas/3.json Outdated Show resolved Hide resolved
shared-data/labware/schemas/3.json Outdated Show resolved Hide resolved
@ryanthecoder ryanthecoder force-pushed the EXEC-736-well-geometry-refactor branch from 2aa5b9b to 59e4130 Compare October 7, 2024 15:53
Copy link
Contributor

@SyntaxColoring SyntaxColoring left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shapes look great to me, thanks!

I haven't reviewed the processing part of this because it seems like @sfoster1 has already looked at it, but I'm happy to if you want more eyes.

"properties": {
"shape": {
"type": "string",
"enum": ["squaredcone"]
Copy link
Contributor

@SyntaxColoring SyntaxColoring Oct 9, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit, doesn't block merging: camelCase squaredCone and roundedCuboid, if possible.

Unless these are matching a convention elsewhere in the labware definitions that I'm missing.

@@ -350,7 +350,7 @@ class SquaredConeSegment(BaseModel):


"""
module filitedPyramidSquare(bottom_shape, diameter, width, length, height, steps) {
module filitedCuboidSquare(bottom_shape, diameter, width, length, height, steps) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit for these OpenSCAD snippets, doesn't block merging: filleted instead of filited.

Copy link
Member

@sfoster1 sfoster1 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Excellent! Looks great to me.

@ryanthecoder ryanthecoder merged commit 7f6506f into edge Oct 9, 2024
58 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants