There are still some warnings left:
* Some text in markdown files are incorrectly picked up as
doxygen commands
* ArrayPortalTransform weirdly inherits from a specialized
version of itself. It's technically correct C++ code, but
gives doxygen fits.
Sandia National Laboratories recently changed management from the
Sandia Corporation to the National Technology & Engineering Solutions
of Sandia, LLC (NTESS). The copyright statements need to be updated
accordingly.
c5232e99 Simplify the implementation of vtkm::ForEach
6069c19f Brigand.hpp now works around CUDA 9 compiler issues.
6a4e91d5 ExecutionPolicy now handles CUDA9 removal of __CUDACC_VER__
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !902
1d5a4d47 Update ExternalFaces worklet to use hashes
fc7b90ac Add hash function
b1e6c1e3 Add method for getting a cononical edge id
8e72dc73 Add method for getting a cononical face id
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !900
Previously once an ArrayHandle was stolen it was placed in an invalid state
where it could not used again by VTK-m. Now instead after being stolen it
is placed into a state where it is identical to memory allocated outside
of VTK-m and passed in.
All types of cell sets should have a consistent interface. This is
tested (and fixed) for explicit and permutation cell sets. However, an
unfixed bug that has been identified is that permutation cell sets only
work for point to cell topologies. All others are not supported
correctly.
Redesigns the TBB and Serial backends and the vtkm::exec::Task concept so that
we can re-use the same launching logic for all Worklets, instead of generating
per worlet code. To keep the performance the same the TilingTask now is past
a range of indices to work on, rather than a single index.
Binary size reduction:
WorkletTests_SERIAL old - 19MB
WorkletTests_SERIAL new - 18MB
WorkletTests_TBB old - 39MB
WorkletTests_TBB new - 18MB
libvtkAcceleratorsVTKm old - 48MB
libvtkAcceleratorsVTKm new - 19MB
Previously when you permuted a structured cellset you would get a permuted
point coordinates. This would cause the Cell operations to take non
optimal paths.
Previously WorkletInvokeFunctor inherited from vtkm::exec::FunctorBase,
which is also the base class for all users Worklets and for all functors
based to DeviceAdapter::Schedule.
This is done for a few reasons. The first is that we reduce the
minimum size of user worklets. Previously the users worklet would hold
a reference to the error message, and so would the wrapper class added
when calling DeviceAdapter::Schedule. Now we only have the users worklet
holding a reference.
Second, by refactoring to have two base classes we can better improve
the documentation on what responsibilities FunctorBase.h has, compared
to TaskBase.
The current design for ArrayPortalVirtual makes it a requirement for all
array portals (that it wraps) to have Set defined. Thus, make sure Set is
defined for all ArrayPortal. Where Set is invalid, an assert is thrown if
something calls it at runtime.
Previously, ExternalFaces really only supported tetrahedral meshes that
have only triangular faces. These changes support all mixes of cells and
their faces.
Most functions in the CUDA runtime API return an error code that must be
checked to determine whether the operation completed successfully. Most
operations in VTK-m just called the function and assumed it completed
correctly, which could lead to further errors. This change wraps most
CUDA calls in a VTKM_CUDA_CALL macro that checks the error code and
throws an exception if the call fails.
The cell derivative/gradient functions were all designed with scalars in
mind. Although the field type is templated and you could pass in a
vector type for the field, many of these classes would perform the
computation incorrectly. These changes specifically support derivatives
of vector types.
The shape array in CellSetExplicit was changed a while ago to be of type
vtkm::UInt8. However, the shape types remained at vtkm::IdComponent. I
can think of no reason why they should not be the same type.
Change the VTKM_CONT_EXPORT to VTKM_CONT. (Likewise for EXEC and
EXEC_CONT.) Remove the inline from these macros so that they can be
applied to everything, including implementations in a library.
Because inline is not declared in these modifies, you have to add the
keyword to functions and methods where the implementation is not inlined
in the class.
8dadf560 Add in support for vector fields to Gradient worklet.
d53f43fb CellDerivaties now support computing the derivatives of vtkm::Vec fields.
b4378c85 Allow vtkm::Matrix to support T values which are vtkm::Vec.
9caabf97 vtkm::Vec now supports +=, -=, *=, and /=.
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Kenneth Moreland <kmorel@sandia.gov>
Merge-request: !608
This usage of raw_referenc_cast returns a const PortalValue which is than
assigned too. So to work around the problem we need to mark operator= on
the class as const.
There were many tests that created code paths for every base and Vec
type that VTK-m supports (up to 4 components). Although this is
admirable, it is also excessive, and our compile times for the tests are
very long.
To shorten compile times, remove the TryAllTypes method. Replace it with
a version of TryTypes that uses a default list of "exemplar" set of
integers, floats, and Vecs.
The UnitTestParametricCoordinates test uses a pseudorandom number
generator to create some random set of parametric coordinates, convert
to world coordinates, and then back to parametric coordinates.
This has been working fine except that the world coordinate to parametric
coordinate conversion is not extremely precise for some cell shapes. (It
would not be cost effective to make it more precise.) Because of this,
the test_equal for this comparison has a pretty high threshold.
While looking at a dashboard I happened across a failure for this test.
It turns out that one of the parametric coordinates created for the
pyramid test for seed 1465529014 was just outside of this threshold, but
otherwise correct. I raised the threshold a little to try to prevent
this error.
ThreadIndicies constructor was templated on the invocation type, which created
thousand's of versions of that symbol which all had the same behavior. So now
remove that and move that logic into a Worklet function since it requires
the invocation info.
These asserts are consolidated into the unified Assert.h. Also made some
minor edits to add asserts where appropriate and a little bit of
reconfiguring as found.
All the other math functions are in the vtkm package. This one was in
vtkm::exec because it uses a callback method. This can be problematic on
CUDA the the declaration of NewtonsMethod does not match the callback
method. However, we now have a VTKM_SUPPRESS_EXEC_WARNINGS macro that
allows a VTKM_EXEC_CONT_EXPORT function (like NewtonsMethod) to call
either a VTKM_EXEC_EXPORT or VTKM_CONT_EXPORT without a warning.
