Previously, the VTK file readers just skipped over everything in FIELD
sections. However, it is common for many point and cell fields to be
written in this section (it is how ParaView writes out most of its
data). This change will allow these fields to be read in correctly.
Previously, if a legacy VTK file had a METADATA section with an
INFORMATION subsection, the reader did not skip over it correctly.
Instead, it just read the rest of the file (and often encountered an
error). Change this to read and skip over the INFORMATION subsection
correctly.
The primary (likely only) use of PointTransform is to perform affine
transform on the position of the mesh. However, PointTransform did not
actually move the mesh. Rather, it just created a new field with the
transformed points.
Now, the output has its coordinate system replaced with the transformed
one generated (in addition to be added as a field). This can be turned
off (but defaults to on).
Also changed the constructor to turn on UseCoordinateSystemAsField so
that by default the filter operates on the existing coordinate system
and replaces it with the new coordinate system.
Also removed the template parameter on the filter. That added an
unnecessary complication to using it.
884616788 Simplify and extend AtomicArray implementation.
9560c4f63 Limit testing dispatch of atomic array to only atomic types.
0e728c800 Update atomic interfaces to support Add/CAS for UInt32/64.
720b452eb Force AtomicArray to use only basic storage arrays.
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Robert Maynard <robert.maynard@kitware.com>
Merge-request: !1802
- Use AtomicInterface to implement device-specific atomic operations.
- Remove DeviceAdapterAtomicArrayImplementations.
- Extend supported atomic types to include unsigned 32/64-bit ints.
- Add a static_assert to check that AtomicArray type is supported.
- Add documentation for AtomicArrayExecutionObject, including a CAS
example.
- Add a `T Get(idx)` method to AtomicArrayExecutionObject that does
an atomic load, and update existing CAS usage to use this instead
of `Add(idx, 0)`.
3eb91af96 Use ArrayGetValue where possible in worklets.
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Robert Maynard <robert.maynard@kitware.com>
Merge-request: !1799
Replace code such as `myArray.GetPortalControl().Get(0)` with
`vtkm::cont::ArrayGetValue(0, myArray)`, which will just retrieve
the single value without transferring the entire contents of
`myArray` to the host. This should prevent memory thrashing.
Also did some general style clean-ups and fixed loops that called
`GetPortalControl` in the loop body.
709b12c5b Add checks for size of contour worklet outputs
a3131d4e1 Fix bad normals in contour test
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Li-Ta Lo <ollie@lanl.gov>
Merge-request: !1794
This allows for developers to do things such as the following
as constexpr's:
```cxx
constexpr vtkm::Id2 dims(16,16);
constexpr vtkm::Float64 dx = vtkm::Float64(4.0 * vtkm::Pi()) / vtkm::Float64(dims[0] - 1);
```
bf96d921d Add extra braces around std::array initializers
9bbf4a5a6 Corrections and expanded testing of implicit functions
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Sujin Philip <sujin.philip@kitware.com>
Merge-request: !1776
The contour worklet test was experiencing normals that were set to NaN
due to problems with computing the gradient of the original field. It
was determined that the problem was caused by the clip filter creating
degenerate cells because the clip plane exactly intersected the points
of the mesh. Although a problem, we found that this behavior also exists
in existing tools like ParaView and VisIt. Thus, it sounds like a
problem to be pushed off to a later day. Instead, just move the plane a
little bit to get it into general position.
Now that Threshold automatically converts its output to CellSetExplicit,
this option is no longer necessary (and the previous implementation did
not work correctly).
aebafc9e5 Use SFINAE to write Set/Get methods in ArrayPortalSOA
20c758108 Add make_ArrayHandleSOA for std::vectors and C arrays
c50857246 Make SOA Portal test more type safe
918766e7a Fix VS 2015 compile issue with HasVecTraits
869d66580 Add ArrayHandleSOA
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Allison Vacanti <allison.vacanti@kitware.com>
Merge-request: !1758
Perhaps a better title for this change would be "Make the Threshold
filter not totally useless."
A long standing issue with the Threshold filter is that its output
CellSet was stored in a CellSetPermutation. This made Threshold hyper-
efficient because it required hardly any data movement to implement.
However, the problem was that any other unit that had to use the CellSet
failed. To have VTK-m handle that output correctly in other filters and
writers, they all would have to check for the existance of
CellSetPermutation. And CellSetPermutation is templated on the CellSet
type it is permuting, so all units would have to compile special cases
for all these combinations. This is not likely to be feasible in any
static solution.
The simple solution, implemented here, is to deep copy the cells to a
CellSetExplicit, which is a known type that is already used everywhere
in VTK-m. The solution is a bit disappointing since it requires more
memory and time to build. But it is on par with solutions in other
libraries (like VTK). And it really does not matter how efficient the
old solution was if it was useless.
Because ArrayPortalSOA calls a delegate portal to get the actual values,
it can only implement its own Set or Get if the delegate portal supports
it. Previously this was done by calling an overloaded internal method
based on the result of PortalSupportsSets/Gets. However, regardless of
whether the delegate portal supported Set or Get, ArrayPortalSOA
provided one. Thus, if something else tried to use PortalSupportsSets/
Gets on ArrayPortalSOA, it would always report true even if it was not
really supported.
Instead, use SFINAE to remove the Set or Get if that method is not
supported in the delegate portal.
Since ArrayHandleSOA is only really used for portals from basic storage
arrays, it will be rare that Set or Get is not supported. However, a
device adapter is free to remove one of these methods on a device
portal. For example, if you call PrepareForInput on an ArrayHandle, it
is possible that the device adapter will create a portal that has no Set
method because the array is not writable.
Thanks to Allison Vacanti for recomending this solution.
I kept getting warnings from different compilers about type conversions
because I was making values by adding an index to them. Change how we
create and test values so that these type issues are less likely to come
up.
Apparently, the Visual Studio 2015 has a bug where the result of a
decltype might not be considered a type. Attempt to get around this
problem by putting the decltype inside of a struct and then have the
using statement use the typename keyword. Hopefully if you literally say
that something is a typename, the compiler will treat it like a type
name.
The gradient is malformed at the apex of a pyramid. To get around this,
steal a trick from the VTK source where in this case interpolate some
values a little bit into the interior of the cell.
Also expand the gradient worklet tests to include all cell types.
This appears to be a bug in older clang and gcc compilers where they
gave a warning asking for an extra unnecessary set of braces around the
initializer of std::array. See for example
https://bugs.llvm.org/show_bug.cgi?id=21629https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25137
I don't think newer compilers give this warning, but we still support
some older compilers it happens on, so we live with it.
To help provide a better time writing VTK-m filter this streamlines
the CreateResult API to provide a focused set of methods, based on
how CreateResult has been used by existing filters.
TypeListTagAll only defines vectors up to size 4, while the default
filter traits do not restrict input types at all.
Since the moments computation may use 6- or 9-tuple vecs, this
restriction is breaking those usecases.
b3df7da22 Allow external cellsets to be used by TriangleWinding worklet.
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Robert Maynard <robert.maynard@kitware.com>
Merge-request: !1765
3a7d3cb5f VTK-m filters now launch all worklets via a vtkm::cont::Invoker
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Kenneth Moreland <kmorel@sandia.gov>
Merge-request: !1760
bf6d6cc60 Get around alignas bug in GCC 4.8
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Robert Maynard <robert.maynard@kitware.com>
Merge-request: !1761
I ran into a bug with GCC 4.8 where if you use the alignas keyword
with a number declared with a constexpr, it gives an error about
the expression not being a constant expression (even though it
is). A workaround to the issue is to wrap the alianas in a class
templated by the size you want to align with. GCC does not
complain when you use a constexpr with a template parameter, and
it is happy to use that template parameter in the alignas
expression.
Workaround found here:
https://stackoverflow.com/questions/29879609/g-complains-constexpr-function-is-not-a-constant-expression
For demonstration purposes, I added a vector field to one of the data
sets (the cow nose). However, the serialization test was not expecting a
field of that type and therefore had not compiled the case to serialize
that type of field, which caused a failure. Fixed the problem by
instructing the test to also consider the correct type of vector fields.
d7b2ff04c Provide a simpler way to restrict value types for filters
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Kenneth Moreland <kmorel@sandia.gov>
Acked-by: Allison Vacanti <allison.vacanti@kitware.com>
Merge-request: !1755
The `From` and `To` nomenclature for topology mapping has been confusing for
both users and developers, especially at lower levels where the intention of
mapping attributes from one element to another is easily conflated with the
concept of mapping indices (which maps in the exact opposite direction).
These identifiers have been renamed to `VisitTopology` and `IncidentTopology`
to clarify the direction of the mapping. The order in which these template
parameters are specified for `WorkletMapTopology` have also been reversed,
since eventually there may be more than one `IncidentTopology`, and having
`IncidentTopology` at the end will allow us to replace it with a variadic
template parameter pack in the future.
Other implementation details supporting these worklets, include `Fetch` tags,
`Connectivity` classes, and methods on the various `CellSet` classes (such as
`PrepareForInput` have also reversed their template arguments. These will need
to be cautiously updated.
The convenience implementations of `WorkletMapTopology` have been renamed for
clarity as follows:
```
WorkletMapPointToCell --> WorkletVisitCellsWithPoints
WorkletMapCellToPoint --> WorkletVisitPointsWithCells
```
The `ControlSignature` tags have been renamed as follows:
```
FieldInTo --> FieldInVisit
FieldInFrom --> FieldInMap
FromCount --> IncidentElementCount
FromIndices --> IncidentElementIndices
```
This is done to avoid warnings when compiling VTK-m consumers
with different defaults for symbol visiblity. AKA avoid warnings
like:
```
warning: ‘vtkm::worklet::WorkletMapField’ declared with greater visibility than the type of its field ‘vtkm::worklet::WorkletMapField::<anonymous>’ [-Wattributes]
class WorkletMapField : public vtkm::worklet::internal::WorkletBase
^~~~~~~~~~~~~~~
```
The Invoker is a control side object that handles the construction
of the relevant worklet dispatcher. Moving it to control makes it
obvious that it isn't an algorithm itself but a way to launch
worklets.
53e868938 Add changedoc for common vec types
0be50c119 Update VTK-m code to use new Vec aliases
b3e295214 Add aliases for common Vec types
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !1743