diff --git a/LICENSE.txt b/LICENSE.txt index 4c47c9c77..58561b095 100644 --- a/LICENSE.txt +++ b/LICENSE.txt @@ -1,7 +1,7 @@ VTKm License Version 2.0 ======================================================================== -Copyright (c) 2014-2022 +Copyright (c) 2014-2023 Kitware Inc., National Technology & Engineering Solutions of Sandia, LLC (NTESS), UT-Battelle, LLC., diff --git a/docs/changelog/2.0/release-notes.md b/docs/changelog/2.0/release-notes.md index 2b74e09ec..0eeeae37c 100644 --- a/docs/changelog/2.0/release-notes.md +++ b/docs/changelog/2.0/release-notes.md @@ -21,10 +21,13 @@ VTK-m 2.0 Release Notes - Attach compressed ZFP data as WholeDataSet field 4. [Execution Environment](#Execution-Environment) - Removed ExecutionWholeArray class + - Add initial support for aborting execution 5. [Worklets and Filters](#Worklets-and-Filters) - Correct particle density filter output field - Rename NewFilter base classes to Filter - Fix handling of cell fields in Tube filter + - Fix setting fields to pass in Filter when setting mode + - Respect Filter::PassCoordinateSystem flag in filters creating coordinate systems. 6. [Build](#Build) - More performance test options - Output complete list of libraries for external Makefiles @@ -32,6 +35,7 @@ VTK-m 2.0 Release Notes 7. [Other](#Other) - Expose the Variant helper class - Fix VTKM_LOG_SCOPE + - Clarify field index ordering in Doxygen # Core @@ -240,6 +244,29 @@ that `ExecutionWholeArray` had was that it provided an subscript operator (somewhat incorrectly). Thus, any use of '[..]' to index the array portal have to be changed to use the `Get` method. +## Add initial support for aborting execution + +VTK-m now has preliminary support for aborting execution. The per-thread instances of +`RuntimeDeviceTracker` have a functor called `AbortChecker`. This functor can be set using +`RuntimeDeviceTracker::SetAbortChecker()` and cleared by `RuntimeDeviceTracker::ClearAbortChecker()` +The abort checker functor should return `true` if an abort is requested for the thread, +otherwise, it should return `false`. + +Before launching a new task, `TaskExecute` calls the functor to see if an abort is requested, +and If so, throws an exception of type `vtkm::cont::ErrorUserAbort`. + +Any code that wants to use the abort feature, should set an appropriate `AbortChecker` +functor for the target thread. Then any piece of code that has parts that can execute on +the device should be put under a `try-catch` block. Any clean-up that is required for an +aborted execution should be handled in a `catch` block that handles exceptions of type +`vtkm::cont::ErrorUserAbort`. + +The limitation of this implementation is that it is control-side only. The check for abort +is done before launching a new device task. Once execution has begun on the device, there is +currently no way to abort that. Therefore, this feature is only useful for aborting code +that is made up of several smaller device task launches (Which is the case for most +worklets and filters in VTK-m) + # Worklets and Filters ## Correct particle density filter output field @@ -282,6 +309,43 @@ would also get around some problems with the implementation that was removed here when mixing polylines with other cell types and degenerate lines.) +## Fix setting fields to pass in `Filter` when setting mode + +The `Filter` class has several version of the `SetFieldsToPass` method that +works in conjunction with the `FieldSelection` object to specify which +fields are mapped. For example, the user might have code like this to pass +all fields except those named `pointvar` and `cellvar`: + +``` cpp + filter.SetFieldsToPass({ "pointvar", "cellvar" }, + vtkm::filter::FieldSelection::Mode::Exclude); +``` + +This previously worked by implicitly creating a `FieldSelection` object +using the `std::initializer_list` filled with the 2 strings. This would +then be passed to the `SetFieldsToPass` method, which would capture the +`FieldSelection` object and change the mode. + +This stopped working in a recent change to `FieldSelection` where each +entry is given its own mode. With this new class, the `FieldSelection` +constructor would capture each field in the default mode (`Select`) and +then change the default mode to `Exclude`. However, the already set modes +kept their `Select` status, which is not what is intended. + +This behavior is fixed by adding `SetFieldToPass` overloads that capture +both the `initializer_list` and the `Mode` and then constructs the +`FieldSelection` correctly. + +## Respect `Filter::PassCoordinateSystem` flag in filters creating coordinate systems + +The `Filter` class has a `PassCoordinateSystem` flag that specifies whether +coordinate systems should be passed regardless of whether the associated +field is passed. However, if a filter created its output with the +`CreateResultCoordinateSystem` method this flag was ignored, and the +provided coordinate system was always passed. This might not be what the +user intended, so this method has been fixed to first check the +`PassCoordinateSystem` flag before setting the coordinates on the output. + # Build ## More performance test options @@ -375,3 +439,14 @@ This was not what was happening. The second log message was being printed immediately after the first. This is because the scope was taken inside of the `LogScope` method. The macro has been rewritten to put the tracking in the right scope. + +## Clarify field index ordering in Doxygen + +The fields in a `DataSet` are indexed from `0` to `GetNumberOfFields() - 1`. +It is natural to assume that the fields will be indexed in the order that +they are added, but they are not. Rather, the indexing is arbitrary and can +change any time a field is added to the dataset. + +To make this more clear, Doxygen documentation is added to the `DataSet` +methods to inform users to not make any assumptions about the order of +field indexing. diff --git a/docs/changelog/document-field-index-order.md b/docs/changelog/document-field-index-order.md deleted file mode 100644 index 53b00d318..000000000 --- a/docs/changelog/document-field-index-order.md +++ /dev/null @@ -1,10 +0,0 @@ -# Clarify field index ordering in Doxygen - -The fields in a `DataSet` are indexed from `0` to `GetNumberOfFields() - 1`. -It is natural to assume that the fields will be indexed in the order that -they are added, but they are not. Rather, the indexing is arbitrary and can -change any time a field is added to the dataset. - -To make this more clear, Doxygen documentation is added to the `DataSet` -methods to inform users to not make any assumptions about the order of -field indexing. diff --git a/docs/changelog/fix-filter-pass-fields.md b/docs/changelog/fix-filter-pass-fields.md deleted file mode 100644 index 5854a1fe4..000000000 --- a/docs/changelog/fix-filter-pass-fields.md +++ /dev/null @@ -1,26 +0,0 @@ -# Fix setting fields to pass in `Filter` when setting mode - -The `Filter` class has several version of the `SetFieldsToPass` method that -works in conjunction with the `FieldSelection` object to specify which -fields are mapped. For example, the user might have code like this to pass -all fields except those named `pointvar` and `cellvar`: - -``` cpp - filter.SetFieldsToPass({ "pointvar", "cellvar" }, - vtkm::filter::FieldSelection::Mode::Exclude); -``` - -This previously worked by implicitly creating a `FieldSelection` object -using the `std::initializer_list` filled with the 2 strings. This would -then be passed to the `SetFieldsToPass` method, which would capture the -`FieldSelection` object and change the mode. - -This stopped working in a recent change to `FieldSelection` where each -entry is given its own mode. With this new class, the `FieldSelection` -constructor would capture each field in the default mode (`Select`) and -then change the default mode to `Exclude`. However, the already set modes -kept their `Select` status, which is not what is intended. - -This behavior is fixed by adding `SetFieldToPass` overloads that capture -both the `initializer_list` and the `Mode` and then constructs the -`FieldSelection` correctly. diff --git a/docs/changelog/fix-pass-coords.md b/docs/changelog/fix-pass-coords.md deleted file mode 100644 index a95a04da8..000000000 --- a/docs/changelog/fix-pass-coords.md +++ /dev/null @@ -1,9 +0,0 @@ -# Respect `Filter::PassCoordinateSystem` flag in filters creating coordinate systems - -The `Filter` class has a `PassCoordinateSystem` flag that specifies whether -coordinate systems should be passed regardless of whether the associated -field is passed. However, if a filter created its output with the -`CreateResultCoordinateSystem` method this flag was ignored, and the -provided coordinate system was always passed. This might not be what the -user intended, so this method has been fixed to first check the -`PassCoordinateSystem` flag before setting the coordinates on the output. diff --git a/docs/changelog/vtkm-abort.md b/docs/changelog/vtkm-abort.md deleted file mode 100644 index 8bd25c7d0..000000000 --- a/docs/changelog/vtkm-abort.md +++ /dev/null @@ -1,22 +0,0 @@ -# Add initial support for aborting execution - -VTK-m now has preliminary support for aborting execution. The per-thread instances of -`RuntimeDeviceTracker` have a functor called `AbortChecker`. This functor can be set using -`RuntimeDeviceTracker::SetAbortChecker()` and cleared by `RuntimeDeviceTracker::ClearAbortChecker()` -The abort checker functor should return `true` if an abort is requested for the thread, -otherwise, it should return `false`. - -Before launching a new task, `TaskExecute` calls the functor to see if an abort is requested, -and If so, throws an exception of type `vtkm::cont::ErrorUserAbort`. - -Any code that wants to use the abort feature, should set an appropriate `AbortChecker` -functor for the target thread. Then any piece of code that has parts that can execute on -the device should be put under a `try-catch` block. Any clean-up that is required for an -aborted execution should be handled in a `catch` block that handles exceptions of type -`vtkm::cont::ErrorUserAbort`. - -The limitation of this implementation is that it is control-side only. The check for abort -is done before launching a new device task. Once execution has begun on the device, there is -currently no way to abort that. Therefore, this feature is only useful for aborting code -that is made up of several smaller device task launches (Which is the case for most -worklets and filters in VTK-m)