630768600 Suppress CUDA warnings
5fa02057a Rely less on overload resolution for ApplyPolicy
26d7bfd0d Force ArrayPolicy of a specific type to the right template
6c136b978 Remove vtkm::BaseComponent
07c59fcf7 Update filters with secondary fields to use new policy method
3039a18ba Add ability to get an array from a Field for a particular type
2b6e6da6c Add ability to get VariantArrayHandle as an ArrayHandleMultiplexer
6323d6803 Add recursive component queries to VecTraits
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Robert Maynard <robert.maynard@kitware.com>
Merge-request: !1829
There was a warning comes from the functors in support of the portals
for ArrayHandleMultiplexer. The template has no good way to determine
whether the object it is calling is for control or execution, so it
supports both. It is not useful to warn when it happens to compile only
for the host.
Sometimes the CUDA runtime would not allocate sufficient stack
space for the particle advection code to run. This issue was exposed by
!1737 -- for some reason, once those changes to unrelated filters/worklets
are added to VTK, CUDA allocates less stack and the following tests would
fail:
UnitTestLagrangianFilterCUDA
UnitTestLagrangianStructuresFilterCUDA
UnitTestStreamlineFilterCUDA
UnitTestStreamSurfaceFilterCUDA
These were fixed by increasing the stack size in the particle advection
worklet Run(...) methods.
An RAII helper has been added that will restore the previous stack size
in case an exception is thrown, and the KDTree code has been updated
to use this helper when it adjusts the CUDA stack allocation.
This is done through a new version of ApplyPolicy. This version takes
a type of the array as its first template argument, which must be
specified.
This requires having a list of potential storage to try. It will use
that to construct an ArrayHandleMultiplexer containing all potential
types. This list of storages comes from the policy. A StorageList
item was added to the policy.
Types are automatically converted. So if you ask for a vtkm::Float64 and
field contains a vtkm::Float32, it will the array wrapped in an
ArrayHandleCast to give the expected type.
The DataSetBuilderExplicitIterative class used to use an ArrayHandle of
vtkm::Vec3f_32 values, which are always of type Float32. This can cause
unexpected results when using double precision by default (i.e. when
FloatDefault is set to Float64). Change that to give Float32 values by
default.
IsWritableArrayHandle can now be used directly as `std::true_type` or
`std::false_type` without having to pull the `type` member out of a
dependent namespace.
This behaves just like `ScanExclusive`, but rather than returning the
total sum, it is appended to the end of the output array.
This is in preparation for the CellSetExplicit refactoring described in
issue #408.
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
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.
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
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.
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.
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
