Skip to content

feat: repair tools refactoring #1912

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

Open
wants to merge 51 commits into
base: main
Choose a base branch
from

Conversation

umutsoysalansys
Copy link
Contributor

@umutsoysalansys umutsoysalansys commented Apr 14, 2025

Description

Refactoring repair tools to move repair stubs to the central area. See the issue for more details.

Issue linked

#1817

Checklist

  • I have tested my changes locally.
  • I have added necessary documentation or updated existing documentation.
  • I have followed the coding style guidelines of this project.
  • I have added appropriate unit tests.
  • I have reviewed my changes before submitting this pull request.
  • I have linked the issue or issues that are solved to the PR if any.
  • I have assigned this PR to myself.
  • I have added the minimum version decorator to any new backend method implemented.
  • I have made sure that the title of my PR follows Conventional commits style (e.g. feat: extrude circle to cylinder)

@umutsoysalansys umutsoysalansys changed the title repair tools refactoring feat: repair tools refactoring Apr 14, 2025
@github-actions github-actions bot added the enhancement New features or code improvements label Apr 14, 2025
@umutsoysalansys umutsoysalansys self-assigned this Apr 14, 2025
Copy link

codecov bot commented Apr 17, 2025

Codecov Report

Attention: Patch coverage is 89.74359% with 20 lines in your changes missing coverage. Please review.

Project coverage is 90.34%. Comparing base (a5236ee) to head (0b898dc).

Files with missing lines Patch % Lines
...s/geometry/core/_grpc/_services/v1/repair_tools.py 55.55% 16 Missing ⚠️
...s/geometry/core/_grpc/_services/v0/repair_tools.py 96.77% 3 Missing ⚠️
src/ansys/geometry/core/tools/repair_tools.py 95.00% 1 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##             main    #1912      +/-   ##
==========================================
- Coverage   90.36%   90.34%   -0.03%     
==========================================
  Files         117      120       +3     
  Lines        9593     9768     +175     
==========================================
+ Hits         8669     8825     +156     
- Misses        924      943      +19     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@umutsoysalansys umutsoysalansys marked this pull request as ready for review April 17, 2025 03:46
@umutsoysalansys umutsoysalansys requested a review from a team as a code owner April 17, 2025 03:46
@RobPasMue
Copy link
Member

RobPasMue commented Apr 21, 2025

Blocked by #1924

Will review once #1924 is merged and this branch is updated with it

Copy link
Member

@RobPasMue RobPasMue left a comment

Choose a reason for hiding this comment

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

Requesting changes. Overall it is looking good but there are some conceptual changes that need to be done:

  • All the methods must return a dictionary, with no gRPC objects... If a conversion from a gRPC object needs to be done, we add it to the conversion module. See the work done in feat: grpc driving dimensions stub implementation #1921
  • We have to add the noqa statements and the typehints -- otherwise pre-commit will complain

Based on these two comments, the src/ansys/geometry/core/tools/repair_tools.py module will have to be adapted too.

Comment on lines 46 to 53
from ansys.api.geometry.v0.repairtools_pb2 import FindSplitEdgesRequest

request = FindSplitEdgesRequest(
bodies_or_faces=kwargs["bodies_or_faces"],
angle=kwargs["angle"],
distance=kwargs["distance"],
)
return self.stub.FindSplitEdges(request)
Copy link
Member

Choose a reason for hiding this comment

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

I know it might sound silly but, if you look at the other modules with the specific implementations, all of them have separate in-line comments for identifying the sections of the method:

    @protect_grpc
    def get_collision(self, **kwargs) -> dict:  # noqa: D102
        from ansys.api.geometry.v0.bodies_pb2 import GetCollisionRequest

        # Create the request - assumes all inputs are valid and of the proper type
        request = GetCollisionRequest(
            body_1_id=kwargs["id"],
            body_2_id=kwargs["other_id"],
        )

        # Call the gRPC service
        resp = self.stub.GetCollision(request=request)

        # Return the response - formatted as a dictionary
        return {"collision_type": resp.collision}

Try to follow the same structure and put the same comments. Although repetitive, gives clarity

from ansys.api.geometry.v0.repairtools_pb2 import FindInexactEdgesRequest

request = FindInexactEdgesRequest(selection=kwargs["selection"])
return self.stub.FindInexactEdges(request)
Copy link
Member

Choose a reason for hiding this comment

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

We always have to return a dictionary. It's the base rule for the entire gRPC rearchitecture.

If you need to return an object, you can add a conversion method from a given gRPC response. Please ask @jacobrkerstetter on guidance for this. He has already handled a few of them.

selection=kwargs["selection"],
max_edge_length=DoubleValue(value=kwargs["length"]),
)
return self.stub.FindShortEdges(request)
Copy link
Member

Choose a reason for hiding this comment

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

The response as a dictionary is a general rule for the entire module. Please adapt everywhere.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

so does it mean we are changing the return type of the methods?
isn't it a breaking change?

Copy link
Member

Choose a reason for hiding this comment

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

We are not changing the return type of the methods that are user facing, so no, it is not a breaking change.

What we are saying is that anything that comes out of the "services" should be a dictionary with proper Python objects. This implies doing the conversion to the wrappers we have or just extracting the info we need (like the success state). See https://github.com/ansys/pyansys-geometry/pull/1921/files for more info

Comment on lines 38 to 43
def __init__(self, channel: grpc.Channel):
"""Initialize the MeasurementToolsService class."""
pass # pragma: no cover

def find_split_edges(self, **kwargs):
raise NotImplementedError
Copy link
Member

Choose a reason for hiding this comment

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

Remember to add the typehints here as well as the noqa statements. Have a look at the other modules implemented

# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
# OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
# SOFTWARE.
"""Module containing the repair tools service implementation (abstraction layer)."""
Copy link
Member

Choose a reason for hiding this comment

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

This is not an abstract layer - it is a specific implementation

@umutsoysalansys
Copy link
Contributor Author

@smereu @RobPasMue only missing piece is refactoring this inspect/repair tools. They are kind of too implicit

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New features or code improvements
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants