Thanks Allesandro. >From your long message ;), I think that the fix then is to not overcount the space taken for the polyhedral cells. https://gitlab.kitware. com/vtk/vtk/merge_requests/2346
thoughts? David E DeMarle Kitware, Inc. R&D Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4909 <(518)%20881-4909> On Fri, Dec 16, 2016 at 11:11 AM, Alessandro De Maio <demai...@gmail.com> wrote: > I've done some more debugging on this topic. > > The problem is not related only to windows machines: the easy example that > I attached at the beginning of this post (polyhedron.xmf) seems to be > correctly opened on Linux machines, but if you try to reopen it several > times (for example using the new 5.2 feature of "Reload Files"), not very > often but sometimes it gives segfault also on Linux machines. Moreover, if > you try to open a bigger file (with more polyhedra inside) it fails more > often or, sometimes, it seems not to read all the polyhedral cells in the > mesh. > > I've tried to investigate the code and I think I've found the reason of > this behaviour, but of course, as I'm not an expert in VTK programming, a > more relevant opinion from the experts in this forum would be appreciated. > The function that builds the VTK topology starting from what has been read > from a xmdf file is vtkXdmf3DataSet::CopyShape in the source file > vtkXdmf3DataSet.cxx (path superbuild/paraview/src/VTK/IO/Xdmf3/ in the > 5.2.0 superbuild building directory). In case of "mixed" XdmfTopologyType > (line 1460 of the file) it creates a vtkCellArray structure named vCells > that at line 1548 is passed to the SetCells function to create the > connectivity information of the DataSet. This vCells structure is filled > through the pointer *cells_ptr that is initially dimensioned with a size > equal to conn_lenght (line 1470) that is the size of the topology array > xTopology that comes form xdmf file reading. > This structure is filled as a sequence of blocks: each block for each > cell. If the cell is not a polyhedron it contains the number of points for > that cell followed by the list of pointID of the vertices. If the cell is a > polyhedron, as it's explained at lines 1531-1534, the cell information is > the sequence of: cell Lenght (that is the size of the following list for > that cell), the number of faces and, for each face, the number of points > and the list of points. So this array is exactly the same of the one that > has been read from the xdmf file, with the substitution of the cell type > for non polyhedral cells with the number of points for that cell, and, with > the substitution of the cell type with the cell lenght for polyhedral cells. > > But, after the loop on cells to fill this structure, at line 1547 there is > a call to the function Resize to reduce the Array to an overall lenght > index-sub where index is the original array lenght and sub is the number of > polyhedral cells. > > I think that this Resize call il wrong because the array lenght is correct > before this reduction. > If you print the content of the vCell structure after the Resize, for the > example of polyhedron.xmf, the last two elements of the array (that are the > last two nodes of the last hexaedron cell of the mesh) are missing. > > Probably when the SetCells function is called at line 1548 with a > cell_type array of the right lenght but a truncated vCells array as the > second argument, the missing elements of vCell array "could" be available > as they should be next in memory to the truncated array, but this is not > guaranteed because it is randomical and it depends on the operating system > (that could explain the different behaviour between linux and windows). > > In any case I've tried to comment the Resize function call and the xmdf > reader has been able to read all the cases that I've tried to read with > polyhedral and not polyhedral 3d cells (there is still a problem with > polygons but I'll write another post on this topic). > > As I've said at the beginning of this too much long message, I hope that > VTK/Paraview developers give their opinion about my hypothesis. > > Thank you > > Alessandro > > > On Thu, Dec 15, 2016 at 10:54 PM, David E DeMarle < > dave.dema...@kitware.com> wrote: > >> >> On Thu, Dec 15, 2016 at 4:39 PM, David E DeMarle < >> dave.dema...@kitware.com> wrote: >> >>> fails on windows >> >> >> some of the time. ;) >> >> If you open it up with the spreadsheet view (so no rendering), you can >> see that the cell connectivity array gets nonsense in it - some of the >> time. When you then open a renderview and show it, it crashes. >> >> So something about the read in of the connectivity data has an >> uninitialized/misaligned word somewhere. >> >> David E DeMarle >> Kitware, Inc. >> R&D Engineer >> 21 Corporate Drive >> Clifton Park, NY 12065-8662 >> Phone: 518-881-4909 <(518)%20881-4909> >> > >
_______________________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the ParaView Wiki at: http://paraview.org/Wiki/ParaView Search the list archives at: http://markmail.org/search/?q=ParaView Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/paraview
