[cgma-dev] Create offset curve bugs

[Boyd Tidwell]

The code for the "Create offset curve" command has some problems.

The following:

    cylinder radius 1 z 1
    create curve offset curve 1 distance 0.5

raises in an exception because the direction vector passed through a series
of calls is (0 0 0). The actual code raising the exception is gp_Dir.lxx,
lines 41-42:

  Standard_Real D = sqrt (Xv * Xv + Yv * Yv + Zv * Zv);
  Standard_ConstructionError_Raise_if (D <= gp::Resolution(), "");

  I am told by the Cubit experts here that a zero value direction vector
for this command should assume the offset is to be planar so in this case a
direction vector of (0 0 1) should be used.  This is indeed how the current
version of Cubit behaves.  When the option "direction 0 0 1" is added to
the command the OCC code works properly. At least the first time.  If the
exact command is entered a second time, the resultant curve is offset by an
additional 0.5 making the total offset 1.0.  Each time the command is
repeated, the offset is incremented by another 0.5 which is incorrect
behavior.

After the create offset command with direction is entered, a "reset"
command yields the following:

   Traceback (most recent call last):
     File "<string>", line 1, in <module>
     File "C:\Cubit_Open_Cascade\cubit_build_OC\claro\bin\Debug\cubit.py",
line 2278, in cmd
       return _cubit.cmd(*args)
   RuntimeError: Access violation - no RTTI data!

Cursory debug reveals the failure occurs when attempting to destroy the
existing geometry.

Also, when the magnitude of the direction vector is increased to any value
other than 1 (such as 0 0 3), strange no-planar behavior results when, in
fact, the magnitude should have no affect on how the command behaves.

Thank you for looking at this.  Sorry it is so long but I thought the
detail would help.

  - Boyd
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/cgma-dev/attachments/20111220/663cd779/attachment.htm>