An update will be applied December 9th, between 12PM and 1:00PM EST (UTC -5:00). The site may be slow during that time.

  1. 01 Dec, 2017 3 commits
  2. 29 Nov, 2017 2 commits
  3. 27 Nov, 2017 3 commits
  4. 23 Nov, 2017 1 commit
  5. 21 Nov, 2017 4 commits
    • Allison Vacanti's avatar
    • Allison Vacanti's avatar
      Optimize the PointMap lookup in vtkExtractCells (12.8% speedup in D3). · 83d7e4cb
      Allison Vacanti authored
      Profiling reveals that most of the time executing D3 is spent in
      vtkExtractCells::findInSortedList, which implements a binary search of a sorted
      list of point ids. When testing with lucy.ply (14M points), this map requires
      ~25 random memory accesses every lookup.
      Since the algorithm is mapping cell ids, it's usually the case that the
      requested point ids will be close together in the point map array. This patch
      exploits this behavior by caching the input/output ids of the last lookup and
      using this information to reduce the number of random memory access. By knowing
      the properties of the list (unique, sorted) and the relationship between the
      inputs and outputs, the query can be restricted to a much smaller subset of the
      id map array. This also uses the CPU cache more efficiently, since less of the
      array needs to be traversed.
    • Allison Vacanti's avatar
      Replaced std::set with std::vector/sort/unique in vtkExtractCells. · a460228b
      Allison Vacanti authored
      This greatly reduces the amount of time spent building up the cell lists, as
      adding a cell to be extracted is now a constant time append operation, rather
      than an order log(N) sorted insertion.
      Using lucy.ply as a test dataset (14M points, 28M cells) with 4 processes, the
      execution time of D3 is reduced by 16.5% from 106s to 88s. The largest savings
      is in the initial distribution of the dataset under TestFixTooFewInputFiles,
      which went from 30.7s to 16.5s. There was also significant savings during the
      final redistribution under RedistributeDataSet, which went from 22.2s to 18.2s.
    • Allison Vacanti's avatar
  6. 18 Nov, 2017 2 commits
  7. 15 Nov, 2017 2 commits
  8. 10 Nov, 2017 1 commit
  9. 09 Nov, 2017 3 commits
  10. 08 Nov, 2017 2 commits
  11. 07 Nov, 2017 4 commits
  12. 06 Nov, 2017 1 commit
  13. 02 Nov, 2017 1 commit
  14. 01 Nov, 2017 1 commit
  15. 31 Oct, 2017 3 commits
  16. 29 Oct, 2017 3 commits
    • Philippe P. Pébaÿ's avatar
      Fixed a bug · e93c5500
      Philippe P. Pébaÿ authored
    • Philippe P. Pébaÿ's avatar
      Rewrite HTG cell centers filter as a HTG algorithm sub-class · e26f1910
      Philippe P. Pébaÿ authored
      The motivation for this refactoring was quite simple: amongst
      all ancient (but renovated) and new hypetree grid filters, which
      were part of the recently merged "HyperTreeGrid Version 2" branch,
      the HTG CellCenters filter stood out as the only one which was
      not deriving from vtkHyperTreeGridAlgorithm, which had also been
      reworked entirely for this new version of HTG support.
      This was because vtkHyperTreeGridCellCenters was, initially,
      deriving from the vtkCellCenters class in Filters/General.
      As VTK does not support multiple inheritance, it was left that
      way but that was not consistent with our overall approach of
      making all HTG algorithms derive from a single base class, in
      the double goal of facilitating both the writing of new HTG
      filters and their maintenance in the long run.
      The current commit thus provides a re-writing of the HTG cell
      center creating algorithm as subclass of vtkHyperTreeGridAlgorithm
      while preserving the outside appearance of a vtkCellCenter-derived
      filter in its API, specifically by introducing a VertexCells
      instance variable in order to mimic that which is provided
      in vtkCellCenters.
      Note that no new unit tests are provided as part of this commit,
      for the 4 existing ones for the previous incarnation of the HTG
      cell center filter are still passing with unchanged results (as
      they should indeed).
    • Philippe P. Pébaÿ's avatar
      Fixed a bug in the Moore supercursor · baef249b
      Philippe P. Pébaÿ authored
      The goal of this commit was to fix a bug that occurred only in
      the (f=2;d=3) case ("binary 3D"), and that had been caused
      by a typo in the MooreChildCursorToChildTable and
       MooreChildCursorToParentCursorTable tables: specifically,
      a "23" had been written instread of "32".
      In addition, two non-regression tests, as well as their baseline
      images, were added in order to validate this fix:
      (i) a geometry case which does not exercise the offending part of
      the code but that illustrates the case built to do it; and
      (ii) a contouring case that does exercise that part of the code,
      for it relies on the "32" section of the Moore supercursor tables.
  17. 27 Oct, 2017 1 commit
  18. 25 Oct, 2017 2 commits
    • Cory Quammen's avatar
      Remove error message in vtkPKdTree::VolumeBounds() · 2645784e
      Cory Quammen authored
      The code executes fine when this condition is encountered, so the
      error message has been converted to a code comment instead.
    • Cory Quammen's avatar
      Ensure that all processes in subgroup invoke collectives · 68921645
      Cory Quammen authored
      In a distributed dataset where some processes have datasets with no
      points or cells, not all processes would invoke the same collective
      communication operations in
      vtkPKdTree::CreateGlobalDataArrayBounds(). This would lead to a
      deadlock in pvserver where processes waited for messages that never
      This is solved by distributing the maximum number of cell and point
      data arrays to all processes so that they all participate in the
      collective operations.
  19. 24 Oct, 2017 1 commit