1. 29 May, 2016 1 commit
  2. 26 May, 2016 1 commit
    • Robert Maynard's avatar
      Simplify the bounds computation code to reduce library size. · 06a06b52
      Robert Maynard authored
      The previous version of the bounds code required once less pass across
      the data, but significantly increase the size of the resulting library:
      Data for VTK-VTK-m interop:
        - 7k more symbol table entries
        - 1.5MB larger library
      Because of the significant savings we need to use a less efficient
      implementation that minimized the code size.
  3. 20 Apr, 2016 1 commit
  4. 23 Mar, 2016 1 commit
  5. 14 Mar, 2016 1 commit
  6. 21 Jan, 2016 1 commit
    • Kenneth Moreland's avatar
      Fix issues with Field constructor overloads · f9750e83
      Kenneth Moreland authored
      I ran into a few minor issues with the constructors to the Field class.
      The big change I made was that I removed the Field constructors that
      take an example type and create an empty field of that type. The problem
      was that the example type was easily confused with some other type that
      was supposed to describe an array. This lead to some odd behavior in the
      compiler and resulted in errors in unexpected places.
      The use case for this constructor is dubious. There were several tests
      in the code that would create an empty field, add it to a data set, then
      get it back out to pass to the worklet. The code is much simpler if you
      just make an ArrayHandle of the right type and use that in the worklet
      invoke directly. It is also faster to compile with smaller code because
      the type is known statically (whereas it is lost the other way).
      The other change was to declare references to ArrayHandle and
      DynamicArrayHandle as const. There is nothing in the behavior that
      invalidates the const, and it accepts arrays constructed in the
  7. 04 Jan, 2016 1 commit
  8. 27 Aug, 2015 1 commit
    • Kenneth Moreland's avatar
      Make PrintSummary actually work for Field and CoordinateSystem. · 9cd8cb22
      Kenneth Moreland authored
      The PrintSummary for CoordinateSystem went in an infinite loop. It was
      supposed to call PrintSummary of its superclass (Field), but instead it
      called itself.
      The PrintSummary for Field only worked for fields of type vtkm::Float32.
      To make it work for all array types, I added a PrintSummary method to
      DynamicArrayHandle, and Field calls that without trying to cast to a
      static type.
  9. 25 Aug, 2015 5 commits
    • Kenneth Moreland's avatar
      CoordinateSystem handles uniform point coordinates. · a99f828c
      Kenneth Moreland authored
      The point of making CoordinateSystem a special type of Field object
      was so that it could handle special array types like implicit regular
      point coordinates. Overload the GetData and GetBounds methods to
      properly handle this type of array.
    • Kenneth Moreland's avatar
      Refactor DynamicArrayHandle to have a common base. · 51f0100b
      Kenneth Moreland authored
      Originally, DynamicArrayHandle only automatically handled the default
      type and storage lists. There was an internal subclass that expanded
      that to user defined lists, but it was a bit inaccessible. This change
      makes DynamicArrayHandle match the structure of DynamicCellSet. There is
      now a templated base class named DynamicArrayHandleBase that can accept
      any pair of lists. DynamicArrayHandle itself is really just a typedef of
      DynamicArrayHandleBase with the default lists.
    • Kenneth Moreland's avatar
      Have CoordinateSystem inherit from Field · 9f624f0a
      Kenneth Moreland authored
      Previously, coordinate systems in a DataSet simply pointed to field data
      specifying the coordinate information (although the ability to get that
      back out of the DataSet was missing). This makes sense since point
      coordinates are in fact just fields with a particular semantic meaning
      to them.
      However, there is an issue with this approach. It turns out that there
      are special representations that are very common for point coordinates
      and very uncommon for other types of fields. For example, a uniform
      (a.k.a. regular or image) grid has point coordinates that are easily
      derived from the point index, but such fields are quite uncommon
      Representing this kind of structure in the Field list of a DataSet is
      problematic. Either all fields have to check to see if they are this
      type, which will cause an explosion of unnecessary generated code, or
      you will have to actually write out the coordinates in memory, which is
      really wasteful but what was done previously.
    • Jeremy Meredith's avatar
      adding case for new "ANY" association. · 34112645
      Jeremy Meredith authored
    • Jeremy Meredith's avatar
      adding ability to specify an association type when requesting fields. · 9c77b56b
      Jeremy Meredith authored
      also adding testing of GetField to UnitTestDataSet tests.
  10. 12 Aug, 2015 2 commits
  11. 03 Aug, 2015 1 commit
    • Kenneth Moreland's avatar
      Change Node -> Point · 01757ea1
      Kenneth Moreland authored
      Most of VTK-m follows the convention of calling the 0D topology elements
      "points" (which follows the convention of VTK). However, there were
      several places where they were referred to as "nodes." Make things
      consistent by calling them points everywhere.
      Also merged some redundant ExecutionSignature tags.
  12. 30 Jul, 2015 1 commit
  13. 27 Jul, 2015 1 commit
    • Kenneth Moreland's avatar
      Conform DataSet classes to coding practices better · 19db32f0
      Kenneth Moreland authored
      The most common changes were making class members uppercase and spelled
      out, adding "this->" whenever a class member is used, and declare
      functions and members with export macros. Also fixed some uses of int
      (instead of vtkm::Id or something similar) and a bit of indentation. I
      also sprinkled some const goodness over the code.
      It should be noted that I had about a week delay between first making
      these changes and checking them in. In the mean time Sujin also made
      some similar changes, so there might be some repetative changes.
  14. 23 Jul, 2015 1 commit
  15. 22 Jul, 2015 1 commit
  16. 13 Jul, 2015 4 commits
  17. 08 Jun, 2015 1 commit
  18. 04 Jun, 2015 1 commit
  19. 03 Jun, 2015 1 commit
  20. 29 May, 2015 3 commits
  21. 20 May, 2015 1 commit
  22. 19 May, 2015 2 commits
  23. 11 May, 2015 1 commit
  24. 15 Apr, 2015 1 commit
  25. 10 Feb, 2015 1 commit
  26. 04 Feb, 2015 1 commit
  27. 24 Jun, 2014 1 commit
    • Kenneth Moreland's avatar
      Change ArrayContainerControl to Storage. · 21823500
      Kenneth Moreland authored
      After a talk with Robert Maynard, we decided to change the name
      ArrayContainerControl to Storage. There are several reasons for this
      1. The name ArrayContainerControl is unwieldy. It is long, hard for
      humans to parse, and makes for long lines and wraparound. It is also
      hard to distinguish from other names like ArrayHandleFoo and
      2. The word container is getting overloaded. For example, there is a
      SimplePolymorphicContainer. Container is being used for an object that
      literally acts like a container for data. This class really manages
      3. The data does not necessarily have to be on the control side.
      Implicit containers store the data nowhere. Derivative containers might
      have all the real data on the execution side. It is possible in the
      future to have storage on the execution environment instead of the
      control (think interfacing with a simulator on the GPU).
      Storage is not a perfect word (what does implicit storage really mean?),
      but its the best English word we came up with.
  28. 15 May, 2014 1 commit
    • Kenneth Moreland's avatar
      Add classes to manage point coordinates. · 7d769a8f
      Kenneth Moreland authored
      Each type of point coordinates has its own class with the name
      PointCoordinates*. Currently there is a PointCoordiantesArray that contains
      an ArrayHandle holding the point coordinates and a PointCoordinatesUniform
      that takes the standard extent, origin, and spacing for a uniform rectilinear
      grid and defines point coordiantes for that. Creating new PointCoordinates
      arrays is pretty easy, and we will almost definitely add more. For example,
      we should have an elevation version that takes uniform coordinates for
      a 2D grid and then an elevation in the third dimension. We can probably
      also use a basic composite point coordinates that can build them from
      other coordinates.
      There is also a DynamicPointCoordinates class that polymorphically stores
      an instance of a PointCoordinates class. It has a CastAndCall method that
      behaves like DynamicArrayHandle; it can call a functor with an array handle
      (possible implicit) that holds the point coordinates.
  29. 03 Apr, 2014 1 commit
    • Kenneth Moreland's avatar
      Add a dynamic array handle. · d309fa7a
      Kenneth Moreland authored
      The dynamic array handle holds a reference to an array handle of an
      unknown type. It contains the ability to try to cast it to an instance
      of array handle or to try lists of types and containers.
      There is currently an issue that is causing the test code not to
      compile. It is the case that some combinations of types and containers
      are not compatible. For example, an implict container is bound to a
      certain type, and the container is undefined if they do not agree. There
      needs to be a mechanism to detect these invalid combinations and skip
      over them in the MTP for each.