Thank you, Boyd. It seems that these two functions were not implemented before, so people gave them a hard assertion of zero to indicate, as you said, that these code should not be called. BTW, I don't know who Danilov is either. Later, we implemented the code, but somehow it seems not on the high priority list, so it's not been tested yet, and the assertion was not removed.<br>
<br>I am glad that you take some effort testing them, and it seems that besides the assertion, the rest of the codes worked as expected. I've removed the assertions, and the code has been up-date for this change now.<br>
<br>Thank you again for the kind note and happy testing!<br><br>Jane<br><br><div class="gmail_quote">On Fri, Dec 16, 2011 at 12:23 PM, Boyd Tidwell <span dir="ltr"><<a href="mailto:bktidwell373@gmail.com">bktidwell373@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I am in the middle of testing OCC integrated with Cubit. �Many things<br>
work just fine, some do not. �I am waiting until the end of the<br>
process to decide which bugs to try to fix myself and which to report.<br>
<br>
But this one is so odd I just couldn't wait.<br>
<br>
>From the cubit test suite:<br>
<br>
create frustum height 11 radius 10 top 2<br>
create cylinder height 1 radius 9<br>
unit body 1 2<br>
<br>
These commands seem to work fine. �But when I try:<br>
<br>
list surf all<br>
<br>
�I hit this code in OCCurve.cpp:<br>
<br>
CubitStatus OCCCurve::get_interior_extrema(<br>
�DLIList<CubitVector*>& interior_points,<br>
�CubitSense& return_sense )<br>
{<br>
�// Danilov: try to use GeomAPI_ExtremaCurveCurve<br>
�// Will do 3 primary directions seperately.<br>
�assert(0);<br>
<br>
<br>
And, of course, it all comes to a screeching halt. �There is one other<br>
method in OCCCurve with an "assert(0);" as the first executable line<br>
also. �All "list surf all" commands for other geometry avoid this<br>
method but something about the geom constructed by these commands<br>
leads the code down this fatal path.<br>
<br>
The only reason I can imagine for a hard assert as the first line of<br>
code is a way of saying: "This code should never be called." �Not the<br>
best way to signal this condition in my book, but maybe I'm missing<br>
something.<br>
<br>
When the assert is removed, the list command completes with what looks<br>
like correct info.<br>
<br>
Thanks for looking into this one.<br>
<span class="HOEnZb"><font color="#888888"><br>
�- Boyd<br>
</font></span></blockquote></div><br>