The CrossProduct and DotProduct are field filters and therefore
fields are automatically propagated instead of calling DoMapField.
As GhostCellClassify is passing through all fields, it can
override `MapFieldOntoOutput` and skip the deduction of the
Field to an ArrayHandle for better compile time.
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.
9b78276ca Updating usage statement for temporal advection example
8e27562ce Adding information about sample datasets in example
fd23bb3c7 Update attributes to include all files in data to lfs
01d735e1a Merge branch 'master' of gitlab.kitware.com:vtk/vtk-m into fix_temporal_example
d9b038fdd Updating method name in unit test
b7191e257 Fixing temporal advection example
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Kenneth Moreland <kmorel@sandia.gov>
Merge-request: !1814
Previously, all the ApplyPolicy functions had the same name and used
template resolution to figure out which one to use. This was pretty
clear at first when there was just one for fields and one for cell sets.
But then it grew to several different types, particularly for fields. It
was hard to look at the code and figure out which form of ApplyPolicy
was being used, and compilers were starting to get confused.
Resolve the problem by giving all the methods unique names to make it
clear which one you expect to be called.
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.
There is a form of ApplyPolicy that takes a field and a value type and
returns an ArrayHandle with that value type that can be used directly.
This is implemented with an ArrayHandleMultiplexer.
For some reason, this version of ApplyPolicy magically stopped working.
The compiler, for some reason, grabbed a different overload and then
complained because it tried to use the ValueType as a list. I'm not sure
why this didn't get ignored due to SFINAE. (Maybe a compiler bug.)
At any rate, the problem is fixed by renaming that ApplyPolicy to
ApplyPolicyFieldOfType to make it clear what we are doing and to help
the compiler along.
Rather than do a CastAndCall on all possible field types when calling a
worklet with two fields (where they all typically get cast to the same
type as the primary field), use the new mechanism with
ArrayHandleMultiplexer to create one code path.
Also update the ApplyPolicy to accept the Field type, which is used to
determine any additional storage types to support.
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.
Added a BaseComponentType to VecTraits that recursively finds the base
(non-Vec) type of a Vec. This is useful when dealing with potentially
nested Vec's (e.g. Vec<Vec<T, M>, N>) and you need to keep the structure
but know the base type.
Also added a couple of templates for keeping the structure but changing
the type. These are ReplaceComponentType and ReplaceBaseComponentType.
These allow you to create new Vec's with the same structure as the query
Vec but with differen component types.
a0df206c9 Use default float to build explicit data sets
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Robert Maynard <robert.maynard@kitware.com>
Merge-request: !1830
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.
1df07f739 Adding testing paths for Curvilinear case
f45491281 Merge branch 'master' of gitlab.kitware.com:vtk/vtk-m into grid_eval_curvilinear_grids
1697ca48c Adding testing paths for Curvilinear case
507336f14 More cases for Grid Evaluator
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Matt Larsen <larsen30@llnl.gov>
Merge-request: !1811
Adding testing paths for curvilinear case
Changing names of interpolation helpers to be consistent
Rectifying interpolation helper error messages to reflect correct
location and types of failures
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.
Originally, only files in the base directory were put into lfs.
With this change, all files in any subdirectory are also put into
lfs.
Also adding the test files for temporal advection to the data directory.
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
