The `MultiBlock` class has been renamed to `PartitionedDataSet`, and its API
has been refactored to refer to "partitions", rather than "blocks".
Additionally, the `AddBlocks` method has been changed to `AppendPartitions` to
more accurately reflect the operation performed. The associated
`AssignerMultiBlock` class has also been renamed to
`AssignerPartitionedDataSet`.
This change is motivated towards unifying VTK-m's data model with VTK. VTK has
started to move away from `vtkMultiBlockDataSet`, which is a hierarchical tree
of nested datasets, to `vtkPartitionedDataSet`, which is always a flat vector
of datasets used to assist geometry distribution in multi-process environments.
This simplifies traversal during processing and clarifies the intent of the
container: The component datasets are partitions for distribution, not
organizational groupings (e.g. materials).
Ref #405
One of the dashboard compilers was complaining about not being able to
resolve which overload to use for std::size_t. (Perhaps on CUDA
std::size_t is sometimes not an unsigned 64-bit integer.) Try to correct
this by adding a templated method that casts anything to vtkm::UInt64.
The functions GetHumanReadableSize and GetSizeString accepted a
vtkm::UInt64 as the size, which should hold pretty much any reasonable
memory size and is compatible with std::size_t. But it has a different
sign-ness as vtkm::Id. So if you are holding an array size with vtkm::Id
(which is common), you could get a compiler warning when using these
functions, which is annoying. So, for convenience add a second form of
these methods that takes a vtkm::Id and automatically converts.
By removing the ability to have multiple CellSets in a DataSet
we can simplify the following things:
- Cell Fields now don't require a CellSet name when being constructed
- Filters don't need to manage what the active cellset is
74e0c5804 Fix some precision warnings
75a060a24 Fix cell derivatives for polygon cell shape
b0b000263 Write out all test data sets in VTKDataSetWriter
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Robert Maynard <robert.maynard@kitware.com>
Merge-request: !1819
For polygon cell shapes (that are not triangles or quadrilaterals),
interpolations are done by finding the center point and creating a
triangle fan around that point. Previously, the gradient was computed in
the same way as interpolation: identifying the correct triangle and
computing the gradient for that triangle.
The problem with that approach is that makes the gradient discontinuous
at the boundaries of this implicit triangle fan. To make things worse,
this discontinuity happens right at each vertex where gradient
calculations happen frequently. This means that when you ask for the
gradient at the vertex, you might get wildly different answers based on
floating point imprecision.
Get around this problem by creating a small triangle around the point in
question, interpolating values to that triangle, and use that for the
gradient. This makes for a smoother gradient transition around these
internal boundaries.
Although convenient, one of the issues of creating data with
MakeTestDataSet is that it is hard to look at the data created. It is
often helpful to be able to bring in the data into something like
ParaView or VisIt to play with it. To enable that, write them all out as
part of UnitTestVTKDataSetWriter.
e34639818 Add example data file.
cbc6e2e7c don't need know the pos in string::find.
c56e53b6c Simplify particle advection example
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !1816
This is a work around while we wait on requiring CMake 3.15 for all
cuda builds. At that point we can replace this with setting
`requires_static_builds` as part of the EXPORT_PROPERTIES of the
vtkm_cuda target.
This has been tested with the ascent proxy
a9bbb6ead Permute cells inline
d37ab7732 Add ability to read FIELD section in vtk legacy files
19a610f5e Fix skipping over information in vtk files
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Sujin Philip <sujin.philip@kitware.com>
Merge-request: !1797
1f8030a6e Add non-const version of DataSet::Get methods
69226803c Make PointTransform actually transform the points
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Robert Maynard <robert.maynard@kitware.com>
Merge-request: !1803
93c5c50b9 Ensure that the serial device is enabled during part of OrientNormals test.
ff7db9780 Add RuntimeDeviceTracker::PrintSummary for debugging.
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Robert Maynard <robert.maynard@kitware.com>
Merge-request: !1810
This is a work around while we wait on requiring CMake 3.15 for all
cuda builds. At that point we can replace this with setting
`cuda_architecture_flags` as part of the EXPORT_PROPERTIES of the
vtkm_cuda target.
This has been tested with the ascent proxy
Once #377 is implemented we won't need this, but for now we have to
use the serial connectivity tables while validating the OrientNormals
output. Ensure that the serial device can be used during the validation
stage.
A non-const version of GetCoordinateSystem was added to implement a
change to the point transform filter. To make things symmetric (and
provide likely future needs), also add non-const versions of getting the
fields and cell sets.
The poly data and unstructured grid readers have to permute the cell
data to componsate for differences between VTK and VTK-m cell shapes.
Previously, this permutation was implemented by casting the read data to
a type and then changing the data. However, some code paths caused the
cast to fail. Get around that by doing the permutation in line when the
data are read.
Previously, the VTK file readers just skipped over everything in FIELD
sections. However, it is common for many point and cell fields to be
written in this section (it is how ParaView writes out most of its
data). This change will allow these fields to be read in correctly.
Previously, if a legacy VTK file had a METADATA section with an
INFORMATION subsection, the reader did not skip over it correctly.
Instead, it just read the rest of the file (and often encountered an
error). Change this to read and skip over the INFORMATION subsection
correctly.
The primary (likely only) use of PointTransform is to perform affine
transform on the position of the mesh. However, PointTransform did not
actually move the mesh. Rather, it just created a new field with the
transformed points.
Now, the output has its coordinate system replaced with the transformed
one generated (in addition to be added as a field). This can be turned
off (but defaults to on).
Also changed the constructor to turn on UseCoordinateSystemAsField so
that by default the filter operates on the existing coordinate system
and replaces it with the new coordinate system.
Also removed the template parameter on the filter. That added an
unnecessary complication to using it.
884616788 Simplify and extend AtomicArray implementation.
9560c4f63 Limit testing dispatch of atomic array to only atomic types.
0e728c800 Update atomic interfaces to support Add/CAS for UInt32/64.
720b452eb Force AtomicArray to use only basic storage arrays.
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Robert Maynard <robert.maynard@kitware.com>
Merge-request: !1802
