[cgma-dev] imprint mesh bug

[Jane Hu]

Hi, Boyd:

Thank you for debugging this issue for me, otherwise, it's a bit difficult
to reproduce your work just in cgm.

I added a function in OCCBody that returns its shape no matter of its
shapetype, this way, the function will always return something. Hope it
fixed your problem. Please double check on it.

Thanks.

Jane

On Wed, Dec 28, 2011 at 2:44 PM, Boyd Tidwell <boyd at csimsoft.com> wrote:

>
> The following commands:
>
>      brick width 10
>      brick width 6
>      body 2 move x 8
>      volume 1 2 size 1
>      mesh volume 1 2
>      imprint mesh body 1 2
>
> cause a crash.  The same commands without the meshing works fine.
>
>
> The actual failure occurs in
>
>  void PartitionSurface::get_parents_virt( DLIList<TopologyBridge*>&
> result_list )
>
> On the assert in the following code, tmp_list.size() is zero.
>
>     for( i = real_surf_shells.size(); i--; )
>     {
>       tmp_list.clean_out();
>       real_surf_shells.get_and_step()->get_parents_virt( tmp_list );
>       assert(tmp_list.size() == 1);
>       real_surf_vols.append(tmp_list.get());
>     }
>
>
> A clue to the real problem may be revealed in the method called right
> before the assert:
>
>
> void OCCShell::get_parents_virt( DLIList<TopologyBridge*>& parents )
>
>  for(int i = 0; i <  bodies->size(); i++)
>   {
>     body = bodies->get_and_step();
>     TopoDS_Compound* shape = body->get_TopoDS_Shape();             <----
> added line
>     if (shape ==
> NULL)
> <---- added line
>
> continue;
> <---- added line
>     TopExp::MapShapesAndAncestors(*(body->get_TopoDS_Shape()),
>                                      TopAbs_SHELL, TopAbs_SOLID, M);
>     if (!M.Contains(*(get_TopoDS_Shell())))
>          continue;
>
>
> Previously I added the lines to check if "body->get_TopoDS_Shape()" was
> returning a NULL pointer.  It seemingly fixed a number of problems. I wish
> I'd written down the actual things that the change fixed.  This might just
> be a band-aid that hides a deeper problem but my tests run much better with
> the new code in place.  Because the existing code doesn't check for a null
> pointer, there seems to be an assumption that it will never be null so the
> null pointer could be the real problem.  I don't have enough understanding
> of the code to know what is correct.
>
> Good Luck and thanks in advance,
>
>   - Boyd
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/cgma-dev/attachments/20120106/f6bec139/attachment.htm>