ansys / pyansys-geometry Goto Github PK

From conversations with DBU, we should implement the Sketch class to work with 2D points rather than 3D when sketching.

This is also a resulting task from #96

This task should follow after:

• #146
• #147

Some of the tasks to be performed are:

• Ensure that all shapes (i.e. 2D objects) are generated from purely 2D elements (i.e. Point2D, Vector2D...).
• Ensure that the Sketch class is adapted to the new shape constructors.
• Ensure that when requesting the 3D points, these are generated properly (for plotting, sending over to the server...).
• Ensure that the examples are properly adapted, as well as the documentation.
• We should delegate the generation of plotting points to PyVista. And only handle on our side those points that are important for the Shape itself (i.e. box == 4 corner points)

We should extract this into a __check_arc_data(...) method. That way we can call it from potential future setters.

Originally posted by @RobPasMue in #81 (comment)

Minimum constructor:

Point3D origin, Direction dir

Minimum constructor:

Point3D origin, Direction dirX, Direction dirY

Can include Plane concept within Sketch class as well since a Sketch acts against a single plane workspace

SpaceClaim constructors for reference:

Sphere(Point3D origin, Direction dirX, Direction dirY, double radius)
Sphere(Point3D origin, double radius)

Once #1 #2 #3 are ready, we should be in a good position of including a first example on how users are expected to work with the library datamodel objects, regarding:

• Object creation
• Object operations (e.g. adding points)
• Object visualization

We should definitely include some examples regarding basic datamodel object usage.

Will be similar to extrude, but does not accept in a distance. CreatePlanarBody grpc endpoing on bodies.proto.

SpaceClaim constructors for reference:

Cylinder(Point3D origin, Direction dirX, Direction dirY, double radius)

Cylinder(Point3D origin, Direction dirZ, double radius)

Now that we have a client in place (#36) we are able to pull up a server and connect to it. We should be able to go through the different shapes implemented, add them to the Sketch and send them over to the server. Then, parse the response and validate that the Sketch build has been done adequately.

• Figure out how to send the sketch.
• Wrap the gRPC stubs to send the information in an orderly manner.
• Validate that the different sketch elements are created consistently on the server side.

It looks like we may have an issue... Sphinx does not link correctly to our package classes amongst themselves.

For example:

Here, Point3D should be clickable. Let's try and solve this.

Maybe all of this is contained client side but would be nice to move server side in either this first implementation or future refactors.

Accept in the required inputs to create a box in a method on the Component class. The call to the server should return a Body that will be nested under the Component in context.

Example client script is within BoardCreationCommonHelper for reference.

Drive by observation:
Why are we defining __all__ here?

https://github.com/pyansys/pygeometry/blob/cd015f33671d4e0e99249f9b40379be64c5c1e24/src/ansys/geometry/core/primitives/__init__.py#L8-L13

__all__ defines what's imported when using "star" imports. Since this __all__ already includes all the classes defined in the __init__.py, it seems redundant.

Let's get a first version of the Geometry client out!

Related tasks:

• Create a base repository + docs repos for getting things started
• Implement basic entity objects. Linked to #13
• Implement units handling using pint. Linked to #2
• Create a plotting module for visualizing the entity objects. Linked to #3
• Create a math/algebra module for operations with entity objects. Linked to #13
• Conceive a simple client to connect to a gRPC server. Linked to #36
• Add tests
• Add documentation: API reference automatically generated + basic PyAnsys sections. Linked to #5
• Add examples. Linked to #4

Let us use beartype for checking type hints at runtime. This will also simplify most of our check validations.

We need to implement a logger. Follow approach from PyDiscovery and PyMAPDL. This module may be easily migrated from these repositories.

Basic Math Capabilities

• Point #16
• Vector3D #18
• VectorUV #18
• Direction (Unit Vector) #16
• Matrix #40

2D Geometry

• Line #54
• Segment #54
• Circle #19
• 2DSpline #46 (NOT A PRIORITY)
• Ellipse #19
• Polygon #52
• Arc #50

3D Geometry

• Plane #32
• Sphere #24
• Cylinder #23
• Torus #20
• Cone #30
• 3DSpline #46 (NOT A PRIORITY)
• Line Segment #33

Misc

• BBox #21 (NOT A PRIORITY)
• Interval #22 (NOT A PRIORITY)
• Frame #51
• Accuracy (operation tolerance (e.g. Point3D == Point3D or Point3d.is_equal(<other point, tol=1E-5) #35

Units

• Metric
• Imperial
• pint

Additional requirements

• Null state (e.g. initialized with Point3D())

Add transformation module for :

• Rotation
• Translation
• Scaling
• Reflection (if required)

An important aspect of CAD libraries are the units. It is expected that, behind the scenes, all objects work in SI units, but users should be able to provide their values in different units. Let's get this module started!

• Implement the units module
• Create a `Quantity`` (enum) class handling the units accepted
• Create a Conversion class which will contain a Quantity (enum) value and a conversion factor
• Implement units inside the datamodel.objects package
• All units inside the objects must be stored in SI, but users will be able to provide different Quantity values. Conversions should be handled in construction and representation. Inside operations and operations between objects will always take place in SI
• Add testing (must be intensive, this is a critical module)
• Add documentation

See the following picture for having an idea of the location of the units subpackage

Let's rework the existing 3D objects into using as base attributes our PyGeometry *Shape objects. We may need to open separate issues for each of them:

• Cone
• Torus
• Cyllinder
• Sphere

Following DBU suggestions (thanks to Udo Tremel) we should consider separating all the curves and primitives we have into these two big submodules. Math would contain our actual primitives submodule whereas SketchCurves should be in shapes

At the moment the docs are a clean sheet. We should consider implementing the basic sections of all PyAnsys docs:

• #141
• #142
• #143
• #144
• #145

One of the suggestions of the DBU team is the concept of bounded/unbounded curves. Sketch-related objects should be bounded (i.e. they should have a beginning and an end) whereas unbounded objects (Line(infinite/semi-infinite), circle, ellipse...) should be more like primitives.

Furthermore, all these objects could be used elsewhere. So we should try to remove the "Sketch" concept from these curves and add the concept of Bounded/Unbounded. In fact, Bounded curves could easily extend Unbounded ones, since they would only be specifying starting and end points.

@Revathyvenugopal162 and @MaxJPRey did a really good work implementing the general Python abstract objects we conceived from PyDiscovery. And most of that work is reusable. Let's take it to this repo!

• Migrate the base GRPCWrapper class (and change name to BaseObject
• Migrate the geometry subpackage
• Remove all gRPC pydiscovery-specific implementations (i.e. the _update_message/_from_message implementations)
• Structure it as proposed in the first meeting we had (see image below)
• Include testing
• Add classes to the documentation

As a developer, I would like an encapsulated abstraction providing:

gRPC abstraction layer

• Stateless pass-through wrapper layer to grpc stubs with method signatures derived from ansys.geometry.core model entities

Server connection management

• Management of existing connections
• Reconnect management
• Establish connection to specific endpoint

The Arc is one of the basic curves we need to be able to create. Basic constructor for DBU is exposed in #13.

• The arc should extend from a Circle if possible since it is basically a subset of points
• Allowing to create an arc from three points as @MaxJPRey suggested in #13 is also a possibility. Consider creating this @classmethod as well.

Make sure that the signatures of the different shapes signatures (circle, arc, ellipse, line...) are consistent.

https://github.com/pyansys/pygeometry/blob/0208ee2360b3964231c8c6c0930db286fd94a4fa/src/ansys/geometry/core/shapes/circle.py#L18-L29

Add a function in vector module to find the angle between 2 vectors. Which will useful to for transformations, arc and geometric functionality of perpendicular, parallel lines

Following @jorgepiloto's suggestion, it may be interesting to add a transformations.py module once the Matrix class is available, so that we have the capability of creating:

• Scale matrices
• Translation matrices
• Rotation matrices

And their operations. All these computations can occur on the client side. Thanks for the suggestion @jorgepiloto!

We are definitely not going to implement the Spline logic on our own. We should look into other libraries to see who has it implemented and wrap around it.

Should handle comparisons with default and defined tolerances like:

Accuracy.length_is_zero(length: float)
Accuracy.length_is_zero(length: float, tolerance: float)

Pull default tolerances from SpaceClaim, such as:

float length_accuracy = 1e-8;

The Frame will allow us to set our reference system in space. As exposed in #13 it is one of the basic objects the DBU needs. This task should be handled prior to #32.

• Consider using the DBU constructor - its inputs should be stored as instance attributes.
• Consider other potential constructors (if any)
• Consider migrating PyDiscovery implementation for ease of task (there is already a Frame class there)

3D primitive object

constructor options within spaceclaim
Point3D origin, Direction dirX, Direction dirY, double majorRadius, double minorRadius
Point3D origin, Direction dirZ, double majorRadius, double minorRadius

Another important point is the visualization of the different objects inside the datamodel. We should consider using PyVista for this task. Points to be taken into account for this task:

• Implement the plotting subpackage
• Consider the creation of a ScenePlotter or similar (please don't use my name suggestion 😄): users will be able to pass in several objects and plot them all together
• All datamodel objects should implement a plot() function. This function should be defined as abstract in the BaseObject class and implemented downstream in each object
• Create a PyGeometry plotting theme so that we do not use the default PyVista theme
• Add documentation
• Add testing

Please consider the following location for the plotting subpackage:

https://github.com/pyansys/pygeometry/blob/ee381c2868a644ff3ead1feaa166c701693c1c70/tox.ini#L44

The following lines need to be removed.
https://github.com/pyansys/pygeometry/blob/3db2614435903e289779b1028311da25faf8f626/src/ansys/geometry/core/math/vector.py#L256-L257

We can check with is_zero wherever it is needed. For instance in the arc modules, when getting vectors from points to calculate the angle, the is_zero can be used.

Once the ansys-api-geometry package is published (in the PyAnsys private PyPi for now) we can start consuming and removing the existing auto-generated Python files from the repository.

As per DBU request, we should allow to overload operators for VectorXD operations

• Dot product: a * b
• Cross product: a @ b, or a ^ b, or a % b

We should also have a three point builder. Basic trigonometry as well. But we may want to leave that for a different PR? Do you see it could be feasible to implement it in this one?

It should be something like:

@classmethod
def from_three_points(start, mid, end):
    ...

Originally posted by @RobPasMue in #81 (comment)

The Polygon class is one of the basic classes we need to be able to create. Basic constructor for DBU is exposed in #13.

Consider using their constructor and storing those properties as instance attributes.

For example, would like to evaluate each value of numpy array against a specific tolerance value.

Minimum constructor
Point3D start, Point3D end

As @akaszynski mentioned, most of the capabilities related with units and its methods are the same everywhere but we are duplicating code. Let's consider extending from a common PhysicalQuantity class (or similar name) that handles units for our base objects.

During our meeting with the DBU we realized that when building a LineSketch object we are not double checking that (for example):

• The points are not the same
• The units of the points should be checked (if they are different, fall back to PyGeometry's default units)
• ...

CreateNamedSelection should most likely be a method on the Design class.

The grpc endpoint is CreateNamedSelection in the namedselection.proto.

Maintain a list of active named selections in the Design instance.

Ellipse, Circle and Line are still pending units support. Work on this.

We are not interested for the moment in adding the poetry.lock file. However, this file could be uploaded as an artifact in the CI/CD when installing the package.

As @jorgepiloto pointed out, it may be better to just remove support for setters. Specially for complex objects (Shapes, primitives etc) depending on more basic objects (math module). This is open to discussion.

If we remove setter support I'd remove them from all places, including math subpackage. What do you think @chadqueen @jorgepiloto @MaxJPRey @Revathyvenugopal162.