From 918de30163ebf190c2ee882c48888d71ecc2ed0c Mon Sep 17 00:00:00 2001 From: Vicente Adolfo Bolea Sanchez Date: Thu, 15 Dec 2022 18:12:41 -0500 Subject: [PATCH] release: 2.0.0-rc1 release notes --- docs/changelog/2.0/release-notes.md | 377 ++++++++++++++++++ docs/changelog/benchmark-options.md | 9 - docs/changelog/build-modules.md | 16 - docs/changelog/cont-portal-token.md | 21 - docs/changelog/coords-are-fields.md | 29 -- docs/changelog/delete-deprecated.md | 7 - docs/changelog/expose-variant.md | 12 - docs/changelog/external-lib-lists.md | 11 - docs/changelog/field-length-checking.md | 12 - docs/changelog/fix-log-scope.md | 11 - docs/changelog/ghost-cell-api.md | 5 - docs/changelog/ghost-cell-global-name.md | 7 - docs/changelog/hide-particle-members.md | 11 - .../include-and-exclude-field-selection.md | 21 - docs/changelog/no-execution-whole-array.md | 18 - .../particle-density-output-field.md | 7 - docs/changelog/partitioned-cell-locator.md | 14 - .../read-permuted-global-cell-ids.md | 8 - docs/changelog/remove-deprecated.md | 8 - docs/changelog/rename-filter-base.md | 11 - docs/changelog/source-parameters.md | 8 - docs/changelog/tube-cell-fields.md | 19 - .../vtkm-cmake-targets-namespaces.md | 42 -- docs/changelog/zfp-output-fields.md | 8 - 24 files changed, 377 insertions(+), 315 deletions(-) create mode 100644 docs/changelog/2.0/release-notes.md delete mode 100644 docs/changelog/benchmark-options.md delete mode 100644 docs/changelog/build-modules.md delete mode 100644 docs/changelog/cont-portal-token.md delete mode 100644 docs/changelog/coords-are-fields.md delete mode 100644 docs/changelog/delete-deprecated.md delete mode 100644 docs/changelog/expose-variant.md delete mode 100644 docs/changelog/external-lib-lists.md delete mode 100644 docs/changelog/field-length-checking.md delete mode 100644 docs/changelog/fix-log-scope.md delete mode 100644 docs/changelog/ghost-cell-api.md delete mode 100644 docs/changelog/ghost-cell-global-name.md delete mode 100644 docs/changelog/hide-particle-members.md delete mode 100644 docs/changelog/include-and-exclude-field-selection.md delete mode 100644 docs/changelog/no-execution-whole-array.md delete mode 100644 docs/changelog/particle-density-output-field.md delete mode 100644 docs/changelog/partitioned-cell-locator.md delete mode 100644 docs/changelog/read-permuted-global-cell-ids.md delete mode 100644 docs/changelog/remove-deprecated.md delete mode 100644 docs/changelog/rename-filter-base.md delete mode 100644 docs/changelog/source-parameters.md delete mode 100644 docs/changelog/tube-cell-fields.md delete mode 100644 docs/changelog/vtkm-cmake-targets-namespaces.md delete mode 100644 docs/changelog/zfp-output-fields.md diff --git a/docs/changelog/2.0/release-notes.md b/docs/changelog/2.0/release-notes.md new file mode 100644 index 000000000..2b74e09ec --- /dev/null +++ b/docs/changelog/2.0/release-notes.md @@ -0,0 +1,377 @@ +VTK-m 2.0 Release Notes +======================= + +# Table of Contents + +1. [Core](#Core) + - Added modules to the build system + - Remove deprecated features from VTK-m +2. [ArrayHandle](#ArrayHandle) + - Support providing a Token to ReadPortal and WritePortal +3. [Control Environment](#Control-Environment) + - Coordinate systems are stored as Fields + - Check to make sure that the fields in a DataSet are the proper length + - Change name of method to set the cell ghost levels in a DataSet + - Automatically make the fields with the global cell ghosts the cell ghosts + - Particle class members are hidden + - Allow FieldSelection to simultaneously include and exclude fields + - New partitioned cell locator class + - Fix reading global ids of permuted cells + - Setting source parameters is more clear + - Attach compressed ZFP data as WholeDataSet field +4. [Execution Environment](#Execution-Environment) + - Removed ExecutionWholeArray class +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 +6. [Build](#Build) + - More performance test options + - Output complete list of libraries for external Makefiles + - VTK-m namespace for its exported CMake targets +7. [Other](#Other) + - Expose the Variant helper class + - Fix VTKM_LOG_SCOPE + +# Core + +## Added modules to the build system + +VTK-m libraries and other targets can now be built as modules. The +advantage of modules is that you can selectively choose which +modules/libraries will be built. This makes it easy to create a more +stripped down compile of VTK-m. For example, you might want a reduced set +of libraries to save memory or you might want to turn off certain libraries +to save compile time. + +The module system will automatically determine dependencies among the +modules. It is capable of weakly turning off a module where it will still +be compiled if needed. Likewise, it is capable of weakly turning on a +module where the build will still work if it cannot be created. + +The use of modules is described in the `Modules.md` file in the `docs` +directory of the VTK-m source. + +## Remove deprecated features from VTK-m + +With the major revision 2.0 of VTK-m, many items previously marked as +deprecated were removed. If updating to a new version of VTK-m, it is +recommended to first update to VTK-m 1.9, which will include the deprecated +features but provide warnings (with the right compiler) that will point to +the replacement code. Once the deprecations have been fixed, updating to +2.0 should be smoother. + +# ArrayHandle + +## Support providing a Token to ReadPortal and WritePortal + +When managing portals in the execution environment, `ArrayHandle` uses the +`Token` object to ensure that the memory associated with a portal exists +for the length of time that it is needed. This is done by creating the +portal with a `Token` object, and the associated portal objects are +guaranteed to be valid while that `Token` object exists. This is supported +by essentially locking the array from further changes. + +`Token` objects are typically used when creating a control-side portal with +the `ReadPortal` or `WritePortal`. This is not to say that a `Token` would +not be useful; a control-side portal going out of scope is definitely a +problem. But the creation and destruction of portals in the control +environment is generally too much work for the possible benefits. + +However, under certain circumstances it could be useful to use a `Token` to +get a control-side portal. For example, if the `PrepareForExecution` method +of an `ExecutionObjectBase` needs to fill a small `ArrayHandle` on the +control side to pass to the execution side, it would be better to use the +provided `Token` object when doing so. This change allows you to optionally +provide that `Token` when creating these control-side portals. + +# Control Environment + +## Coordinate systems are stored as Fields + +Previously, `DataSet` managed `CoordinateSystem`s separately from `Field`s. +However, a `CoordinateSystem` is really just a `Field` with some special +attributes. Thus, coordinate systems are now just listed along with the +rest of the fields, and the coordinate systems are simply strings that +point back to the appropriate field. (This was actually the original +concept for `DataSet`, but the coordinate systems were separated from +fields for some now obsolete reasons.) + +This change should not be very noticeable, but there are a few consequences +that should be noted. + +1. The `GetCoordinateSystem` methods no longer return a reference to a + `CoordinateSystem` object. This is because the `CoordinateSystem` object + is made on the fly from the field. +2. When mapping fields in filters, the coordinate systems get mapped as + part of this process. This has allowed us to remove some of the special + cases needed to set the coordinate system in the output. +3. If a filter is generating a coordinate system in a special way + (different than mapping other point fields), then it can use the special + `CreateResultCoordinateSystem` method to attach this custom coordinate + system to the output. +4. The `DataSet::GetCoordinateSystems()` method to get a `vector<>` of all + coordinate systems is removed. `DataSet` no longer internally has this + structure. Although it could be built, the only reason for its existence + was to support passing coordinate systems in filters. Now that this is + done automatically, the method is no longer needed. + +## Check to make sure that the fields in a DataSet are the proper length + +It is possible in a `DataSet` to add a point field (or coordinate system) +that has a different number of points than reported in the cell set. +Likewise for the number of cells in cell fields. This is very bad practice +because it is likely to lead to crashes in worklets that are expecting +arrays of an appropriate length. + +Although `DataSet` will still allow this, a warning will be added to the +VTK-m logging to alert users of the inconsistency introduced into the +`DataSet`. Since warnings are by default printed to standard error, users +are likely to see it. + +## Change name of method to set the cell ghost levels in a DataSet + +Previously, the method was named `AddGhostCellField`. However, only one +ghost cell field can be marked at a time, so `SetGhostCellField` is more +appropriate. + +## Automatically make the fields with the global cell ghosts the cell ghosts + +Previously, if you added a cell field to a `DataSet` with a name that was +the same as that returned from `GetGlobalCellFieldName`, it was still only +recognized as a normal field. Now, that field is automatically recognized +as the cell ghost levels (unless the global cell field name is changed or +a different field is explicitly set as the cell ghost levels). + +## Particle class members are hidden + +The member variables of the `vtkm::Particle` classes are now hidden. This +means that external code will not be directly able to access member +variables like `Pos`, `Time`, and `ID`. Instead, these need to be retrieved +and changed through accessor methods. + +This follows standard C++ principles. It also helps us future-proof the +classes. It means that we can provide subclasses or alternate forms of +`Particle` that operate differently. It also makes it possible to change +interfaces while maintaining a deprecated interface. + +## Allow FieldSelection to simultaneously include and exclude fields + +The basic use of `FieldSelection` is to construct the class with a mode +(`None`, `Any`, `Select`, `Exclude`), and then specify particular fields +based off of this mode. This works fine for basic uses where the same code +that constructs a `FieldSelection` sets all the fields. + +But what happens, for example, if you have code that takes an existing +`FieldSelection` and wants to exclude the field named `foo`? If the +`FieldSelection` mode happens to be anything other than `Exclude`, the code +would have to go through several hoops to construct a new `FieldSelection` +object with this modified selection. + +To make this case easier, `FieldSelection` now has the ability to specify +the mode independently for each field. The `AddField` method now has an +optional mode argument the specifies whether the mode for that field should +be `Select` or `Exclude`. + +In the example above, the code can simply add the `foo` field with the +`Exclude` mode. Regardless of whatever state the `FieldSelection` was in +before, it will now report the `foo` field as not selected. + +## New partitioned cell locator class + +A new version of a locator, `CellLocatorParitioned`, is now available. This version of a +locator takes a `PartitionedDataSet` and builds a structure that will find the partition Ids and +cell Ids for the input array of locations. It runs CellLocatorGeneral for each partition. We +expect multiple hits and only return the first one (lowest partition Id) where the detected cell +is of type REGULAR (no ghost, not blanked) in the vtkGhostType array. If this array does not +exist in a partition, we assume that all cells are regular. + +vtkm::cont::CellLocatorPartitioned produces an Arrayhandle of the size of the number of +partitions filled with the execution objects of CellLocatorGeneral. It further produces an +Arrayhandle filled with the ReadPortals of the vtkGhost arrays to then select the non-blanked +cells from the potentially multiple detected cells on the different partitions. Its counterpart +on the exec side, vtkm::exec::CellLocatorPartitioned, contains the actual FindCell function. + +## Fix reading global ids of permuted cells + +The legacy VTK reader sometimes has to permute cell data because some VTK +cells are not directly supported in VTK-m. (For example, triangle strips +are not supported. They have to be converted to triangles.) + +The global and pedigree identifiers were not properly getting permuted. +This is now fixed. + +## Setting source parameters is more clear + +Originally, most of the sources used constructor parameters to set the +various options of the source. Although convenient, it was difficult to +keep track of what each parameter meant. To make the code more clear, +source parameters are now set with accessor functions (e.g. +`SetPointDimensions`). Although this makes code more verbose, it helps +prevent mistakes and makes the changes more resilient to future changes. + +## Attach compressed ZFP data as WholeDataSet field + +Previously, point fields compressed by ZFP were attached as point fields +on the output. However, using them as a point field would cause +problems. So, instead attache them as `WholeDataSet` fields. + +Also fixed a problem where the 1D decompressor created an output of the +wrong size. + +# Execution Environment + +## Removed ExecutionWholeArray class + +`ExecutionWholeArray` is an archaic class in VTK-m that is a thin wrapper +around an array portal. In the early days of VTK-m, this class was used to +transfer whole arrays to the execution environment. However, now the +supported method is to use `WholeArray*` tags in the `ControlSignature` of +a worklet. + +Nevertheless, the `WholeArray*` tags caused the array portal transferred to +the worklet to be wrapped inside of an `ExecutionWholeArray` class. This +is unnecessary and can cause confusion about the types of data being used. + +Most code is unaffected by this change. Some code that had to work around +the issue of the portal wrapped in another class used the `GetPortal` +method which is no longer needed (for obvious reasons). One extra feature +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. + +# Worklets and Filters + +## Correct particle density filter output field + +The field being created by `ParticleDensityNearestGridPoint` was supposed +to be associated with cells, but it was sized to the number of points. +Although the number of points will always be more than the number of cells +(so the array will be big enough), having inappropriately sized arrays can +cause further problems downstream. + +## Rename NewFilter base classes to Filter + +During the VTK-m 1.8 and 1.9 development, the filter infrastructure was +overhauled. Part of this created a completely new set of base classes. To +avoid confusion with the original filter base classes and ease transition, +the new filter base classes were named `NewFilter*`. Eventually after all +filters were transitioned, the old filter base classes were deprecated. + +With the release of VTK-m 2.0, the old filter base classes are removed. The +"new" filter base classes are no longer new. Thus, they have been renamed +simply `Filter` (and `FilterField`). + +## Fix handling of cell fields in Tube filter + +The `Tube` filter wraps a tube of polygons around poly line cells. +During this process it had a strange (and wrong) handling of cell data. +It assumed that each line had an independent field entry for each +segment of each line. It thus had lots of extra code to find the length +and offsets of the segment data in the cell data. + +This is simply not how cell fields work in VTK-m. In VTK-m, each cell +has exactly one entry in the cell field array. Even if a polyline has +100 segments, it only gets one cell field value. This behavior is +consistent with how VTK treats cell field arrays. + +The behavior the `Tube` filter was trying to implement was closer to an +"edge" field. However, edge fields are currently not supported in VTK-m. +The proper implementation would be to add edge fields to VTK-m. (This +would also get around some problems with the implementation that was +removed here when mixing polylines with other cell types and degenerate +lines.) + +# Build + +## More performance test options + +More options are available for adding performance regression tests. These +options allow you to pass custom options to the benchmark test so that you +are not limited to the default values. They also allow multiple tests to be +created from the same benchmark executable. Separating out the benchmarks +allows the null hypothesis testing to better catch performance problems +when only one of the tested filters regresses. It also allows passing +different arguments to different benchmarks. + +## Output complete list of libraries for external Makefiles + +There is a Makefile include, `vtkm_config.mk`, and a package include, +`vtkm.pc`, that are configured so that external programs that do not use +CMake have a way of importing VTK-m's configuration. However, the set of +libraries was hardcoded. In particular, many of the new filter libraries +were missing. + +Rather than try to maintain this list manually, the new module mechanism +in the CMake configuration is used to get a list of libraries built and +automatically build these lists. + +## VTK-m namespace for its exported CMake targets + +VTK-m exported CMake targets are now prefixed with the `vtkm::` namespace. + +### What it means for VTK-m users + +VTK-m users will now need to prepend a `vtkm::` prefix when they refer to a +VTK-m CMake target in their projects as shown below: + +``` +add_executable(example example.cxx) +## Before: +target_link_libraries(example vtkm_cont vtkm_rendering) +## Now: +target_link_libraries(example vtkm::cont vtkm::rendering) +``` + +For compatibility purposes we still provide additional exported targets with the +previous naming scheme, in the form of `vtkm_TARGET`, when VTK-m is found +using: + +``` +## With any version less than 2.0 +find_package(VTK-m 1.9) + +add_executable(example example.cxx) +## This is still valid +target_link_libraries(example vtkm_cont vtkm_rendering) +``` + +Use with care since we might remove those targets in future releases. + +### What it means for VTK-m developers + +While VTK-m exported targets are now prefixed with the `vtkm::` prefix, internal +target names are still in the form of `vtkm_TARGET`. + +To perform this name transformation in VTK-m targets a new CMake function has +been provided that decorates the canonical `install` routine. Use this functions +instead of `install` when creating new `VTK-m` targets, further information can +be found at the `vtkm_install_targets` function header at +`CMake/VTKmWrappers.cmake`. + +# Other + +## Expose the Variant helper class + +For several versions, VTK-m has had a `Variant` templated class. This acts +like a templated union where the object will store one of a list of types +specified as the template arguments. (There are actually 2 versions for the +control and execution environments, respectively.) + +Because this is a complex class that required several iterations to work +through performance and compiler issues, `Variant` was placed in the +`internal` namespace to avoid complications with backward compatibility. +However, the class has been stable for a while, so let us expose this +helpful tool for wider use. + +## Fix VTKM_LOG_SCOPE + +The `VTKM_LOG_SCOPE` macro was not working as intended. It was supposed to +print a log message immediately and then print a second log message when +leaving the scope along with the number of seconds that elapsed between the +two messages. + +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. diff --git a/docs/changelog/benchmark-options.md b/docs/changelog/benchmark-options.md deleted file mode 100644 index 457226cb4..000000000 --- a/docs/changelog/benchmark-options.md +++ /dev/null @@ -1,9 +0,0 @@ -# More performance test options - -More options are available for adding performance regression tests. These -options allow you to pass custom options to the benchmark test so that you -are not limited to the default values. They also allow multiple tests to be -created from the same benchmark executable. Separating out the benchmarks -allows the null hypothesis testing to better catch performance problems -when only one of the tested filters regresses. It also allows passing -different arguments to different benchmarks. diff --git a/docs/changelog/build-modules.md b/docs/changelog/build-modules.md deleted file mode 100644 index ea3a0db2e..000000000 --- a/docs/changelog/build-modules.md +++ /dev/null @@ -1,16 +0,0 @@ -# Added modules to the build system - -VTK-m libraries and other targets can now be built as modules. The -advantage of modules is that you can selectively choose which -modules/libraries will be built. This makes it easy to create a more -stripped down compile of VTK-m. For example, you might want a reduced set -of libraries to save memory or you might want to turn off certain libraries -to save compile time. - -The module system will automatically determine dependencies among the -modules. It is capable of weakly turning off a module where it will still -be compiled if needed. Likewise, it is capabile of weakly turning on a -module where the build will still work if it cannot be created. - -The use of modules is described in the `Modules.md` file in the `docs` -directory of the VTK-m source. diff --git a/docs/changelog/cont-portal-token.md b/docs/changelog/cont-portal-token.md deleted file mode 100644 index b666508f5..000000000 --- a/docs/changelog/cont-portal-token.md +++ /dev/null @@ -1,21 +0,0 @@ -# Support providing a Token to ReadPortal and WritePortal - -When managing portals in the execution environment, `ArrayHandle` uses the -`Token` object to ensure that the memory associated with a portal exists -for the length of time that it is needed. This is done by creating the -portal with a `Token` object, and the associated portal objects are -guaranteed to be valid while that `Token` object exists. This is supported -by essentially locking the array from further changes. - -`Token` objects are typically used when creating a control-side portal with -the `ReadPortal` or `WritePortal`. This is not to say that a `Token` would -not be useful; a control-side portal going out of scope is definitely a -problem. But the creation and distruction of portals in the control -environment is generally too much work for the possible benefits. - -However, under certain circumstances it could be useful to use a `Token` to -get a control-side portal. For example, if the `PrepareForExecution` method -of an `ExecutionObjectBase` needs to fill a small `ArrayHandle` on the -control side to pass to the execution side, it would be better to use the -provided `Token` object when doing so. This change allows you to optionally -provide that `Token` when creating these control-side portals. diff --git a/docs/changelog/coords-are-fields.md b/docs/changelog/coords-are-fields.md deleted file mode 100644 index 06d2261d1..000000000 --- a/docs/changelog/coords-are-fields.md +++ /dev/null @@ -1,29 +0,0 @@ -# Coordiante systems are stored as Fields - -Previously, `DataSet` managed `CoordinateSystem`s separately from `Field`s. -However, a `CoordinateSystem` is really just a `Field` with some special -attributes. Thus, coordiante systems are now just listed along with the -rest of the fields, and the coordinate systems are simply strings that -point back to the appropriate field. (This was actually the original -concept for `DataSet`, but the coordinate systems were separated from -fields for some now obsolete reasons.) - -This change should not be very noticible, but there are a few consequences -that should be noted. - -1. The `GetCoordinateSystem` methods no longer return a reference to a - `CoordinateSystem` object. This is because the `CoordinateSystem` object - is made on the fly from the field. -2. When mapping fields in filters, the coordinate systems get mapped as - part of this process. This has allowed us to remove some of the special - cases needed to set the coordinate system in the output. -3. If a filter is generating a coordinate system in a special way - (different than mapping other point fields), then it can use the special - `CreateResultCoordianteSystem` method to attach this custom coordinate - system to the output. -4. The `DataSet::GetCoordianteSystems()` method to get a `vector<>` of all - coordiante systems is removed. `DataSet` no longer internally has this - structure. Although it could be built, the only reason for its existance - was to support passing coordinate systems in filters. Now that this is - done autmoatically, the method is no longer needed. - diff --git a/docs/changelog/delete-deprecated.md b/docs/changelog/delete-deprecated.md deleted file mode 100644 index bfcaf864c..000000000 --- a/docs/changelog/delete-deprecated.md +++ /dev/null @@ -1,7 +0,0 @@ -# Delete deprecated features - -With the major release of VTK-m 2.0, we are cleaning up the code by -removing deprecated features. For software using VTK-m 1.9, you should have -gotten deprecation warnings about any feature that is removed. Thus, to -ease porting to VTK-m 2.0, software should consider updating to VTK-m 1.9 -first. diff --git a/docs/changelog/expose-variant.md b/docs/changelog/expose-variant.md deleted file mode 100644 index 8e7358a79..000000000 --- a/docs/changelog/expose-variant.md +++ /dev/null @@ -1,12 +0,0 @@ -# Expose the Variant helper class - -For several versions, VTK-m has had a `Variant` templated class. This acts -like a templated union where the object will store one of a list of types -specified as the template arguments. (There are actually 2 versions for the -control and execution environments, respectively.) - -Because this is a complex class that required several iterations to work -through performance and compiler issues, `Variant` was placed in the -`internal` namespace to avoid complications with backward compatibility. -However, the class has been stable for a while, so let us expose this -helpful tool for wider use. diff --git a/docs/changelog/external-lib-lists.md b/docs/changelog/external-lib-lists.md deleted file mode 100644 index df29ab543..000000000 --- a/docs/changelog/external-lib-lists.md +++ /dev/null @@ -1,11 +0,0 @@ -# Output complete list of libraries for external Makefiles - -There is a Makefile include, `vtkm_config.mk`, and a package include, -`vtkm.pc`, that are configured so that external programs that do not use -CMake have a way of importing VTK-m's configuration. However, the set of -libraries was hardcoded. In particular, many of the new filter libraries -were missing. - -Rather than try to maintain this list manually, the new module mechanism -in the CMake configuration is used to get a list of libraries built and -automatically build these lists. diff --git a/docs/changelog/field-length-checking.md b/docs/changelog/field-length-checking.md deleted file mode 100644 index e8624ed26..000000000 --- a/docs/changelog/field-length-checking.md +++ /dev/null @@ -1,12 +0,0 @@ -# Check to make sure that the fields in a DataSet are the proper length - -It is possible in a `DataSet` to add a point field (or coordinate system) -that has a different number of points than reported in the cell set. -Likewise for the number of cells in cell fields. This is very bad practice -because it is likely to lead to crashes in worklets that are expecting -arrays of an appropriate length. - -Although `DataSet` will still allow this, a warning will be added to the -VTK-m logging to alert users of the inconsistency introduced into the -`DataSet`. Since warnings are by default printed to standard error, users -are likely to see it. diff --git a/docs/changelog/fix-log-scope.md b/docs/changelog/fix-log-scope.md deleted file mode 100644 index 50dc9c62f..000000000 --- a/docs/changelog/fix-log-scope.md +++ /dev/null @@ -1,11 +0,0 @@ -# Fix VTKM_LOG_SCOPE - -The `VTKM_LOG_SCOPE` macro was not working as intended. It was supposed to -print a log message immediately and then print a second log message when -leaving the scope along with the number of seconds that elapsed between the -two messages. - -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. diff --git a/docs/changelog/ghost-cell-api.md b/docs/changelog/ghost-cell-api.md deleted file mode 100644 index dbc937d10..000000000 --- a/docs/changelog/ghost-cell-api.md +++ /dev/null @@ -1,5 +0,0 @@ -# Change name of method to set the cell ghost levels in a DataSet - -Previously, the method was named `AddGhostCellField`. However, only one -ghost cell field can be marked at a time, so `SetGhostCellField` is more -appropriate. diff --git a/docs/changelog/ghost-cell-global-name.md b/docs/changelog/ghost-cell-global-name.md deleted file mode 100644 index 0dfbfc528..000000000 --- a/docs/changelog/ghost-cell-global-name.md +++ /dev/null @@ -1,7 +0,0 @@ -# Automatically make the fields with the global cell ghosts the cell ghosts - -Previously, if you added a cell field to a `DataSet` with a name that was -the same as that returned from `GetGlobalCellFieldName`, it was still only -recognized as a normal field. Now, that field is automatically recognized -as a the cell ghost levels (unless the global cell field name is changed or -a different field is explicitly set as the cell ghost levels). diff --git a/docs/changelog/hide-particle-members.md b/docs/changelog/hide-particle-members.md deleted file mode 100644 index eeeaf4d9b..000000000 --- a/docs/changelog/hide-particle-members.md +++ /dev/null @@ -1,11 +0,0 @@ -# Particle class members are hidden - -The member variables of the `vtkm::Particle` classes are now hidden. This -means that external code will not be directly able to access member -variables like `Pos`, `Time`, and `ID`. Instead, these need to be retrieved -and changed through accessor methods. - -This follows standard C++ principles. It also helps us future-proof the -classes. It means that we can provide subclasses or alternate forms of -`Particle` that operate differently. It also makes it possible to change -interfaces while maintaining a deprecated interface. diff --git a/docs/changelog/include-and-exclude-field-selection.md b/docs/changelog/include-and-exclude-field-selection.md deleted file mode 100644 index a36fceaa3..000000000 --- a/docs/changelog/include-and-exclude-field-selection.md +++ /dev/null @@ -1,21 +0,0 @@ -# Allow FieldSelection to simultaneously include and exclude fields - -The basic use of `FieldSelection` is to construct the class with a mode -(`None`, `Any`, `Select`, `Exclude`), and then specify particular fields -based off of this mode. This works fine for basic uses where the same code -that constructs a `FieldSelection` sets all the fields. - -But what happens, for example, if you have code that takes an existing -`FieldSelection` and wants to exclude the field named `foo`? If the -`FieldSelection` mode happens to be anything other than `Exclude`, the code -would have to go through several hoops to construct a new `FieldSelection` -object with this modified selection. - -To make this case easier, `FieldSelection` now has the ability to specify -the mode independently for each field. The `AddField` method now has an -optional mode argument the specifies whether the mode for that field should -be `Select` or `Exclude`. - -In the example above, the code can simply add the `foo` field with the -`Exclude` mode. Regardless of whatever state the `FieldSelection` was in -before, it will now report the `foo` field as not selected. diff --git a/docs/changelog/no-execution-whole-array.md b/docs/changelog/no-execution-whole-array.md deleted file mode 100644 index d7eb97ba7..000000000 --- a/docs/changelog/no-execution-whole-array.md +++ /dev/null @@ -1,18 +0,0 @@ -# Removed ExecutionWholeArray class - -`ExecutionWholeArray` is an archaic class in VTK-m that is a thin wrapper -around an array portal. In the early days of VTK-m, this class was used to -transfer whole arrays to the execution environment. However, now the -supported method is to use `WholeArray*` tags in the `ControlSignature` of -a worklet. - -Nevertheless, the `WholeArray*` tags caused the array portal transferred to -the worklet to be wrapped inside of an `ExecutionWholeArray` class. This -is unnecessary and can cause confusion about the types of data being used. - -Most code is unaffected by this change. Some code that had to work around -the issue of the portal wrapped in another class used the `GetPortal` -method which is no longer needed (for obvious reasons). One extra feature -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. diff --git a/docs/changelog/particle-density-output-field.md b/docs/changelog/particle-density-output-field.md deleted file mode 100644 index 2ffb96ede..000000000 --- a/docs/changelog/particle-density-output-field.md +++ /dev/null @@ -1,7 +0,0 @@ -# Correct particle density filter output field - -The field being created by `ParticleDensityNearestGridPoint` was supposed -to be associated with cells, but it was sized to the number of points. -Although the number of points will always be more than the number of cells -(so the array will be big enough), having inappropriately sized arrays can -cause further problems downstream. diff --git a/docs/changelog/partitioned-cell-locator.md b/docs/changelog/partitioned-cell-locator.md deleted file mode 100644 index 365fe9cf5..000000000 --- a/docs/changelog/partitioned-cell-locator.md +++ /dev/null @@ -1,14 +0,0 @@ -# New partitioned cell locator class - -A new version of a locator, `CellLocatorParitioned`, is now available. This version of a -locator takes a `PartitionedDataSet` and builds a structure that will find the partition Ids and -cell Ids for the input array of locations. It runs CellLocatorGeneral for each partition. We -expect multiple hits and only return the first one (lowest partition Id) where the detected cell -is of type REGULAR (no ghost, not blanked) in the vtkGhostType array. If this array does not -exist in a partition, we assume that all cells are regular. - -vtkm::cont::CellLocatorPartitioned produces an Arrayhandle of the size of the number of -partitions filled with the execution objects of CellLocatorGeneral. It further produces an -Arrayhandle filled with the ReadPortals of the vtkGhost arrays to then select the non-blanked -cells from the potentially multiple detected cells on the different partitions. Its counterpart -on the exec side, vtkm::exec::CellLocatorPartitioned, contains the actual FindCell function. diff --git a/docs/changelog/read-permuted-global-cell-ids.md b/docs/changelog/read-permuted-global-cell-ids.md deleted file mode 100644 index ba07b5165..000000000 --- a/docs/changelog/read-permuted-global-cell-ids.md +++ /dev/null @@ -1,8 +0,0 @@ -# Fix reading global ids of permuted cells - -The legacy VTK reader sometimes has to permute cell data because some VTK -cells are not directly supported in VTK-m. (For example, triangle strips -are not supported. They have to be converted to triangles.) - -The global and petigree identifiers were not properly getting permuted. -This is now fixed. diff --git a/docs/changelog/remove-deprecated.md b/docs/changelog/remove-deprecated.md deleted file mode 100644 index 33b786dd1..000000000 --- a/docs/changelog/remove-deprecated.md +++ /dev/null @@ -1,8 +0,0 @@ -# Remove deprecated features from VTK-m - -With the major revision 2.0 of VTK-m, many items previously marked as -deprecated were removed. If updating to a new version of VTK-m, it is -recommended to first update to VTK-m 1.9, which will include the deprecated -features but provide warnings (with the right compiler) that will point to -the replacement code. Once the deprecations have been fixed, updating to -2.0 should be smoother. diff --git a/docs/changelog/rename-filter-base.md b/docs/changelog/rename-filter-base.md deleted file mode 100644 index 8185e5a88..000000000 --- a/docs/changelog/rename-filter-base.md +++ /dev/null @@ -1,11 +0,0 @@ -# Rename NewFilter base classes to Filter - -During the VTK-m 1.8 and 1.9 development, the filter infrastructure was -overhauled. Part of this created a completely new set of base classes. To -avoid confusion with the original filter base classes and ease transition, -the new filter base classes were named `NewFilter*`. Eventually after all -filters were transitioned, the old filter base classes were deprecated. - -With the release of VTK-m 2.0, the old filter base classes are removed. The -"new" filter base classes are no longer new. Thus, they have been renamed -simply `Filter` (and `FilterField`). diff --git a/docs/changelog/source-parameters.md b/docs/changelog/source-parameters.md deleted file mode 100644 index f7c0aadec..000000000 --- a/docs/changelog/source-parameters.md +++ /dev/null @@ -1,8 +0,0 @@ -# Setting source parameters is more clear - -Originally, most of the sources used constructor parameters to set the -various options of the source. Although convenient, it was difficult to -keep track of what each parameter meant. To make the code more clear, -source parameters are now set with accessor functions (e.g. -`SetPointDimensions`). Although this makes code more verbose, it helps -prevent mistakes and makes the changes more resilient to future changes. diff --git a/docs/changelog/tube-cell-fields.md b/docs/changelog/tube-cell-fields.md deleted file mode 100644 index 540e86a13..000000000 --- a/docs/changelog/tube-cell-fields.md +++ /dev/null @@ -1,19 +0,0 @@ -# Fix handling of cell fields in Tube filter - -The `Tube` filter wraps a tube of polygons around poly line cells. -During this process it had a strange (and wrong) handling of cell data. -It assumed that each line had an independent field entry for each -segment of each line. It thus had lots of extra code to find the length -and offsets of the segment data in the cell data. - -This is simply not how cell fields work in VTK-m. In VTK-m, each cell -has exactly one entry in the cell field array. Even if a polyline has -100 segments, it only gets one cell field value. This behavior is -consistent with how VTK treats cell field arrays. - -The behavior the `Tube` filter was trying to implement was closer to an -"edge" field. However, edge fields are currently not supported in VTK-m. -The proper implementation would be to add edge fields to VTK-m. (This -would also get around some problems with the implementation that was -removed here when mixing polylines with other cell types and degenerate -lines.) diff --git a/docs/changelog/vtkm-cmake-targets-namespaces.md b/docs/changelog/vtkm-cmake-targets-namespaces.md deleted file mode 100644 index ad1101855..000000000 --- a/docs/changelog/vtkm-cmake-targets-namespaces.md +++ /dev/null @@ -1,42 +0,0 @@ -# VTK-m namespace for its exported CMake targets - -VTK-m exported CMake targets are now prefixed with the `vtkm::` namespace. - -## What it means for VTK-m users - -VTK-m users will now need to prepend a `vtkm::` prefix when they refer to a -VTK-m CMake target in their projects as shown below: - -``` -add_executable(example example.cxx) -# Before: -target_link_libraries(example vtkm_cont vtkm_rendering) -# Now: -target_link_libraries(example vtkm::cont vtkm::rendering) -``` - -For compatibility purposes we still provide additional exported targets with the -previous naming scheme, in the form of `vtkm_TARGET`, when VTK-m is found -using: - -``` -# With any version less than 2.0 -find_package(VTK-m 1.9) - -add_executable(example example.cxx) -# This is still valid -target_link_libraries(example vtkm_cont vtkm_rendering) -``` - -Use with care since we might remove those targets in future releases. - -## What it means for VTK-m developers - -While VTK-m exported targets are now prefixed with the `vtkm::` prefix, internal -target names are still in the form of `vtkm_TARGET`. - -To perform this name transformation in VTK-m targets a new CMake function has -been provided that decorates the canonical `install` routine. Use this functions -instead of `install` when creating new `VTK-m` targets, further information can -be found at the `vtkm_install_targets` function header at -`CMake/VTKmWrappers.cmake`. diff --git a/docs/changelog/zfp-output-fields.md b/docs/changelog/zfp-output-fields.md deleted file mode 100644 index dced4dc5a..000000000 --- a/docs/changelog/zfp-output-fields.md +++ /dev/null @@ -1,8 +0,0 @@ -# Attach compressed ZFP data as WholeDatSet field - -Previously, point fields compressed by ZFP were attached as point fields -on the output. However, using them as a point field would cause -problems. So, instead attache them as `WholeDataSet` fields. - -Also fixed a problem where the 1D decompressor created an output of the -wrong size.