This provides the ability to convert an array handle of an unknown value
type to an array handle that has `vtkm::FloatDefault` as its base
component type. Thus subsequently lets you pull the components as
`vtkm::FloatDefault` without having to worry about type conflicts.
There was an error that caused deprecation warnings in VTK-m to be
suppressed, which meant that many uses of deprecated features went
unnoticed. This fixes those deprecation warnings.
The majority of the warnings were caused by the use of the deprecated
`Cast`, `CopyTo`, and `ResetTypes` methods of `UnknownArrayHandle` (or
`VariantArrayHandle`). Both `Cast` and `CopyTo` have been subsumed by
`AsArrayHandle` (to make the functionality more clear). `ResetTypes` now
requires a second template argument to define the storage types to try.
Also fixed some issues with `SerializableField` being deprecated.
This class is no longer necessary because `Field` can now be directly
serialized.
Field.h had a runaway deprecation suppression where the pragmas to
suppress deprecation warnings were turned on but not properly turned
off. This caused deprecation warnings to be turned off for anything
including Field.h (directly or indirectly), and consequently lots of use
of deprecated features went unnoticed.
There are several places in the ray casting library that require
operating on a field that we know is a scalar field. Previously, these
were all independently cast to an uncertain array of the limited types.
Rather than have independent calls everywere, make a consolidated
function that does the same operation for everyone.
This fixes an issue with using a deprecated version of a method. It also
makes it possible to quickly change types in the future.
61522fde7 Add #includes and explicitly identify the field name.
1bad28a3e Logistic map as an example of how to use the ImageWriter.
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Nickolas Davis <nadavi@sandia.gov>
Merge-request: !2385
081f8aaea reformat if statements, add comments on the HDF5 macros
31aa46706 Merge branch 'master' into hdf5_image_io
e65c0713b move #include of hdf5.h into .cxx files
ff0b8fd0b changed to CMake files based on Robert's feedback
ca0ce4de7 Merge branch 'master' into hdf5_image_io
23a95f864 exclude header files from install check when it is not enabled
d81f08eed correct copyright mesage
fb6c9afe7 uncomment ubuntu1805_cuda image
...
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Li-Ta Lo <ollie@lanl.gov>
Acked-by: Robert Maynard <robert.maynard@kitware.com>
Merge-request: !2371
3a7ba1d56 Fix deprecation warning in MSVC
11a4c9867 Change Field to hold UnknownArrayHandle rather than VariantArrayHandle
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Sujin Philip <sujin.philip@kitware.com>
Merge-request: !2298
MSVC tends to give deprecation warnings in templated methods that are
used with deprecated classes rather than where the deprecated thing was
declared. That makes it annoyingly hard to supress them to implement
support of deprecated items.
The `VariantArrayHandle` will soon be deprecated for its replacement of
`UnknownArrayHandle`. Thus, `Field` and related classes should start
using the new `UnknownArrayHandle`.
The compile error happened from incompatible code changes between !2349
and !2374. The former removed the ability to use non-`Vec` values in
`ArrayHandleSOA`. The latter tried to create such an `ArrayHandle`
inside a template function that was called with the SOA storage.
cecd81d5d Add types appropriate for Ascent
865855ea0 Add changelog for making ArrayHandleSOA a default array
50ff9c22a Add support of `ArrayHandleSOA` as a default storage type
bc09a9cd1 Add precompiled versions of `ArrayRangeCompute` for `ArrayHandleSOA`
77f9ae653 Support `ArrayHandleSOA` only for `Vec` value types
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Robert Maynard <robert.maynard@kitware.com>
Merge-request: !2349
3228752b2 Fix error message when using deprecated storage
5ef4e7eee Make new style of ArrayHandle the expected style
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Robert Maynard <robert.maynard@kitware.com>
Merge-request: !2375
9ed68f5a4 Add default copy constructor for `RecombineVec`
66fbc99b0 Disable ArrayHandleCounting for invalid value types
0b2dbfdda Fix ICE in GCC 4.8
50d932013 Add missing types to serialization of UnknownArrayHandle
ab9c0f724 Add arithmetic assignment operators to `RecombineVec`
1cc6dbb0c Allow `VecBaseCommon` operators to work with any `Vec`-like
74536d4ca Support `Vec` operators on `ArrayPortalValueReference`
06c59fed1 Update MapFieldMergeAverage/Permuation to use new CastAndCall
...
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Robert Maynard <robert.maynard@kitware.com>
Merge-request: !2381
`ArrayHandleCounting` only works with values that support basic
arithmetic. The concept of counting makes little sense for types that
are not well defined for addition and multiplication like `bool`,
`string` and other custom types.
`RecombineVec` is the class used as the value type for
`ArrayHandleRecombineVec`. It is a `Vec`-like object, but has several
limitations (including arithmetic operators like `+` won't work).
Arithmetic assignment operators are useful so you don't have to create
impossible intermediate values.
Previously, the arithmetic assignment operators (`+=`, `-=`, `*=`, `/=`)
on `VecBaseCommon` only accepted another subclass of `VecBaseCommon`.
Changed the operators to accept any type.
The benefit of this change is that the assignment operator of classes
that inherit from `VecBaseCommon` can now work with `Vec`-like classes
that do not inherit from `VecBaseCommon`. I think the only real downside
is that the template could match other classes that would lead to
invalid comparisons. But such use would lead to a compile error anyway.
The difference is that instead of getting an error that no overloaded
version of the operator is available, you will get an error inside the
code of the operator.
