[cgma-dev] Current CGM test failures (via Python)

[James Porter]

On Fri, 2011-05-13 at 15:42 -0500, Jason Kraftcheck wrote:
> On 05/13/2011 03:21 PM, James Porter wrote:
> > This is just a heads-up for people if they'd like to fix these things,
> > but there are currently 4 test failures in PyTAPS' iGeom interface. One
> > of them is a recently-fixed bug in CGM that I just haven't had the
> > chance to fix the test for, but the other 3 are bugs in CGM. They are as
> > follows (note that this is against Cubit 12):
> > 
> > 1) iGeom_getEnt1stDrvt returns iBase_FAILURE
> >    This is a relatively recent failure, since before the Cubit 12 branch
> >    was merged, this worked (it may have regressed a bit earlier or later
> >    than that, though). I'm not totally sure what the issue is here. It's
> >    possible that it's a bug in Cubit.
> > 
> 
> Are you testing with Cubit?  If not, which engine are you testing with?

Cubit (as mentioned in passing above).

> > 2) iGeom_getEnt2ndDrvt returns iBase_NOT_SUPPORTED
> >    If possible, we should try to support this function. I'm not sure how
> >    hard that would be, though.
> > 
> 
> ACIS (and presumably OpenCascade) can provide this data.  However, as it
> isn't exposed in any CGM API, providing access to that information would
> make our iGeom implementation incompatible with Cubit.  That is, we might be
> able to fix this with a bunch of #define type stuff, but it will never work
> when linking against Cubit.
> 
> As an alternate solution, it might be possible to calculate these values
> given the first derivatives and the principal curvatures.

This might work as a fallback when we build with Cubit.
> 
> > 3) Sets contained in sets don't quite work
> >    It seems that num_hops doesn't work right in the iGeom set functions
> >    (just for set containment, not parent-child).
> >
> 
> This seems like a simple bug.  Have you looked at it at all?

I have. The only remotely difficult part would be cycle detection, but
even that isn't too bad.

> >    getEntSets only returns
> >    immediate children. I could probably fix this one, but I'm not sure
> >    if I should just fix it in the iGeom interface, or if it should be
> >    fixed somewhere else.
> > 
> 
> It should be fixed in the iGeom interface.

Alright. I'll see about fixing this sometime in the near future then.

- Jim