Re: [OctDev] griddata / delaunay

[Jonathan S. <jjs...@sb...>]

Seems like a good solution to me.

I'm rather new to open source development...  How do changes generally 
get committed to octave-forge?  Should I submit a patch for delaunay to 
this list?  Will someone then review and commit it?

BTW:  I just started working with delaunay recently because griddata was 
giving me trouble.  I really don't know much about the other functions 
that use qhull, so I'd rather leave them alone right now.

Thanks,
Jonathan


David Bateman wrote:
> I'm not a user of delaunay and so you know better. I just proposed a 
> generic fix that should be applied wherever foreign code is used with
> octave to prevent just this type of problem. If the "QJ" to qhull is
> such a generic solution, why not just make the default for OPT in
> delaunay (and elsewhere?) be "QJ" with something like
> 
>  if (nargin == 2)
>    opt = "QJ";
>  endif
> 
> and be done with it. This combined with the previous fix, should be
> sufficient..
> 
> D.
> 
> 
> According to Jonathan Stickel <jjs...@sb...> (on 09/01/04):
> 
>>David Bateman wrote:
>>
>>>According to Jonathan Stickel <jjs...@sb...> (on 09/01/04):
>>>
>>>
>>>>I have encountered a problem with griddata when using semi-regular input 
>>>>points.  The issue has to do with facet merging when running delaunay, 
>>>>via qhull, with defualt options.  To avoid this, delaunay should be run 
>>>>with the "QJ" option.  Perhaps this should be mentioned explicitly in 
>>>>the delaunay help.  For the worst case of a rectangular grid, a 
>>>>segmentation fault occcurs:
>>>>
>>>>octave:1> [x,y]=meshgrid(1:10,1:10);
>>>>octave:2> delaunay(x(:),y(:),"QJ")
>>>>(plot of triangles)
>>>>octave:3> delaunay(x(:),y(:))
>>>>panic: Segmentation fault -- stopping myself...
>>>>attempting to save variables to `octave-core'...
>>>>save to `octave-core' complete
>>>>Segmentation fault
>>>>
>>>>Attached is a patch for griddata which calls delaunay with the "QJ" 
>>>>option.
>>>
>>>
>>>Not sure if this is the right approach. What is the real reason for the
>>>seg fault. If it is in the underlying qhull code, it might be better to
>>>surround the calls to the qhull stuff with
>>>
>>>     BEGIN_INTERRUPT_IMMEDIATELY_IN_FOREIGN_CODE_1;
>>>
>>>     error ("delaunay: Internal qhull error. Please try the 'QJ' 
>>>     option.");
>>>     octave_throw_interrupt_exception ();
>>>
>>>     BEGIN_INTERRUPT_IMMEDIATELY_IN_FOREIGN_CODE_2;
>>>
>>>     <QHULL CODE HERE>
>>>
>>>     END_INTERRUPT_IMMEDIATELY_IN_FOREIGN_CODE;
>>>
>>>and inform the author of qhull of the problem within their code. At least
>>>this way octave won't crash for qhulls problems....
>>>
>>
>>I agree.  I do believe that qhull is the real cause of the example 
>>segfault, and octave functions should catch the problem like you 
>>suggest.  However, for other semi-regular grids, delaunay does not 
>>always segfault but will "drop points" when used without the QJ option. 
>>  I can provide an example if you like. I think this should be 
>>mentioned in the help for qhull based functions.
>>
>>Please don't overlook my specific solution for griddata.  Griddata does 
>>not currently take arguments to pass to qhull.  This could be added, of 
>>course, but I see no reason not to always use the QJ option for delaunay 
>>within griddata.
>>
>>Jonathan
>>
>>
>>-------------------------------------------------------
>>This SF.Net email is sponsored by BEA Weblogic Workshop
>>FREE Java Enterprise J2EE developer tools!
>>Get your free copy of BEA WebLogic Workshop 8.1 today.
>>http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click
>>_______________________________________________
>>Octave-dev mailing list
>>Oct...@li...
>>https://lists.sourceforge.net/lists/listinfo/octave-dev
> 
>