From c1c7b0df508ea22130d8493115f6aafbd5e1deec Mon Sep 17 00:00:00 2001 From: Vicente Adolfo Bolea Sanchez Date: Mon, 24 Jun 2024 17:40:32 -0400 Subject: [PATCH] release: 2.2.0-rc1 release notes --- docs/changelog/2.2/release-notes.md | 421 ++++++++++++++++++ ...Object_Allow_order_of_atomic_operations.md | 3 - docs/changelog/add-merge-datasets-filter.md | 3 - docs/changelog/add-slice-multiple-filter.md | 3 - .../changelog/allow-backward-compatibility.md | 17 - docs/changelog/arrayhandle-getcomponents.md | 20 - .../arrayhandleconstant-extract-component.md | 9 - docs/changelog/avoid-rendering-fpe.md | 10 - docs/changelog/constant-amr-arrays.md | 8 - docs/changelog/contour-int-isovalue.md | 17 - docs/changelog/deprecate-filter-field.md | 22 - .../deprecate-reduce-by-key-count.md | 12 - .../changelog/extract-geometry-permutation.md | 13 - docs/changelog/fill-stride-arrays.md | 22 - docs/changelog/fix-old-cuda-atomics.md | 6 - docs/changelog/hints.md | 32 -- docs/changelog/intel-finites.md | 6 - docs/changelog/intel-union-placeholder.md | 17 - docs/changelog/isosurface-uncertainty.md | 7 - docs/changelog/mesh-info-constructors.md | 10 - .../new-instance-variable-components.md | 16 - docs/changelog/obsolete-thrust-patch.md | 9 - docs/changelog/safe-cuda-runtime-config.md | 7 - docs/changelog/update-warps.md | 32 -- docs/changelog/users-guide.md | 15 - docs/changelog/vecfromportal-operators.md | 8 - 26 files changed, 421 insertions(+), 324 deletions(-) create mode 100644 docs/changelog/2.2/release-notes.md delete mode 100644 docs/changelog/AtomicArrayExecutionObject_Allow_order_of_atomic_operations.md delete mode 100644 docs/changelog/add-merge-datasets-filter.md delete mode 100644 docs/changelog/add-slice-multiple-filter.md delete mode 100644 docs/changelog/allow-backward-compatibility.md delete mode 100644 docs/changelog/arrayhandle-getcomponents.md delete mode 100644 docs/changelog/arrayhandleconstant-extract-component.md delete mode 100644 docs/changelog/avoid-rendering-fpe.md delete mode 100644 docs/changelog/constant-amr-arrays.md delete mode 100644 docs/changelog/contour-int-isovalue.md delete mode 100644 docs/changelog/deprecate-filter-field.md delete mode 100644 docs/changelog/deprecate-reduce-by-key-count.md delete mode 100644 docs/changelog/extract-geometry-permutation.md delete mode 100644 docs/changelog/fill-stride-arrays.md delete mode 100644 docs/changelog/fix-old-cuda-atomics.md delete mode 100644 docs/changelog/hints.md delete mode 100644 docs/changelog/intel-finites.md delete mode 100644 docs/changelog/intel-union-placeholder.md delete mode 100644 docs/changelog/isosurface-uncertainty.md delete mode 100644 docs/changelog/mesh-info-constructors.md delete mode 100644 docs/changelog/new-instance-variable-components.md delete mode 100644 docs/changelog/obsolete-thrust-patch.md delete mode 100644 docs/changelog/safe-cuda-runtime-config.md delete mode 100644 docs/changelog/update-warps.md delete mode 100644 docs/changelog/users-guide.md delete mode 100644 docs/changelog/vecfromportal-operators.md diff --git a/docs/changelog/2.2/release-notes.md b/docs/changelog/2.2/release-notes.md new file mode 100644 index 000000000..1449e5c2d --- /dev/null +++ b/docs/changelog/2.2/release-notes.md @@ -0,0 +1,421 @@ +VTK-m 2.2.0 Release Notes +======================= + +# Table of Contents + +1. [Core](#Core) + - Enable non-finite values with Intel compiler. +2. [ArrayHandle](#ArrayHandle) + - Add `GetNumberOfComponentsFlat` method to `ArrayHandle`. + - Support `Fill` for `ArrayHandleStride`. + - Added support for component extraction from ArrayHandleConstant better. + - Store constant AMR arrays with less memory. + - Improved = operators in VecFromPortal. + - Deprecate the GetCounts() method in Keys objects. + - Enable new instances of unknown arrays with dynamic sizes. +3. [Filters and Worklets](#Filters_and_Worklets) + - Consolidate WarpScalar and WarpVector filter. + - Adding MergeDataSets filter. + - Fix bug with ExtractGeometry filter. + - New Isosurface Uncertainty Visualization Analysis filter. + - Deprecated `vtkm::filter::FilterField`. + - Adding SliceMultiple filter. + - Constructors for mesh info classes updated to conform with other filters. + - Allow floating-point isovalues for contours of integer fields. +4. [Control Environment](#Control_Environment) +5. [Execution Environment](#Execution_Environment) + - AtomicArrayExecutionObject: Allow order of atomic operations. + - Disable Thrust patch that is no longer needed in modern Thrust. + - Add hints to device adapter scheduler. +6. [Build](#Build) + - Support backward compatibility in CMake package. + - Fix issue with union placeholder on Intel compiler. + - Fix old cuda atomics. +7. [Others](#Others) + - Avoid floating point exceptions in rendering code. + - Added VTK-m's user guide into the source code. + - Fix crash when CUDA device is disabled. + +# Core + +## Enable non-finite values with Intel compiler + +The Intel compiler by default turns on an optimization that assumes that +all floating point values are finite. This breaks any ligitimate uses of +non-finite values including checking values with functions like `isnan` +and `isinf`. Turn off this feature for the intel compiler. + +# ArrayHandle + +## Add `GetNumberOfComponentsFlat` method to `ArrayHandle` + +Getting the number of components (or the number of flattened components) +from an `ArrayHandle` is usually trivial. However, if the `ArrayHandle` is +special in that the number of components is specified at runtime, then it +becomes much more difficult to determine. + +Getting the number of components is most important when extracting +component arrays (or reconstructions using component arrays) with +`UnknownArrayHandle`. Previously, `UnknownArrayHandle` used a hack to get +the number of components, which mostly worked but broke down when wrapping +a runtime array inside another array such as `ArrayHandleView`. + +To prevent this issue, the ability to get the number of components has been +added to `ArrayHandle` proper. All `Storage` objects for `ArrayHandle`s now +need a method named `GetNumberOfComponentsFlat`. The implementation of this +method is usually trivial. The `ArrayHandle` template now also provides a +`GetNumberOfComponentsFlat` method that gets this information from the +`Storage`. This provides an easy access point for the `UnknownArrayHandle` +to pull this information. + +## Support `Fill` for `ArrayHandleStride` + +Previously, if you called `Fill` on an `ArrayHandleStride`, you would get +an exception that said the feature was not supported. It turns out that +filling values is very useful in situations where, for example, you need to +initialize an array when processing an unknown type (and thus dealing with +extracted components). + +This implementation of `Fill` first attempts to call `Fill` on the +contained array. This only works if the stride is set to 1. If this does +not work, then the code leverages the precompiled `ArrayCopy`. It does this +by first creating a new `ArrayHandleStride` containing the fill value and a +modulo of 1 so that value is constantly repeated. It then reconstructs an +`ArrayHandleStride` for itself with a modified size and offset to match the +start and end indices. + +Referencing the `ArrayCopy` was tricky because it kept creating circular +dependencies among `ArrayHandleStride`, `ArrayExtractComponent`, and +`UnknownArrayHandle`. These dependencies were broken by having +`ArrayHandleStride` directly use the internal `ArrayCopyUnknown` function +and to use a forward declaration of `UnknownArrayHandle` rather than +including its header. + +## Added support for component extraction from ArrayHandleConstant better + +Previously, `ArrayHandleConstant` did not really support component +extraction. Instead, it let a fallback operation create a full array on +the CPU. + +Component extraction is now quite efficient for `ArrayHandleConstant`. It +creates a basic `ArrayHandle` with one entry and sets a modulo on the +`ArrayHandleStride` to access that value for all indices. + +## Store constant AMR arrays with less memory + +The `AmrArrays` filter generates some cell fields that specify information +about the hierarchy, which are constant across all cells in a partition. +These were previously stored as an array with the same value throughout. +Now, the field is stored as an `ArrayHandleConstant`, which does not +require any real storage. Recent changes to VTK-m allow code to extract the +array as a component efficiently without knowing the storage type. + +## Improved = operators in VecFromPortal + +Previously, `VecFromPortal` could only be set to a standard `Vec`. +However, because this is a `Vec`-like object with a runtime-size, it is +hard to do general arithmetic on it. It is easier to do in place so +there is some place to put the result. To make it easier to operate on +this as the result of other `Vec`-likes, extend the operators like `+=`, +`*=`, etc to support this. + +## Deprecate the GetCounts() method in Keys objects + +The `vtkm::worklet::Keys` object held a `SortedValuesMap` array, an +`Offsets` array, a `Counts` array, and (optionally) a `UniqueKeys` array. +Of these, the `Counts` array is redundant because the counts are trivially +computed by subtracting adjacent entries in the offsets array. This pattern +shows up a lot in VTK-m, and most places we have moved to removing the +counts and just using the offsets. + +This change removes the `Count` array from the `Keys` object. Where the +count is needed internally, adjacent offsets are subtracted. The deprecated +`GetCounts` method is implemented by copying values into a new array. + +## Enable new instances of unknown arrays with dynamic sizes + +`UnknownArrayHandle` allows you to create a new instance of a compatible +array so that when receiving an array of unknown type, a place to put the +output can be created. However, these methods only worked if the number of +components in each value could be determined statically at compile time. + +However, there are some special `ArrayHandle`s that can define the number +of components at runtime. In this case, the `ArrayHandle` would throw an +exception if `NewInstanceBasic` or `NewInstanceFloatBasic` was called. + +Although rare, this condition could happen when, for example, an array was +extracted from an `UnknownArrayHandle` with `ExtractArrayFromComponents` or +with `CastAndCallWithExtractedArray` and then the resulting array was +passed to a function with arrays passed with `UnknownArrayHandle` such as +`ArrayCopy`. + + +# Filters and Worklets + +## Consolidate WarpScalar and WarpVector filter + +In reflection, the `WarpScalar` filter is surprisingly a superset of the +`WarpVector` features. `WarpScalar` has the ability to displace in the +directions of the mesh normals. In VTK, there is a distinction of normals +to vectors, but in VTK-m it is a matter of selecting the correct one. As +such, it makes little sense to have two separate implementations for the +same operation. The filters have been combined and the interface names have +been generalized for general warping (e.g., "normal" or "vector" becomes +"direction"). + +In addition to consolidating the implementation, the `Warp` filter +implementation has been updated to use the modern features of VTK-m's +filter base classes. In particular, when the `Warp` filters were originally +implemented, the filter base classes did not support more than one active +scalar field, so filters like `Warp` had to manage multiple fields +themselves. The `FilterField` base class now allows specifying multiple, +indexed active fields, and the updated implementation uses this to manage +the input vectors and scalars. + +The `Warp` filters have also been updated to directly support constant +vectors and scalars, which is common for `WarpScalar` and `WarpVector`, +respectively. Previously, to implement a constant field, you had to add a +field containing an `ArrayHandleConstant`. This is still supported, but an +easier method of just selecting constant vectors or scalars makes this +easier. + +Internally, the implementation now uses tricks with extracting array +components to support many different array types (including +`ArrayHandleConstant`. This allows it to simultaneously interact with +coordinates, directions, and scalars without creating too many template +instances. + +## Adding MergeDataSets filter + +The MergeDataSets filter can accept partitioned data sets and output a merged +data set. It assumes that all partitions have the same coordinate systems. If a +field is missing in a specific partition, the user-specified invalid value will +be adopted and filled into the corresponding places of the merged field array. + +## Fix bug with ExtractGeometry filter + +The `ExtractGeometry` filter was outputing datasets containing +`CellSetPermutation` as the representation for the cells. Although this is +technically correct and a very fast implementation, it is essentially +useless. The problem is that any downstream processing will have to know +that the data has a `CellSetPermutation`. None do (because the permutation +can be on any other cell set type, which creates an explosion of possible +cell types). + +Like was done with `Threshold` a while ago, this problem is fixed by deep +copying the result into a `CellSetExplicit`. This behavior is consistent +with VTK. + +## New Isosurface Uncertainty Visualization Analysis filter + +This new filter, designed for uncertainty analysis of the marching cubes +algorithm for isosurface visualization, computes three uncertainty metrics, +namely, level-crossing probability, topology case count, and entropy-based +uncertainty. This filter requires a 3D cell-structured dataset with ensemble +minimum and ensemble maximum values denoting uncertain data range at each grid +vertex. + +This uncertainty analysis filter analyzes the uncertainty in the marching cubes +topology cases. The output dataset consists of 3D point fields corresponding to +the level-crossing probability, topology case count, and entropy-based +uncertainty. + +This VTK-m implementation is based on the algorithm presented in the paper +"FunMC2: A Filter for Uncertainty Visualization of Marching Cubes on Multi-Core +Devices" by Wang, Z., Athawale, T. M., Moreland, K., Chen, J., Johnson, C. R., +& Pugmire, D. + +## Deprecated `vtkm::filter::FilterField` + +The original design of the filter base class required several specialized +base classes to control what information was pulled from the input +`DataSet` and provided to the derived class. Since the filter base class was +redesigned, the derived classes all get a `DataSet` and pull their own +information from it. Thus, most specialized filter base classes became +unnecessary and removed. + +The one substantial exception was the `FilterField`. This filter base class +managed input and output arrays. This was kept separate from the base +`Filter` because not all filters need the ability to select this +information. + +That said, this separation has not been particularly helpful. There are +several other features of `Filter` that does not apply to all subclasses. +Furthermore, there are several derived filters that are using `FilterField` +merely to pick a single part, like selecting a coordinate system, and +ignoring the rest of the abilities. + +Thus, it makes more sense to deprecate `FilterField` and have these classes +inherit directly from `Filter`. + +## Adding SliceMultiple filter + +The SliceMultiple filter can accept multiple implicit functions and output a +merged dataset. This filter is added to the filter/contour. The code of this +filter is adapted from vtk-h. The mechanism that merges multiple datasets in +this filter is supposed to support more general datasets and work a separate +filter in the future. + +## Constructors for mesh info classes updated to conform with other filters + +The `CellMeasures` and `MeshQuality` filters had constructors that took the +metric that the filter should generate. However, this is different than the +iterface of the rest of the filters. To make the interface more consistent, +these filters now have a default (no argument) constructor, and the metric +to compute is selected via a method. This makes it more clear what is being +done. + +In addition, the documentation for these two classes is updated. + +## Allow floating-point isovalues for contours of integer fields + +The flying edges version of the contouring filter converted the isovalues +provided into the same type as the field. This is fine for a floating point +field, but for an integer field the isovalue was truncated to the nearest +integer. + +This is problematic because it is common to provide a fractional isovalue +(usually N + 0.5) for integer fields to avoid degenerate cases of the +contour intersecting vertices. It also means the behavior changes between +an integer type that is directly supported (like a `signed char`) or an +integer type that is not directly supported and converted to a floating +point field (like potentially a `char`). + +This change updates the worklets to allow the isovalue to have a different +type than the field and to always use a floating point type for the +isovalue. + + +# Control Environment + + +# Execution Environment + +## AtomicArrayExecutionObject: Allow order of atomic operations + +AtomicArrayExecutionObject now allows order of atomic operations for Get/Set/Add/CompareExchange. + +## Disable Thrust patch that is no longer needed in modern Thrust + +There is a Thrust patch that works around an issue in Thrust 1.9.4 +(https://github.com/NVIDIA/thrust/issues/972). The underlying issue +should be fixed in recent versions. In recent versions of CUDA, the patch +breaks (https://gitlab.kitware.com/vtk/vtk-m/-/issues/818). + +This change fixes the problem by disabling the patch where it is not +needed. + +## Add hints to device adapter scheduler + +The `DeviceAdapter` provides an abstract interface to the accelerator +devices worklets and other algorithms run on. As such, the programmer has +less control about how the device launches each worklet. Each device +adapter has its own configuration parameters and other ways to attempt to +optimize how things are run, but these are always a universal set of +options that are applied to everything run on the device. There is no way +to specify launch parameters for a particular worklet. + +To provide this information, VTK-m now supports `Hint`s to the device +adapter. The `DeviceAdapterAlgorithm::Schedule` method takes a templated +argument that is of the type `HintList`. This object contains a template +list of `Hint` types that provide suggestions on how to launch the parallel +execution. The device adapter will pick out hints that pertain to it and +adjust its launching accordingly. + +These are called hints rather than, say, directives, because they don't +force the device adapter to do anything. The device adapter is free to +ignore any (and all) hints. The point is that the device adapter can take +into account the information to try to optimize for itself. + +A provided hint can be tied to specific device adapters. In this way, an +worklet can further optimize itself. If multiple hints match a device +adapter, the last one in the list will be selected. + +The `Worklet` base now has an internal type named `Hints` that points to a +`HintList` that is applied when the worklet is scheduled. Derived worklet +classes can provide hints by simply defining their own `Hints` type. + +This feature is experimental and consequently hidden in an `internal` +namespace. + +# Build + +## Support backward compatibility in CMake package + +VTK-m development is in a mode where backward compatibility should be +maintained between minor versions of the software. (You may get deprecation +warnings, but things should still work.) To match this behavior, the +generated CMake package now supports finding versions with the same major +release and the same or newer minor release. For example, if an external +program does this + +``` cmake +find_package(VTKm 2.1 REQUIRED) +``` + +then CMake will link to 2.1 (of course) as well as newer minor releases +(e.g., 2.2, 2.3, etc.). It will not, however, match older versions (e.g., +2.0, 1.9), nor will it match any version after the next major release +(e.g., 3.0). + +## Fix issue with union placeholder on Intel compiler + +We have run into an issue with some Intel compilers where if a `union` +contains a `struct` that has some padding for byte alignment, the value +copy might skip over that padding even when the `union` contains a different +type where those bytes are valid. This breaks the value copy of our +`Variant` class. + +This is not a unique problem. We have seen the same thing in other +compilers and already have a workaround for when this happens. The +workaround creates a special struct that has no padding placed at the front +of the `union`. The Intel compiler adds a fun twist in that this +placeholder structure only works if the alignment is at least as high as +the struct that follows it. + +To get around this problem, make the alignment of the placeholder `struct` +at large as possible for the size of the `union`. + +## Fix old cuda atomics + +There are some overloads for atomic adds of floating point numbers for +older versions of cuda that do not include them directly. These were +misnamed and thus not properly overloading the generic implementation. +This caused compile errors with older versions of cuda. + +## Fix crash when CUDA device is disabled + +There was an issue where if VTK-m was compiled with CUDA support but then +run on a computer where no CUDA device was available, an inappropriate +exception was thrown (instead of just disabling the device). The +initialization code should now properly check for the existance of a CUDA +device. + +# Others + +## Avoid floating point exceptions in rendering code + +There were some places in the rendering code where floating point +exceptions (FPE) could happen under certain circumstances. Often we do not +care about invalid floating point operation in rendering as they often +occur in degenerate cases that don't contribute anyway. However, +simulations that might include VTK-m might turn on FPE to check their own +operations. In such cases, we don't want errant rendering arithmetic +causing an exception and bringing down the whole code. Thus, we turn on FPE +in some of our test platforms and avoid such operations in general. + +## Added VTK-m's user guide into the source code + +The VTK-m User's Guide is being transitioned into the VTK-m source code. +The implementation of the guide is being converted from LaTeX to +ReStructuredText text to be built by Sphinx. There are several goals of +this change. + +1. Integrate the documentation into the source code better to better + keep the code up to date. +2. Move the documentation over to Sphinx so that it can be posted online + and be more easily linked. +3. Incoporate Doxygen into the guide to keep the documentation + consistent. +4. Build the user guide examples as part of the VTK-m CI to catch + compatibility changes quickly. diff --git a/docs/changelog/AtomicArrayExecutionObject_Allow_order_of_atomic_operations.md b/docs/changelog/AtomicArrayExecutionObject_Allow_order_of_atomic_operations.md deleted file mode 100644 index f4654f5ea..000000000 --- a/docs/changelog/AtomicArrayExecutionObject_Allow_order_of_atomic_operations.md +++ /dev/null @@ -1,3 +0,0 @@ -# AtomicArrayExecutionObject: Allow order of atomic operations - -AtomicArrayExecutionObject now allows order of atomic operations for Get/Set/Add/CompareExchange. diff --git a/docs/changelog/add-merge-datasets-filter.md b/docs/changelog/add-merge-datasets-filter.md deleted file mode 100644 index edc317cd6..000000000 --- a/docs/changelog/add-merge-datasets-filter.md +++ /dev/null @@ -1,3 +0,0 @@ -# Adding MergeDataSets filter - -The MergeDataSets filter can accept partitioned data sets and output a merged data set. It assumes that all partitions have the same coordinate systems. If a field is missing in a specific partition, the user-specified invalid value will be adopted and filled into the corresponding places of the merged field array. diff --git a/docs/changelog/add-slice-multiple-filter.md b/docs/changelog/add-slice-multiple-filter.md deleted file mode 100644 index d11dab22e..000000000 --- a/docs/changelog/add-slice-multiple-filter.md +++ /dev/null @@ -1,3 +0,0 @@ -# Adding SliceMultiple filter - -The SliceMultiple filter can accept multiple implicit functions and output a merged dataset. This filter is added to the filter/contour. The code of this filter is adapted from vtk-h. The mechanism that merges multiple datasets in this filter is supposed to support more general datasets and work a separate filter in the future. diff --git a/docs/changelog/allow-backward-compatibility.md b/docs/changelog/allow-backward-compatibility.md deleted file mode 100644 index 92a180278..000000000 --- a/docs/changelog/allow-backward-compatibility.md +++ /dev/null @@ -1,17 +0,0 @@ -# Support backward compatibility in CMake package - -VTK-m development is in a mode where backward compatibility should be -maintained between minor versions of the software. (You may get deprecation -warnings, but things should still work.) To match this behavior, the -generated CMake package now supports finding versions with the same major -release and the same or newer minor release. For example, if an external -program does this - -``` cmake -find_package(VTKm 2.1 REQUIRED) -``` - -then CMake will link to 2.1 (of course) as well as newer minor releases -(e.g., 2.2, 2.3, etc.). It will not, however, match older versions (e.g., -2.0, 1.9), nor will it match any version after the next major release -(e.g., 3.0). diff --git a/docs/changelog/arrayhandle-getcomponents.md b/docs/changelog/arrayhandle-getcomponents.md deleted file mode 100644 index f452f5851..000000000 --- a/docs/changelog/arrayhandle-getcomponents.md +++ /dev/null @@ -1,20 +0,0 @@ -# Add `GetNumberOfComponentsFlat` method to `ArrayHandle` - -Getting the number of components (or the number of flattened components) -from an `ArrayHandle` is usually trivial. However, if the `ArrayHandle` is -special in that the number of components is specified at runtime, then it -becomes much more difficult to determine. - -Getting the number of components is most important when extracting -component arrays (or reconstructions using component arrays) with -`UnknownArrayHandle`. Previously, `UnknownArrayHandle` used a hack to get -the number of components, which mostly worked but broke down when wrapping -a runtime array inside another array such as `ArrayHandleView`. - -To prevent this issue, the ability to get the number of components has been -added to `ArrayHandle` proper. All `Storage` objects for `ArrayHandle`s now -need a method named `GetNumberOfComponentsFlat`. The implementation of this -method is usually trivial. The `ArrayHandle` template now also provides a -`GetNumberOfComponentsFlat` method that gets this information from the -`Storage`. This provides an easy access point for the `UnknownArrayHandle` -to pull this information. diff --git a/docs/changelog/arrayhandleconstant-extract-component.md b/docs/changelog/arrayhandleconstant-extract-component.md deleted file mode 100644 index 2d40ed30b..000000000 --- a/docs/changelog/arrayhandleconstant-extract-component.md +++ /dev/null @@ -1,9 +0,0 @@ -# Added support for component extraction from ArrayHandleConstant better - -Previously, `ArrayHandleConstant` did not really support component -extraction. Instead, it let a fallback operation create a full array on -the CPU. - -Component extraction is now quite efficient for `ArrayHandleConstant`. It -creates a basic `ArrayHandle` with one entry and sets a modulo on the -`ArrayHandleStride` to access that value for all indices. diff --git a/docs/changelog/avoid-rendering-fpe.md b/docs/changelog/avoid-rendering-fpe.md deleted file mode 100644 index 1cfa5e7d2..000000000 --- a/docs/changelog/avoid-rendering-fpe.md +++ /dev/null @@ -1,10 +0,0 @@ -# Avoid floating point exceptions in rendering code - -There were some places in the rendering code where floating point -exceptions (FPE) could happen under certain circumstances. Often we do not -care about invalid floating point operation in rendering as they often -occur in degenerate cases that don't contribute anyway. However, -simulations that might include VTK-m might turn on FPE to check their own -operations. In such cases, we don't want errant rendering arithmetic -causing an exception and bringing down the whole code. Thus, we turn on FPE -in some of our test platforms and avoid such operations in general. diff --git a/docs/changelog/constant-amr-arrays.md b/docs/changelog/constant-amr-arrays.md deleted file mode 100644 index c2afda9df..000000000 --- a/docs/changelog/constant-amr-arrays.md +++ /dev/null @@ -1,8 +0,0 @@ -# Store constant AMR arrays with less memory - -The `AmrArrays` filter generates some cell fields that specify information -about the hierarchy, which are constant across all cells in a partition. -These were previously stored as an array with the same value throughout. -Now, the field is stored as an `ArrayHandleConstant`, which does not -require any real storage. Recent changes to VTK-m allow code to extract the -array as a component efficiently without knowing the storage type. diff --git a/docs/changelog/contour-int-isovalue.md b/docs/changelog/contour-int-isovalue.md deleted file mode 100644 index 9d6b045f2..000000000 --- a/docs/changelog/contour-int-isovalue.md +++ /dev/null @@ -1,17 +0,0 @@ -# Allow floating-point isovalues for contours of integer fields - -The flying edges version of the contouring filter converted the isovalues -provided into the same type as the field. This is fine for a floating point -field, but for an integer field the isovalue was truncated to the nearest -integer. - -This is problematic because it is common to provide a fractional isovalue -(usually N + 0.5) for integer fields to avoid degenerate cases of the -contour intersecting vertices. It also means the behavior changes between -an integer type that is directly supported (like a `signed char`) or an -integer type that is not directly supported and converted to a floating -point field (like potentially a `char`). - -This change updates the worklets to allow the isovalue to have a different -type than the field and to always use a floating point type for the -isovalue. diff --git a/docs/changelog/deprecate-filter-field.md b/docs/changelog/deprecate-filter-field.md deleted file mode 100644 index aa87c08e9..000000000 --- a/docs/changelog/deprecate-filter-field.md +++ /dev/null @@ -1,22 +0,0 @@ -# Deprecated `vtkm::filter::FilterField` - -The original design of the filter base class required several specialized -base classes to control what information was pulled from the input -`DataSet` and provided to the derived class. Since the filter base class was -redesigned, the derived classes all get a `DataSet` and pull their own -information from it. Thus, most specialized filter base classes became -unnecessary and removed. - -The one substantial exception was the `FilterField`. This filter base class -managed input and output arrays. This was kept separate from the base -`Filter` because not all filters need the ability to select this -information. - -That said, this separation has not been particularly helpful. There are -several other features of `Filter` that does not apply to all subclasses. -Furthermore, there are several derived filters that are using `FilterField` -merely to pick a single part, like selecting a coordinate system, and -ignoring the rest of the abilities. - -Thus, it makes more sense to deprecate `FilterField` and have these classes -inherit directly from `Filter`. diff --git a/docs/changelog/deprecate-reduce-by-key-count.md b/docs/changelog/deprecate-reduce-by-key-count.md deleted file mode 100644 index c5f15a84f..000000000 --- a/docs/changelog/deprecate-reduce-by-key-count.md +++ /dev/null @@ -1,12 +0,0 @@ -# Deprecate the GetCounts() method in Keys objects - -The `vtkm::worklet::Keys` object held a `SortedValuesMap` array, an -`Offsets` array, a `Counts` array, and (optionally) a `UniqueKeys` array. -Of these, the `Counts` array is redundant because the counts are trivially -computed by subtracting adjacent entries in the offsets array. This pattern -shows up a lot in VTK-m, and most places we have moved to removing the -counts and just using the offsets. - -This change removes the `Count` array from the `Keys` object. Where the -count is needed internally, adjacent offsets are subtracted. The deprecated -`GetCounts` method is implemented by copying values into a new array. diff --git a/docs/changelog/extract-geometry-permutation.md b/docs/changelog/extract-geometry-permutation.md deleted file mode 100644 index 8a90495f7..000000000 --- a/docs/changelog/extract-geometry-permutation.md +++ /dev/null @@ -1,13 +0,0 @@ -# Fix bug with ExtractGeometry filter - -The `ExtractGeometry` filter was outputing datasets containing -`CellSetPermutation` as the representation for the cells. Although this is -technically correct and a very fast implementation, it is essentially -useless. The problem is that any downstream processing will have to know -that the data has a `CellSetPermutation`. None do (because the permutation -can be on any other cell set type, which creates an explosion of possible -cell types). - -Like was done with `Threshold` a while ago, this problem is fixed by deep -copying the result into a `CellSetExplicit`. This behavior is consistent -with VTK. diff --git a/docs/changelog/fill-stride-arrays.md b/docs/changelog/fill-stride-arrays.md deleted file mode 100644 index 7fa55ce61..000000000 --- a/docs/changelog/fill-stride-arrays.md +++ /dev/null @@ -1,22 +0,0 @@ -# Support `Fill` for `ArrayHandleStride` - -Previously, if you called `Fill` on an `ArrayHandleStride`, you would get -an exception that said the feature was not supported. It turns out that -filling values is very useful in situations where, for example, you need to -initialize an array when processing an unknown type (and thus dealing with -extracted components). - -This implementation of `Fill` first attempts to call `Fill` on the -contained array. This only works if the stride is set to 1. If this does -not work, then the code leverages the precompiled `ArrayCopy`. It does this -by first creating a new `ArrayHandleStride` containing the fill value and a -modulo of 1 so that value is constantly repeated. It then reconstructs an -`ArrayHandleStride` for itself with a modified size and offset to match the -start and end indices. - -Referencing the `ArrayCopy` was tricky because it kept creating circular -dependencies among `ArrayHandleStride`, `ArrayExtractComponent`, and -`UnknownArrayHandle`. These dependencies were broken by having -`ArrayHandleStride` directly use the internal `ArrayCopyUnknown` function -and to use a forward declaration of `UnknownArrayHandle` rather than -including its header. diff --git a/docs/changelog/fix-old-cuda-atomics.md b/docs/changelog/fix-old-cuda-atomics.md deleted file mode 100644 index 87ca20bd4..000000000 --- a/docs/changelog/fix-old-cuda-atomics.md +++ /dev/null @@ -1,6 +0,0 @@ -# Fix old cuda atomics - -There are some overloads for atomic adds of floating point numbers for -older versions of cuda that do not include them directly. These were -misnamed and thus not properly overloading the generic implementation. -This caused compile errors with older versions of cuda. diff --git a/docs/changelog/hints.md b/docs/changelog/hints.md deleted file mode 100644 index 10f9bf47a..000000000 --- a/docs/changelog/hints.md +++ /dev/null @@ -1,32 +0,0 @@ -# Add hints to device adapter scheduler - -The `DeviceAdapter` provides an abstract interface to the accelerator -devices worklets and other algorithms run on. As such, the programmer has -less control about how the device launches each worklet. Each device -adapter has its own configuration parameters and other ways to attempt to -optimize how things are run, but these are always a universal set of -options that are applied to everything run on the device. There is no way -to specify launch parameters for a particular worklet. - -To provide this information, VTK-m now supports `Hint`s to the device -adapter. The `DeviceAdapterAlgorithm::Schedule` method takes a templated -argument that is of the type `HintList`. This object contains a template -list of `Hint` types that provide suggestions on how to launch the parallel -execution. The device adapter will pick out hints that pertain to it and -adjust its launching accordingly. - -These are called hints rather than, say, directives, because they don't -force the device adapter to do anything. The device adapter is free to -ignore any (and all) hints. The point is that the device adapter can take -into account the information to try to optimize for itself. - -A provided hint can be tied to specific device adapters. In this way, an -worklet can further optimize itself. If multiple hints match a device -adapter, the last one in the list will be selected. - -The `Worklet` base now has an internal type named `Hints` that points to a -`HintList` that is applied when the worklet is scheduled. Derived worklet -classes can provide hints by simply defining their own `Hints` type. - -This feature is experimental and consequently hidden in an `internal` -namespace. diff --git a/docs/changelog/intel-finites.md b/docs/changelog/intel-finites.md deleted file mode 100644 index 0b2128839..000000000 --- a/docs/changelog/intel-finites.md +++ /dev/null @@ -1,6 +0,0 @@ -# Enable non-finite values with Intel compiler - -The Intel compiler by default turns on an optimization that assumes that -all floating point values are finite. This breaks any ligitimate uses of -non-finite values including checking values with functions like `isnan` -and `isinf`. Turn off this feature for the intel compiler. diff --git a/docs/changelog/intel-union-placeholder.md b/docs/changelog/intel-union-placeholder.md deleted file mode 100644 index 0c76ee49d..000000000 --- a/docs/changelog/intel-union-placeholder.md +++ /dev/null @@ -1,17 +0,0 @@ -# Fix issue with union placeholder on Intel compiler - -We have run into an issue with some Intel compilers where if a `union` -contains a `struct` that has some padding for byte alignment, the value -copy might skip over that padding even when the `union` contains a different -type where those bytes are valid. This breaks the value copy of our -`Variant` class. - -This is not a unique problem. We have seen the same thing in other -compilers and already have a workaround for when this happens. The -workaround creates a special struct that has no padding placed at the front -of the `union`. The Intel compiler adds a fun twist in that this -placeholder structure only works if the alignment is at least as high as -the struct that follows it. - -To get around this problem, make the alignment of the placeholder `struct` -at large as possible for the size of the `union`. diff --git a/docs/changelog/isosurface-uncertainty.md b/docs/changelog/isosurface-uncertainty.md deleted file mode 100644 index 403bb8d4c..000000000 --- a/docs/changelog/isosurface-uncertainty.md +++ /dev/null @@ -1,7 +0,0 @@ -# New Isosurface Uncertainty Visualization Analysis filter - -This new filter, designed for uncertainty analysis of the marching cubes algorithm for isosurface visualization, computes three uncertainty metrics, namely, level-crossing probability, topology case count, and entropy-based uncertainty. This filter requires a 3D cell-structured dataset with ensemble minimum and ensemble maximum values denoting uncertain data range at each grid vertex. - -This uncertainty analysis filter analyzes the uncertainty in the marching cubes topology cases. The output dataset consists of 3D point fields corresponding to the level-crossing probability, topology case count, and entropy-based uncertainty. - -This VTK-m implementation is based on the algorithm presented in the paper "FunMC2: A Filter for Uncertainty Visualization of Marching Cubes on Multi-Core Devices" by Wang, Z., Athawale, T. M., Moreland, K., Chen, J., Johnson, C. R., & Pugmire, D. diff --git a/docs/changelog/mesh-info-constructors.md b/docs/changelog/mesh-info-constructors.md deleted file mode 100644 index 0859bf3ed..000000000 --- a/docs/changelog/mesh-info-constructors.md +++ /dev/null @@ -1,10 +0,0 @@ -# Constructors for mesh info classes updated to conform with other filters - -The `CellMeasures` and `MeshQuality` filters had constructors that took the -metric that the filter should generate. However, this is different than the -iterface of the rest of the filters. To make the interface more consistent, -these filters now have a default (no argument) constructor, and the metric -to compute is selected via a method. This makes it more clear what is being -done. - -In addition, the documentation for these two classes is updated. diff --git a/docs/changelog/new-instance-variable-components.md b/docs/changelog/new-instance-variable-components.md deleted file mode 100644 index 90c43fd75..000000000 --- a/docs/changelog/new-instance-variable-components.md +++ /dev/null @@ -1,16 +0,0 @@ -# Enable new instances of unknown arrays with dynamic sizes - -`UnknownArrayHandle` allows you to create a new instance of a compatible -array so that when receiving an array of unknown type, a place to put the -output can be created. However, these methods only worked if the number of -components in each value could be determined statically at compile time. - -However, there are some special `ArrayHandle`s that can define the number -of components at runtime. In this case, the `ArrayHandle` would throw an -exception if `NewInstanceBasic` or `NewInstanceFloatBasic` was called. - -Although rare, this condition could happen when, for example, an array was -extracted from an `UnknownArrayHandle` with `ExtractArrayFromComponents` or -with `CastAndCallWithExtractedArray` and then the resulting array was -passed to a function with arrays passed with `UnknownArrayHandle` such as -`ArrayCopy`. diff --git a/docs/changelog/obsolete-thrust-patch.md b/docs/changelog/obsolete-thrust-patch.md deleted file mode 100644 index e97b4b4be..000000000 --- a/docs/changelog/obsolete-thrust-patch.md +++ /dev/null @@ -1,9 +0,0 @@ -# Disable Thrust patch that is no longer needed in modern Thrust - -There is a Thrust patch that works around an issue in Thrust 1.9.4 -(https://github.com/NVIDIA/thrust/issues/972). The underlying issue -should be fixed in recent versions. In recent versions of CUDA, the patch -breaks (https://gitlab.kitware.com/vtk/vtk-m/-/issues/818). - -This change fixes the problem by disabling the patch where it is not -needed. diff --git a/docs/changelog/safe-cuda-runtime-config.md b/docs/changelog/safe-cuda-runtime-config.md deleted file mode 100644 index a9a0880cc..000000000 --- a/docs/changelog/safe-cuda-runtime-config.md +++ /dev/null @@ -1,7 +0,0 @@ -# Fix crash when CUDA device is disabled - -There was an issue where if VTK-m was compiled with CUDA support but then -run on a computer where no CUDA device was available, an inappropriate -exception was thrown (instead of just disabling the device). The -initialization code should now properly check for the existance of a CUDA -device. diff --git a/docs/changelog/update-warps.md b/docs/changelog/update-warps.md deleted file mode 100644 index b1e911720..000000000 --- a/docs/changelog/update-warps.md +++ /dev/null @@ -1,32 +0,0 @@ -# Consolidate WarpScalar and WarpVector filter - -In reflection, the `WarpScalar` filter is surprisingly a superset of the -`WarpVector` features. `WarpScalar` has the ability to displace in the -directions of the mesh normals. In VTK, there is a distinction of normals -to vectors, but in VTK-m it is a matter of selecting the correct one. As -such, it makes little sense to have two separate implementations for the -same operation. The filters have been combined and the interface names have -been generalized for general warping (e.g., "normal" or "vector" becomes -"direction"). - -In addition to consolidating the implementation, the `Warp` filter -implementation has been updated to use the modern features of VTK-m's -filter base classes. In particular, when the `Warp` filters were originally -implemented, the filter base classes did not support more than one active -scalar field, so filters like `Warp` had to manage multiple fields -themselves. The `FilterField` base class now allows specifying multiple, -indexed active fields, and the updated implementation uses this to manage -the input vectors and scalars. - -The `Warp` filters have also been updated to directly support constant -vectors and scalars, which is common for `WarpScalar` and `WarpVector`, -respectively. Previously, to implement a constant field, you had to add a -field containing an `ArrayHandleConstant`. This is still supported, but an -easier method of just selecting constant vectors or scalars makes this -easier. - -Internally, the implementation now uses tricks with extracting array -components to support many different array types (including -`ArrayHandleConstant`. This allows it to simultaneously interact with -coordinates, directions, and scalars without creating too many template -instances. diff --git a/docs/changelog/users-guide.md b/docs/changelog/users-guide.md deleted file mode 100644 index d7b2fdbc2..000000000 --- a/docs/changelog/users-guide.md +++ /dev/null @@ -1,15 +0,0 @@ -# Added VTK-m's user guide into the source code - -The VTK-m User's Guide is being transitioned into the VTK-m source code. -The implementation of the guide is being converted from LaTeX to -ReStructuredText text to be built by Sphinx. There are several goals of -this change. - -1. Integrate the documentation into the source code better to better - keep the code up to date. -2. Move the documentation over to Sphinx so that it can be posted online - and be more easily linked. -3. Incoporate Doxygen into the guide to keep the documentation - consistent. -4. Build the user guide examples as part of the VTK-m CI to catch - compatibility changes quickly. diff --git a/docs/changelog/vecfromportal-operators.md b/docs/changelog/vecfromportal-operators.md deleted file mode 100644 index 747c34222..000000000 --- a/docs/changelog/vecfromportal-operators.md +++ /dev/null @@ -1,8 +0,0 @@ -# Improved = operators in VecFromPortal - -Previously, `VecFromPortal` could only be set to a standard `Vec`. -However, because this is a `Vec`-like object with a runtime-size, it is -hard to do general arithmetic on it. It is easier to do in place so -there is some place to put the result. To make it easier to operate on -this as the result of other `Vec`-likes, extend the operators like `+=`, -`*=`, etc to support this.