On Fri, Sep 05, 2008 at 01:15:07PM +0200, Rafael Laboissiere wrote: > * Thomas Weber <[EMAIL PROTECTED]> [2008-06-09 09:11]: > > > Am Samstag, den 10.05.2008, 07:33 +0200 schrieb Thomas Weber: > > > On 09/05/08 18:34 -0500, Jordi Gutiérrez Hermoso wrote: > > > > Package: octaviz > > > > Version: 0.4.7-1 > > > > Severity: important > > > > > > > > With the attached script and data, Octaviz segfaults on AMD64. > > > > > > As I discussed with Jordi earlier: this is arch-specific, it doesn't > > > happen on i386. > > > > I've tracked this back till line 271 of vtkClipPolyData.cxx, where > > cellScalars->GetComponent(1,0) > > is a NaN value. > > Should this bug be considered release-critical, as it is now (severity level > "serious")? The octaviz package is essentially functional and the problem > reported happens in the vtk_surf function (well, maybe also in others, who > knows...)
> > Anyway, I think that it is too harsh to drop octaviz from lenny only because > of that. I would prefer to downgrade the severity to "important" and, as an > interim solution, upload a new version of octaviz with a patched vtk_surf > file. For instance, we could change the doc string by alerting the user > about NaN or, better, return an error message if the input Z matrix contains > NaN values. At any rate, the user can circumvent this bug by changing her > script (see the modified plotresults_vtk.m attached below). > > What do you think? Aarrgg, Rafael, you are my hero. Up until now, I thought that there was a bug in Octaviz/VTK, that created these NaN values. Now I see that they are coming from griddata(). Well, VTK doesn't support NaNs, at least according to http://www.vtk.org/pipermail/vtk-developers/2007-January/004421.html http://thread.gmane.org/gmane.comp.science.electromagnetism.meep.general/295 So, my "solution" would be: patch vtk_surf() to check for NaN and error out if it finds them. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
