[cgma-dev] Create offset curve bugs

[Jane Hu]

Hi, Boyd:

On Tue, Dec 20, 2011 at 11:47 AM, Boyd Tidwell <boyd at csimsoft.com> wrote:

> 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.


This part is not implement yet, but I am planning to add it to the to-do
list.


> 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.
>
> This sounds to me an (Cubit) interpreter issue. Can you make a break at
OCCModifyEngine::offset_curves(), and check offset_distance value for me?
if it kept increasing, the the upper level interpreter has something to do
with it. Please let me know if you consistantly see it to be 0.5 and yet
offset a wrong distance. Thanks.

Also, I don't have the newest Cubit to double check this command, however,
I tried to see what Cubit did in cubit12.2 for this command with an
offset_direction. It seems to me that this direction doesn't make sense in
Cubit, and it always treats the curve plannar offset. This makes me more
curious to know what the command interpreter does for this.


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.
>
>
I'll take a look on this.

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.
>
> Please also double check on your side, if the offset distance and
direction are passed in correctly to  OCCModifyEngine::offset_curves.
Thanks.

BTW, I am going to take a 2-week vacation from tomorrow, you are welcome to
sending in more bugs as your testing going on. I will probably get back to
you on those in the new year.

Merry Christmas and Happy New Year!

Jane

> 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/20111221/27afdf4f/attachment.htm>