[cgma-dev] Bug Report: getPtClass Function Call in PyTaps

[Jason Kraftcheck]

The problem here is that iGeom_CGMA is mis-using the
RefFace::point_containment call.  For ACIS geometry, that function
ultimately calls api_point_in_face.  The ACIS 16 documentation for
api_point_in_face says:

  Limitations: If the input point is not on the face's surface, the
  behavior of this function is undefined. For performance reasons this
  is not trapped by the function, so the api will not fail in this
  situation, but the relationship returned is not meaningful. In
  particular, the result point_outside_face is not guaranteed to be
  returned when this function is called with a point not on the face's
  surface.

- jason



Stuart Slattery wrote:
> Hello
> 
> I am an undergraduate working at the University of Wisconsin-Madison and
> have run into an issue implementing iGeom through the PyTaps interface.
> I am using a five-volume cylindrical geometry (see attached cyltst.sat
> file) that was constructed in CUBIT 10.2 with the volumes imprinted and
> merged. Throughout the geometry, I am using getPtClass in PyTaps to
> decide which geometry volume the point lies in.
> 
> The attached python script (demo.py) uses getPtClass at two points in
> the geometry. Both are at the same x and z coordinates with the y
> coordinate varied. Because the cylinders are aligned along the y-axis,
> both of these points reside in the same volume. However, depending on a
> given y-position with the same x and z coordinates, getPtClass will
> return a surface entity handle or a volume entity handle when only a
> volume entity handle should be returned.
> 
> I am curious to the cause of this y-position dependence on the results
> returned by getPtClass when the geometry has no variation in the
> y-direction. For your reference, I built CGMA against CUBIT 10.2.
> 
> Thanks
> 
> Stuart Slattery
> 
> 


-- 
"A foolish consistency is the hobgoblin of little minds" - Ralph Waldo Emerson