f025c218 Suppress conversion warning inside Cell Interpolate code
822d4c61 Marching Cubes test doesn't abuse fall through case statements
dac7ab98 Correct a bad memcpy in ColorTable that gcc 7 found
c6726644 Reformat some test code to stop gcc 7.3 from segfaulting.
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Utkarsh Ayachit <utkarsh.ayachit@kitware.com>
Merge-request: !1175
Somehow deducing the parameters to a static function was causing
gcc to segfault and crash. Changed around the code to use a free
function and everything works properly
The usage of uint was causing problems with CUDA + MSVC2015 as
type was not defined. Instead we use vtkm::Id as that was the expect
type to be passed to the task
This allows for easier host side logic when determining grid and block
sizes, and allows for a smaller library side by moving some logic
into compiled in functions.
Previously, when a Worklet needed a scatter, the scatter object was
stored in the Worklet object. That was problematic because that means
the Scatter, which is a control object, was shoved into the execution
environment.
To prevent that, move the Scatter into the Dispatcher object. The
worklet still declares a ScatterType alias, but no longer has a
GetScatter method. Instead, the Dispatcher now takes a Scatter object in
its constructor. If using the default scatter (ScatterIdentity), the
default constructor is used. If using another type of Scatter that
requires data to set up its state, then the caller of the worklet needs
to provide that to the dispatcher. For convenience, worklets are
encouraged to have a MakeScatter method to help construct a proper
scatter object.
Adding API to DataSet to `CopyStructure` from another dataset. This
copies the cellsets and coordinate systems while leaving the fields
unchanged.
CreateResult no longer copies all input fields to the output dataset
created.
Furthermore, if a Filter subclass doesn't provide `MapFieldOntoOutput`,
then the default implementation simply copies only the selected fields
to the output dataset.
Minimizing the need to have complex serialization code in vtkm/cont.
This is first step in moving DIY serialization code out of vtkm/cont. We
need to move that to filter so we can leverage policy correctly
serialize fields.
`vtkm_unit_tests` now supports an MPI option that can be used to add
test that run with MPI. Adding `UnitTestFieldRangeGlobalCompute` to test
global ranges for fields.
Removing another API that need not be on MultiBlock. There's generally
no need for apps to know this. If needed, we can add `...Compute`
function. This removes another API on MultiBlock that could trigger
parallel communication/synchronization.
Removing MultiBlock::GetGlobalRange API to keep things consistent with
DataSet API. Instead, one should use `FieldRangeCompute` or
`FieldRangeGlobalCompute` as appropriate.
c1237969 VTK-m ArrayHandle can now take ownership of a user allocated memory location
707970f4 VTK-m StorageBasic is now able to give/take ownership of user allocated memory.
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Kenneth Moreland <kmorel@sandia.gov>
Merge-request: !1137
Previously memory that was allocated outside of VTK-m was impossible to transfer to
VTK-m as we didn't know how to free it. By extending the ArrayHandle constructors
to support a Storage object that is being moved, we can clearly express that
the ArrayHandle now owns memory it didn't allocate.
Here is an example of how this is done:
```cpp
T* buffer = new T[100];
auto user_free_function = [](void* ptr) { delete[] static_cast<T*>(ptr); };
vtkm::cont::internal::Storage<T, vtkm::cont::StorageTagBasic>
storage(buffer, 100, user_free_function);
vtkm::cont::ArrayHandle<T> arrayHandle(std::move(storage));
```
This fixes the three following issues with StorageBasic.
1. Memory that was allocated by VTK-m and Stolen by the user needed the
proper free function called which is generally StorageBasicAllocator::deallocate.
But that was hard for the user to hold onto. So now we provide a function
pointer to the correct free function.
2. Memory that was allocated outside of VTK-m was impossible to transfer to
VTK-m as we didn't know how to free it. This is now resolved by allowing the
user to specify a free function to be called on release.
3. When the CUDA backend allocates memory for an ArrayHandle that has no
control representation, and the location we are running on supports concurrent
managed access we want to specify that cuda managed memory as also the host memory.
This requires that StorageBasic be able to call an arbitrary new delete function
which is chosen at runtime.
Adding a new exception type `vtkm::cont::ErrorFilterExecution`. Unlike
existing exceptions, when thrown in `TryExecute`, this exception causes
the call to not attempt to execute on any other devices and let it be
thrown so that the application can catch it.
3a812b04 Make default ColorTable preset
3391e5d2 Basic interface changes to FieldToColors
a3b2c393 Remove default constructor for ColorTable
cb8a05c7 Add a preset enum to ColorTable
97a24559 Make LAB the default color space
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Robert Maynard <robert.maynard@kitware.com>
Merge-request: !1133
Changed the "default" ColorTable preset from "cool to warm" to
"viridis." Also made a default constructor for ColorTable that sets it
to this default preset.
The main reason to change to viridis for the default is that it is in
LAB space. We are concerned that having the default ColorTable preset
being Diverging space could lead to users using that color space
inappropriately.
The problem is that there is no good "default" constructor for
ColorTable. The previous default constructor created an empty color
table, but that would be confusing if someone actually tried to use it.
We could set ot to the default preset, but the default preset uses the
diverging color map, which could foul people up if they actually want to
edit or create their own color map. Instead, force the declaration of
ColorTable to indicate what you plan to do with it.
You can still select presets through strings (and we leave ourselves
open to add more presets through strings than enumerating with the
enum), but this provides a way to select a preset that is verified by
the compiler.
This fixes several issues with how DIY was used in MultiBlock.
Instead of using `diy::RegularSwapPartners` using
`diy::RegularMergePartners` to reduce data to block(gid=0) and then
broadcast out to all ranks (and not blocks) using
`diy::RegularBroadcastPartners`. Old code that used RegularSwapPartners
ended up building reduced result on all blocks, which was not only
unnecessary, but expensive since we would generally have more blocks
than ranks.
Remove `DecomposerMultiBlock`. This class was needed due to my
misunderstanding of how the decomposer works.
`diy::RegularDecomposer<diy::DiscreteBounds>` provides all the necessary
functionality provided by `DecomposerMultiBlock`.
