014c429eb Make divide by volume in particle density estimate a little safer
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Li-Ta Lo <ollie@lanl.gov>
Merge-request: !3022
The `HierarchicalAugmenter` used in the distributed contour tree filter
attempts to save memory by releasing buffers used to send and receive
data after the DIY enqueues and dequeues are posted. This works as long
as the DIY serialization process copies the data in the arrays. However,
changes are coming where the data is sent directly from the buffers.
These changes cause a deadlock because the enqueue places a read lock
until the data is sent while the release tried to get a write lock.
The solution is simply to "forget" the array rather than explicitly
delete it. In this case, the array will automatically be deleted once
everyone is done with it.
While going through the VTK-m code to identify where a cast-and-call was
happening against VTKM_DEFAULT_TYPE_LIST, I ran into a subtle case in
`ParticleDensityBase` that was calling a worklet with an
`UnknownArrayHandle`. This works OK, but was probably compiling for
unnecessary types (for example, vectors). Changed the field resolution
to be more intentional.
MR !2969 was meant to update the clip filters such that their field
mapping works on any field type and preserves the value type. Although
this was done for `ClipWithField`, it was not fully implemented for
`ClipWithImplicitFunction`. These changes update
`ClipWithImplicitFunction` to match its sibling.
ac889b500 Implement VecTraits class for all types
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Li-Ta Lo <ollie@lanl.gov>
Merge-request: !3018
f545feba8 Add changelog for documenting data license
a24358a1a Document source of WarpX files
60559ce9b Document the source of venn250.vtk
796ec9638 Document data that comes from VisIt tutorial
06391c4e6 Clarify license for ECL data
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Vicente Bolea <vicente.bolea@kitware.com>
Merge-request: !3016
The `VecTraits` class allows templated functions, methods, and classes to
treat type arguments uniformly as `Vec` types or to otherwise differentiate
between scalar and vector types. This only works for types that `VecTraits`
is defined for.
The `VecTraits` templated class now has a default implementation that will
be used for any type that does not have a `VecTraits` specialization. This
removes many surprise compiler errors when using a template that, unknown
to you, has `VecTraits` in its implementation.
One potential issue is that if `VecTraits` gets defined for a new type, the
behavior of `VecTraits` could change for that type in backward-incompatible
ways. If `VecTraits` is used in a purely generic way, this should not be an
issue. However, if assumptions were made about the components and length,
this could cause problems.
Fixes#589
Some of the data sets that are included from VTK-m are derived from the
VisIt Tutorial Data (https://www.visitusers.org/index.php?title=Tutorial_Data).
These are covered by the VisIt license, as communicated by Eric Brugger.
Although the license for these data is compatible with VTK-m's license,
we should still attribute the source of the data and make clear the
copyrights. The data are moved into the third_party directory, and
readmes are added to document everything.
The noise.vtk and noise.bov files have been renamed example.vtk and
example_temp.bov to match the name of the file in the VisIt tutorial
data archive. The ucd3d.vtk file, which is similar to the curv3d.silo
data but altered, has been removed. It was not used for any tests. It
was referenced in a couple of example programs, but the reference is
easily changed.
Some of the test data sets are derived from data sets that are commonly
distributed to test visualization algorithms and are featured in
numerous papers. However, I am unable to track down the original source
let alone identify what license, if any, they were released under. To
avoid any complications with data ownership, remove these data sets and
replace them with in house data sets that we explicitly own.
The precompiled `ArrayRangeCompute` function was not following proper fast
paths for special arrays. For example, when computing the range of an
`ArrayHandleUniformPointCoordinates`, the ranges should be taken from the
origin and spacing of the special array. However, the precompiled version
was calling the generic range computation, which was doing an unnecessary
reduction over the entire array. These fast paths have been fixed.
These mistakes in the code were caused by quirks in how templated method
overloading works. To prevent this mistake from happening again in the
precompiled `ArrayRangeCompute` function and elsewhere, all templated forms
of `ArrayRangeCompute` have been deprecated. Most will call
`ArrayRangeCompute` with no issues. For those that need the templated
version, `ArrayRangeComputeTemplate` replaces the old templated
`ArrayRangeCompute`. There is exactly one templated declaration of
`ArrayRangeComputeTemplate` that uses a class, `ArrayRangeComputeImpl`,
with partial specialization to ensure the correct form is used.
267ee49cb docker: update kokkos hip image
67bf9a966 docker: update kokkos hip image
50d4ab5cc CMake: VTKm_ENABLE_KOKKOS_THRUST to depend on Kokkos with CUDA or HIP enabled
0604f314a Fix for building SERIAL unit tests with KOKKOS_HIP/CUDA enabled
802bf80b0 CI: Add rocthrust installation step
fda475d5b Rework Thrust CMake options
e6f63a807 Adding CMake tweaks to turn off thrust algorithms if thrust is not detected.
5a72275ed Rewrite sorting specialization using std::enable_if_t
...
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !2926
`vtkm::cont::DataSet` is a dynamic object that can hold cell sets and
fields of many different types, none of which are known until runtime. This
causes a problem with serialization, which has to know what type to compile
the serialization for, particularly when unserializing the type at the
receiving end. The original implementation "solved" the problem by creating
a secondary wrapper object that was templated on types of field arrays and
cell sets that might be serialized. This is not a great solution as it
punts the problem to algorithm developers.
This problem has been completely solved for fields, as it is possible to
serialize most types of arrays without knowing their type now. You still
need to iterate over every possible `CellSet` type, but there are not that
many `CellSet`s that are practically encountered. Thus, there is now a
direct implementation of `Serialization` for `DataSet` that covers all the
data types you are likely to encounter.
The old `SerializableDataSet` has been deprecated. In the unlikely event an
algorithm needs to transfer a non-standard type of `CellSet` (such as a
permuted cell set), it can use the replacement `DataSetWithCellSetTypes`,
which just specifies the cell set types.
The `UnknownArrayHandle` has been updated to allow
`ArrayHandleRuntimeVec` to work interchangeably with basic
`ArrayHandle`. If an `ArrayHandleRuntimeVec` is put into an
`UnknownArrayHandle`, it can be later retrieved as an `ArrayHandleBasic`
as long as the base component type matches and it has the correct amount
of components. This means that an array can be created as an
`ArrayHandleRuntimeVec` and be used with any filters or most other
features designed to operate on basic `ArrayHandle`s. Likewise, an array
added as a basic `ArrayHandle` can be retrieved in an
`ArrayHandleRuntimeVec`. This makes it easier to pull arrays from VTK-m
and place them in external structures (such as `vtkDataArray`).
504d241b4 Correct documentation about `ArrayHandle`s with `Vec`-like values
cdd1dbd7b Add ArrayHandleRuntimeVec
a7679c9e9 Add more safety to VecTraits
da731005b Remove unused comments in test
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Sujin Philip <sujin.philip@kitware.com>
Merge-request: !2982
`UnitTestAbort.cxx` does not touch any code that needs to be compiled on
the device, so you do not need a device compiler. Use the standard C++
compiler instead.
The new `ArrayHandleRuntimeVec` is a fancy `ArrayHandle` allows you to
specify a basic array of `Vec`s where the number of components of the `Vec`
are not known until runtime. (It can also optionally specify scalars.) The
behavior is much like that of `ArrayHandleGroupVecVariable` except that its
representation is much more constrained. This constrained representation
allows it to be automatically converted to an `ArrayHandleBasic` with the
proper `Vec` value type. This allows one part of code (such as a file
reader) to create an array with any `Vec` size, and then that array can be
fed to an algorithm that expects an `ArrayHandleBasic` of a certain value
type.
You can often get compile errors when trying to get `Vec` attributes
from types that do not define `VecTraits`. This is of particular problem
when you create an object like `Vec` with a component that does not
define `VecTraits`. Make using these types safer by internally using
`SafeVecTraits`, which will gracefully handle types that do not have
`VecTraits`.
While updating the user's guide, I noticed a couple of minor problems
with how filters map fields. First, if a filter was using
`CreateResultCoordinateSystem`, it did not respect the
`PassCoordinateSystems` flag. Second, if both an `initializer_list` and
a mode was given to `SetFieldsToPass`, the mode was captured
incorrectly. Both problems are corrected.
The `GetNumberOfComponents` and `GetNumberOfComponentsFlat` methods in
`UnknownArrayHandle` have been updated to correctly report the number of
components in special `ArrayHandle`s where the `Vec` sizes of the values
are not selected until runtime.
Previously, these methods always reported 0 because the value type could
not report the size of the `Vec`. The lookup has been modified to query the
`ArrayHandle`'s `Storage` for the number of components where supported.
Note that this only works on `Storage` that provides a method to get the
runtime `Vec` size. If that is not provided, as will be the case if the
number of components can vary from one value to the next, it will still
report 0.
This feature is implemented by looking for a method named
`GetNumberOfComponents` is the `Storage` class for the `ArrayHandle`. If
this method is found, it is used to query the size at runtime.
Previously, `VectorMagnitude` only worked with `Vec`s of size 2, 3, or
4. It now works with `Vec`s of any size. It also avoids a memory copy of
non-float types (although it does add a little arithmetic in the
computation).
CUDA 12 adds a `cub::Swap` function that creates ambiguity with `vtkm::Swap`.
This happens when a function from the `cub` namespace is called with an object
of a class defined in the `vtkm` namespace as an argument. If that function
has an unqualified call to `Swap`, it results in ADL being used, causing the
templated functions `cub::Swap` and `vtkm::Swap` to conflict.
Previously, the probe filter only worked on certain `Vec` sizes and
converted many types to floating point.
This change uses the extract component feature to pull data from any
array at its natural component type.
The bad part of this change is that it has to call the worklet
separately for each component in the field. That adds overhead and
probably lowers the cache efficiency. It was implemented this way
because the cell interpolation function does not work with the
recombined vecs returned from extract array.
The `Fetch::Load` for an input array of a topology map for an XGC array
(that uses `ConnectivityExtrude`) was failing to compile because it
creates a return `Vec` and then fills it. That does not work if the
input array has values that cannot be default constructed. This is the
case for `ArrayHandleRecombineVec`, which creates values that lazily
pull data out of portals.
Change the code to careful construct the return `Vec` such that it does
not require the default constructor of the components.
The previous version of the `PointAverage` filter used a float fallback
to handle most array types. The problem with this approach other than
converting field types perhaps unexpectantly is that it does not work
with every `Vec` size. This change uses the extract by component feature
of `UnknownArrayHandle` to handle every array type.
To implement this change the `PointAverage` worklet had to be changed to
handle recombined vecs. This change resulted in a feature degridation
where it can no longer be compiled for inputs of incompatible `Vec`
sizes. This feature dates back to when worklets like this were exposed
in the interface. This worklet class is now hidden away from the exposed
interface, so this degredation should not affect end users. There are
some unit tests that use this worklet to test other features, and these
had to be updated.
The previous version of the `CellAverage` filter used a float fallback
to handle most array types. The problem with this approach other than
converting field types perhaps unexpectantly is that it does not work
with every `Vec` size. This change uses the extract by component feature
of `UnknownArrayHandle` to handle every array type.
To implement this change the `CellAverage` worklet had to be changed to
handle recombined vecs. This change resulted in a feature degridation
where it can no longer be compiled for inputs of incompatible `Vec`
sizes. This feature dates back to when worklets like this were exposed
in the interface. This worklet class is now hidden away from the exposed
interface, so this degredation should not affect end users. There are
some unit tests that use this worklet to test other features, and these
had to be updated.
Use the `MapFieldPermutation` function when mapping point coordinates
for points that are removed. (This function was already being used for
the rest of the fields.) Also remove some unneeded code in the
`CleanGrid` worklets.
719d347fd Update contour filter's field map to work on any field type
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Sujin Philip <sujin.philip@kitware.com>
Merge-request: !2973
447b8e711 Fill input to test of array extract from stride array
726bb0910 Fix floating point exception in Kokkos sort
89245c3df Remove NUMA regions option
4912d1d04 Update --kokkos-threads to --kokkos-num-threads
9f77e1118 Do not test if Kokkos device id does not match
fa30d6774 Update the minimum Kokkos required to 3.7
3a96e9429 ci: update Kokkos docker images
674572419 Use Kokkos 3.7.1 in the CI builds
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Vicente Bolea <vicente.bolea@kitware.com>
Merge-request: !2967
Use the extract component functionality to get data from any type of
array. This prevents converting fields to `vtkm::DefaultFloat` and
supports any size `Vec` in the component.
THe current version of sort in Kokkos does not check whether the array
is of size 0, and that messes up its bin calculation. If the size of the
array is less than 2, skip the sort since the order cannot change.
This configuration option was only added because Kokkos has such a flag.
But this flag is now deprecated in Kokkos and has no effect, so remove
it from VTK-m.
There was a regression test to check for an exception if the requested
Kokkos device id did not match the `KOKKOS_DEVICE_ID` environment
variable. New versions of Kokkos do not throw an exception (they just
pick one over the other), so remove this check.
The previous implementation of the map field in the clip filters
(`ClipWithField` and `ClipWithImplicitFunction`) checked for common field
types and interpolated those. If the field value type did not match, it
would either convert the field to floats (which is at odds with what VTK
does) or fail outright if the `Vec` length is not supported.
The map field function for clip has been changed to support all possible
types. It does this by using the extract component functionality to get
data from any type of array.
When you use an `ArrayHandle` as an output array in a worklet (for example,
as a `FieldOut`), the fetch operation does not read values from the array
during the `Load`. Instead, it just constructs a new object. This makes
sense as an output array is expected to have garbage in it anyway.
This is a problem for some special arrays that contain `Vec`-like objects
that are sized dynamically. For example, if you use an
`ArrayHandleGroupVecVariable`, each entry is a dynamically sized `Vec`. The
array is referenced by creating a special version of `Vec` that holds a
reference to the array portal and an index. Components are retrieved and
set by accessing the memory in the array portal. This allows us to have a
dynamically sized `Vec` in the execution environment without having to
allocate within the worklet.
The problem comes when we want to use one of these arrays with `Vec`-like
objects for an output. The typical fetch fails because you cannot construct
one of these `Vec`-like objects without an array portal to bind it to. In
these cases, we need the fetch to create the `Vec`-like object by reading
it from the array. Even though the data will be garbage, you get the
necessary buffer into the array (and nothing more).
Previously, the problem was fixed by creating partial specializations of
the `Fetch` for these `ArrayHandle`s. This worked OK as long as you were
using the array directly. However, the approach failed if the `ArrayHandle`
was wrapped in another `ArrayHandle` (for example, if an `ArrayHandleView`
was applied to an `ArrayHandleGroupVecVariable`).
To get around this problem and simplify things, the basic `Fetch` for
direct output arrays is changed to handle all cases where the values in the
`ArrayHandle` cannot be directly constructed. A compile-time check of the
array's value type is checked with `std::is_default_constructible`. If it
can be constructed, then the array is not accessed. If it cannot be
constructed, then it grabs a value out of the array.
This feature enables the ability to anonomously create an array (such as
with `UnknownArrayHandle::NewInstance()`) and then use that as an output
array.
This feature enables the ability to anonomously create an array (such as
with `UnknownArrayHandle::NewInstance()`) and then use that as an output
array. Although resizing `ArrayHandleStride` is a little wonky, it
allows worklets to resize them after creation rather than having to know
what size to make and allocating the array.
CUDA 12 adds a `cub::Swap` function that creates ambiguity with `vtkm::Swap`.
This happens when a function from the `cub` namespace is called with an object
of a class defined in the `vtkm` namespace as an argument. If that function
has an unqualified call to `Swap`, it results in ADL being used, causing the
templated functions `cub::Swap` and `vtkm::Swap` to conflict.
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.
There are some special functions/methods that take as an argument a
function-like object and then call that function with some arguments.
There are some instances where a templated function was passed given the
appropriate template. Even though there is a specific function, this
gets passed as a function pointer and calling a function pointer on some
devices is a no-no.
Replace these function arguments with lambdas, which are constructed as
unnamed functor objects.
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.
The PerlinNoise source has a mode where if a seed is not set, it will
choose a new seed every time it is executed. It did this by using the
value 0 as an indicator to do this (and initializing the Seed to 0).
However, there was a problem with one of the benchmarks that was
specifically setting the seed to 0 and getting unexpected results.
Fix the problem by adding a separate, hidden member of the PerlinNoise
class that keeps track of whether to generate new seeds or not.
aa7b83bb2 Handle random seed generation better for PerlinNoise
84bc72312 Make source parameters more clear
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Li-Ta Lo <ollie@lanl.gov>
Merge-request: !2933
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`).
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.
This method is principally obsolete and should have been removed when
coordinate systems were converted into fields. I noticed it was still
there when updating the documentation.
This removal required some changes to the CleanGrid filter, but this
actually simplified the code.
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.
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.)
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.
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.
The name of the methods were changed from `AddGhostCellField` to
`SetGhostCellField` since only one field can be marked as the cell
ghost. Also automatically select a field that matches
`GetGlobalCellFieldName` if nothing else is set.
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.
54f0ef2a8 Support providing a Token to ReadPortal and WritePortal
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Li-Ta Lo <ollie@lanl.gov>
Merge-request: !2916
63702d5d1 Check to make sure that the fields in a DataSet are the proper length
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Li-Ta Lo <ollie@lanl.gov>
Merge-request: !2914
aa5687512 Correct the number of points in `SplitSharpEdges` filter
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Abhishek Yenpure <abhi.yenpure@kitware.com>
Merge-request: !2912
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.
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.
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.
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.
The cell set created in the `SplitSharpEdges` filter had the number of
points of the input, not the output. This inconsistency became worse now
that `DataSet` is doing more to check the consistency of point and cell
field lengths.
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.)
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.
Several revisions ago, the ability to use virtual methods in the
execution environment was deprecated. Completely remove this
functionality for the VTK-m 2.0 release.
`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.
When the configure modules were first created, there were some hacks
around filters that had not yet moved to the new filter mechanism. These
can (and should) be removed.
This mechanism sets up CMake variables that allow a user to select which
modules/libraries to create. Dependencies will be tracked down to ensure
that all of a module's dependencies are also enabled.
The modules are also arranged into groups.
Groups allow you to set the enable flag for a group of modules at once.
Thus, if you have several modules that are likely to be used together,
you can create a group for them.
This can be handy in converting user-friendly CMake options (such as
`VTKm_ENABLE_RENDERING`) to the modules that enable that by pointing to
the appropriate group.
When you used the `AddHelp` option to `Initialize`, it added a
`--vtkm-help` option and `-h`, but not `--help`, which was weird. It
also avoided adding `--vtkm-help` when `AddHelp` was not used, but did
print out a usage statement under other circumstances.
This changes the behavior to add `--vtkm-help`, `--help`, and `-h` when
`AddHelp` is on and only `--vtkm-help` when it is off.
This was causing an issue in VTK as the VTK specific typelist was not
being used. This resulted in a field's type being changed from `UInt8` to
`Float32` and caused a test to fail.
This commit reflects the changes of VTK-m API/ABI release plans in
which we attempt ABI compatibility in patch releases.
- It also sets the version/soname for diy thirdparty module lib
This has the side effect of initialing MPI_Init (and will also
call MPI_Finalize at program exit). However, if the calling
code has already called MPI_Init, then nothing will happen.
Thus, if the calling code wants to manage MPI_Init/Finalize,
it can do so as long as it does before it initializes VTK-m.
There was a bug with Flying Edges checking the boundary conditions in
the z-direction. It was comparing the z index to the size of the y
dimension, not the z dimension. This simple typo was probably missed
because most of the tests use square meshes. To catch the problem, you
need a mesh that has a different number of points in the y and z
directions and the contour has to go past the positive z boundary.
When this error was hit, the indices for the edges on that boundary were
not recorded, and later interpolation used garbage values for edge's
point ids.
e36d908a4 Remove use of deprecated features in TransferToOpenGL
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Vicente Bolea <vicente.bolea@kitware.com>
Merge-request: !2871
49dd19408 Do not overthink ComputeNumberOfBlocksPerAxis
e2968ca24 Revised ComputeNumberOfBlocksPerAxis inspired by Ken Moreland's suggestion
ede6bb001 Replace the way data is split in contour tree augmented example
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !2519
The `TransferToOpenGL` function was using a deprecated method to
determine on which device an `ArrayHandle` was installed. Update the
function to use the replacement methods.
The original versions of Lagrangian and LagrangianStructures mapped the
global fields from inputs to output. Restore that capability.
Also changed the output CoordinateSystem of Lagrangian to be uniform
points instead of rectilinear points. The points were uniformly spaced
anyway, so it is more clear to have uniform points in the coordinate
system.
1. Now we can threshold for values below or above a given value, instead
of just between two values.
2. Supports multi-component fields instead of just scalar fields.
3. The threshold criteria can be tested against just one specified
component or against all of the components, and pass if any or all of
the components pass.
4. The results of the threshold operation can be inverted.
There were several cases where parameters of basic types were declared
const-by-value, instead of just by-value which is the convention
followed in vtk-m.
There were also some cases where compound types were being declared
const-by-value instead of const-by-reference.
0fb721207 Kick the dashboard builds.
30d1d86a0 Method was deprecated during the rename within the MR. (Not a new method).
a215ac320 Use {} initialization of FieldCollection.
4b60978a0 Simplify implementation of CreateResult.
98994026b Change GetPartitionField to GetFieldFromPartition.
fbe78b45c Change all usage of IsField* to Is*Field.
e395fe8fe Rename methods for consistency.
019d6cbc6 fix build error due to typo.
...
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !2853
When the flow filters were converted to the new filter base classes, the
classes and headers were moved to a new namespace. Support backward
compatibility by adding deprecated versions of headers.
81b85e8ec Removing unnecessary includes
2004177db Making test data in control environment
606223edd Fixing choice of dataset integrator
2dc485ac2 Adding WarpX code path for steady state streamlines
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !2848
Adding updates
Adding WarpX data and unit test
Fixing code from feedback
Fixing code from Ollie and Dave's feedback
Reducing WarpX dataset size
Fixing high precision requirement to store properties
Fixing Particle Sizeof
Fixing high precision requirement to store properties
fixing code from Ollie and Dave's feedback
Trying test
Fixing ChargedParticle serailization for MPI
770fa2964 Reset flag to previous value on exit.
dd16f738e remove example from cmake..
38714972a remove example for threaded multiblocks.
fc8b750e5 Fix type Set --> Get for CPU/GPU threads.
115db2175 fix compile error for cuda.
baac7e1fb Put sync memory into RuntimeDeviceTracker
8455972a0 Turn on thread-safe-ish mem alloc
9f4b786a7 Add option to thread-efficient mem alloc
...
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !2845
This header is now considered an internal header, and the latest
release commit of Kokkos does not allow you to include it. The
header gets included anyway with Kokkos_Core.hpp, so we can safely
just delete it.
See https://github.com/kokkos/kokkos/pull/5178
The `Variant` class was missing a way to check the type. You could do it
indirectly using `variant.GetIndex() == variant.GetIndexOf<T>()`, but
having this convenience function is more clear.
Rather than try to collect all `LastCell` types inside of a single
header and make an uber type, have each cell locator define its own cell
locator type and use that.
The `Variant` class was missing a way to check the type. You could do it
indirectly using `variant.GetIndex() == variant.GetIndexOf<T>()`, but
having this convenience function is more clear.
25c622508 Use ScatterCounting instead of ScatterPermutation.
8cf0c1a7f Merge branch 'master' of https://gitlab.kitware.com/vtk/vtk-m into tube_fix_degenerate_polylines
531c3a442 Merge branch 'master' of https://gitlab.kitware.com/vtk/vtk-m into tube_fix_degenerate_polylines
a2d5f5249 kick dashboard...
6353da486 minor edit to kick dashboards.
deb15bc14 small edit to kick dashboards.
2bfd0ce59 Use ScatterPermutation to skip invalid cells.
8e44a7ce0 Merge branch 'master' of https://gitlab.kitware.com/vtk/vtk-m
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !2821
This is an addition to commit e312c5435651f326f530a976d3faf3752350911e,
which corrects type comparison on OSX for typeids created in different
translation units. That missed the type correction for the
`BaseComponentType` of `UnknownArrayHandle`.
d1d97ec05 make NewFilterParticleAdvection::GetResultType pure
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Dave Pugmire <dpugmire@gmail.com>
Merge-request: !2832
This commit address issue #713 and removes the need to pass information
about the spatial decomposition (block origins, block sizes, block index
and blocks per dimension) to the contour tree filter. Block origin
information is added to CellSetStructured (as GlobalPointSize) and the
distributed contour tree filter will get this information from
CellSetStructured instead of expecting it as parameters to the
constructor. Information about blocks per dimension and block indices
are computed from the information in CellSetStructure albeit requiring
global communication across all ranks. To avoid this communication cost,
the caller of the filter may explicitly specify this information via the
SetBlockIndices() method.
898a3e092 Move StreamSurface into NewFilterField
5ffae6111 Use CastAndCallForTypes with UnknownArray of seeds.
061fe6afb Fix dashboard compile errors.
42fd70d50 Remove virtuals from DataSetIntegrator classes.
2524c16a0 Missed some cuda fixes filters...
e1fbfea30 Remove device compiler dependencies.
2a4430447 tests need to be device compiled.
9b2a257d9 Move include out of .h file.
...
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !2777
c41c3b7a5 Fix Variant::CastAndCall SFINAE for auto return type functors
3ec9fc858 Fix issue with Variant::CastAndCall with non-const reference
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !2824
`Variant::CastAndCall` was using the C++11 style for an `auto` return
where the return type was specified with a `->` that got the `decltype`
of the return value of the functor. This was used as part of SFINAE to
pick whether you needed the const or non-const version.
However, this was causing a problem with functions that got an error
when deducing the return type for that. This was particularly
problematic for lambda functions. For example, say you have the
following simple `CastAndCall`.
```cpp
variant.CastAndCall([](auto& x){ ++x; });
```
To determine the return type of the lambda (`void`), the function has to
be compiled. But when it is compiled with a const type, which happens
when deducing the const version of `CastAndCall`, you get a compile
error. This error is not considered a substitution error (hence SFINAE),
it is an outright error. So you get a compile error just trying to
deduce the type.
The solution was to move to the C++14 version of an auto return type. In
this case, the return type is no longer important for SFINAE and is
delayed until the function is actually compiled with the specific
template parameters. This would be a problem if the const version of
`CastAndCall` was used when the non-const version was needed. But now
both versions will pass SFINAE and thus the non-const version will be
chosen as long as the `Variant` object itself is non-const. If the
`Variant` object itself is const, then that is in fact a legitimate
error, so a compile error is OK.
One thing I find wierd is that `CastAndCall` still has a `noexcept`
expression that will likewise cause a compile error in this case.
However, it is still working. I _think_ the difference is that
`noexcept` is not used to determine template substitution/overloaded, so
is therefore ignored until the function is actually compiled.
AddGhostCellField function for Dataset class
setGhostCellName function for GhostCellClassify class
setGhostCellName function for GhostCellClassify class
added default ghost cell name in Dataset class
Default ghost cell field name defined in GhostCellClassify class
Default ghost cell field name for GhostCellClassify class
Unit test for ghost field name check
Unit test for ghost field name check updated
Default ghost field name updated
Get function for GhostCellClassify and default ghost name
UnitTestStreamlineFilter updated with AddGhostCellField
AddGhostCellField and GetGlobalGhostCellFieldName propagated
GhostCellClassify constructor now defined in header file
Assigned default values to dataset class members GhostSet and GhostCellName
default values set for GhostSet and GhostCellName in dataset constructor
Constructor removed from dataset class and noexcept for GetGlobalGhostName
added Dataset constructor with noexcept
additions to make sure default move constructor has not changed
GhostSetName field made as a shared pointer since string class is not noexcept
AddGhostCellField funtion added without field name
hasGhostCellField added and unit tests updated for addGhostCellField
hasGhostCellField added and unit tests updated for addGhostCellField
GetGhostCellField and GetGhostCellFieldName functions added to Dataset
GetGhostCellField and GetGhostCellFieldName functions added to Dataset
debugging UnitTestCellLocatorGerneral for CUDA error
UnitTestCellLocatorGeneral testing for error
UnitTestCellLocatorGeneral testing for cude error
UnitTestCellLocatorGeneral error resolution
UnitTestCellLocatorGeneral error resolution
UnitTestCellLocatorGeneral error resolution print statement removed
Minor updates to Dataset class files
GlobalGhostCellFieldName implementation revised to return a static variable
GhostSet member removed, hasGhostCellField, constructor, copystructure updated
GetGhostCellField and GetGhostCellFieldName made cosistent with GetField
Fixes to a few function calls
When the `Probe` filter was moved to the new filter superclasses, there
were some mistakes in the deprecated header. First, the pathname in an
include was incorrect. Second, the header guard for the moved header was
not updated to be unique from the deprecated header.
There was a typo in the declaration of the `CastAndCall` for a non-const
`Variant`. When determining the `noexcept` status of the function being
called, it was passing in a const reference instead of a regular
reference, which is what is actually passed to the function. This
potentially causes the function call to not match and fail to compile.
