Shuenhoy/vtk-m2
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
30967f9585
vtk-m2/vtkm/cont/testing/TestingComputeRange.h

165 lines
5.9 KiB
C
Raw Normal View History

Add compute bounds to Fields
2015-07-16 19:10:01 +00:00
//============================================================================
// Copyright (c) Kitware, Inc.
// All rights reserved.
// See LICENSE.txt for details.
conslidate the license statement
2019-04-15 23:24:21 +00:00
//
Add compute bounds to Fields
2015-07-16 19:10:01 +00:00
// This software is distributed WITHOUT ANY WARRANTY; without even
// the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR
// PURPOSE. See the above copyright notice for more information.
//============================================================================
Change Field and related methods to use Range and Bounds First, be more explicit when we mean a range of values in a field or a spacial bounds. Use the Range and Bounds structs in Field and CoordinateSystem to make all of this more clear (and reduce a bit of code as well).
2016-05-26 22:02:30 +00:00
#ifndef vtk_m_cont_testing_TestingComputeRange_h
#define vtk_m_cont_testing_TestingComputeRange_h
Add compute bounds to Fields
2015-07-16 19:10:01 +00:00
#include <vtkm/Types.h>
CoordinateSystem handles uniform point coordinates. The point of making CoordinateSystem a special type of Field object was so that it could handle special array types like implicit regular point coordinates. Overload the GetData and GetBounds methods to properly handle this type of array.
2015-08-19 04:56:10 +00:00
#include <vtkm/cont/CoordinateSystem.h>
Add compute bounds to Fields
2015-07-16 19:10:01 +00:00
#include <vtkm/cont/Field.h>
Add Field::GetRange and CoordinateSystem::GetBounds to library Following what was done with ArrayRangeCompute, the GetRange and GetBounds methods are embedded into the vtkm_cont library for the most common type lists. Also, and probably more importantly, the device adapter is no longer one of the arguments for either of these methods. It is no longer needed as ArrayRangeCompute no longer needs it.
2017-02-24 21:39:37 +00:00
#include <vtkm/cont/RuntimeDeviceTracker.h>
Add compute bounds to Fields
2015-07-16 19:10:01 +00:00
#include <vtkm/cont/testing/Testing.h>
Update vtkm/cont/testing to work with ArrayHandleVariant
2018-11-08 15:37:50 +00:00
// Required for implementation of ArrayRangeCompute for virtual arrays
Deprecate templated versions of Field::GetRange Instead, always use precompiled versions of range computing. This means you won't be able to specify the type. Currently, types are limited to scalars vecs up to size 4. The main motivation for this change is to allow you to include Field.h with a non-device compiler. This is an important feature for our customers. I plan in the future to implement a mechanism to pull out a component of most ArrayHandle's as a single array. This would enable us to support a precompiled version that can compute the range of arbitrarily sized Vecs.
2020-10-20 19:22:43 +00:00
#include <vtkm/cont/ArrayRangeComputeTemplate.h>
Add compute bounds to Fields
2015-07-16 19:10:01 +00:00
#include <algorithm>
#include <iostream>
Replace std::random_shuffle with std::shuffle std::random_shuffle is deprecated in C++14 because it's using std::rand which uses a non uniform distribution and the underlying algorithm is unspecified. Using std::shuffle can provide a reliable result in a 64 bit version.
2018-08-02 16:15:04 +00:00
#include <random>
Add compute bounds to Fields
2015-07-16 19:10:01 +00:00
clang-format: apply to the entire tree
2017-05-18 14:29:41 +00:00
namespace vtkm
{
namespace cont
{
namespace testing
{
Convert uses of ListTagBase to List
2019-12-05 21:38:41 +00:00
using CustomTypeList = vtkm::List<vtkm::Vec<Int32, 3>,
vtkm::Vec<Int64, 3>,
vtkm::Vec<Float32, 3>,
vtkm::Vec<Float64, 3>,
vtkm::Vec<Int32, 9>,
vtkm::Vec<Int64, 9>,
vtkm::Vec<Float32, 9>,
vtkm::Vec<Float64, 9>>;
clang-format: apply to the entire tree
2017-05-18 14:29:41 +00:00
template <typename DeviceAdapterTag>
Change Field and related methods to use Range and Bounds First, be more explicit when we mean a range of values in a field or a spacial bounds. Use the Range and Bounds structs in Field and CoordinateSystem to make all of this more clear (and reduce a bit of code as well).
2016-05-26 22:02:30 +00:00
class TestingComputeRange
Add compute bounds to Fields
2015-07-16 19:10:01 +00:00
{
private:
template <typename T>
static void TestScalarField()
{
const vtkm::Id nvals = 11;
T data[nvals] = { 1, 2, 3, 4, 5, -5, -4, -3, -2, -1, 0 };
Replace std::random_shuffle with std::shuffle std::random_shuffle is deprecated in C++14 because it's using std::rand which uses a non uniform distribution and the underlying algorithm is unspecified. Using std::shuffle can provide a reliable result in a 64 bit version.
2018-08-02 16:15:04 +00:00
std::random_device rng;
std::mt19937 urng(rng());
std::shuffle(data, data + nvals, urng);
Improvements to moving data into ArrayHandle We have made several improvements to adding data into an `ArrayHandle`. ## Moving data from an `std::vector` For numerous reasons, it is convenient to define data in a `std::vector` and then wrap that into an `ArrayHandle`. It is often the case that an `std::vector` is filled and then becomes unused once it is converted to an `ArrayHandle`. In this case, what we really want is to pass the data off to the `ArrayHandle` so that the `ArrayHandle` is now managing the data and not the `std::vector`. C++11 has a mechanism to do this: move semantics. You can now pass variables to functions as an "rvalue" (right-hand value). When something is passed as an rvalue, it can pull state out of that variable and move it somewhere else. `std::vector` implements this movement so that an rvalue can be moved to another `std::vector` without actually copying the data. `make_ArrayHandle` now also takes advantage of this feature to move rvalue `std::vector`s. There is a special form of `make_ArrayHandle` named `make_ArrayHandleMove` that takes an rvalue. There is also a special overload of `make_ArrayHandle` itself that handles an rvalue `vector`. (However, using the explicit move version is better if you want to make sure the data is actually moved.) ## Make `ArrayHandle` from initalizer list A common use case for using `std::vector` (particularly in our unit tests) is to quickly add an initalizer list into an `ArrayHandle`. Now you can by simply passing an initializer list to `make_ArrayHandle`. ## Deprecated `make_ArrayHandle` with default shallow copy For historical reasons, passing an `std::vector` or a pointer to `make_ArrayHandle` does a shallow copy (i.e. `CopyFlag` defaults to `Off`). Although more efficient, this mode is inherintly unsafe, and making it the default is asking for trouble. To combat this, calling `make_ArrayHandle` without a copy flag is deprecated. In this way, if you wish to do the faster but more unsafe creation of an `ArrayHandle` you should explicitly express that. This requried quite a few changes through the VTK-m source (particularly in the tests). ## Similar changes to `Field` `vtkm::cont::Field` has a `make_Field` helper function that is similar to `make_ArrayHandle`. It also features the ability to create fields from `std::vector`s and C arrays. It also likewise had the same unsafe behavior by default of not copying from the source of the arrays. That behavior has similarly been depreciated. You now have to specify a copy flag. The ability to construct a `Field` from an initializer list of values has also been added.
2020-07-16 16:32:32 +00:00
auto field = vtkm::cont::make_Field(
"TestField", vtkm::cont::Field::Association::POINTS, data, nvals, vtkm::CopyFlag::Off);
Add compute bounds to Fields
2015-07-16 19:10:01 +00:00
Change Field and related methods to use Range and Bounds First, be more explicit when we mean a range of values in a field or a spacial bounds. Use the Range and Bounds structs in Field and CoordinateSystem to make all of this more clear (and reduce a bit of code as well).
2016-05-26 22:02:30 +00:00
vtkm::Range result;
Add Field::GetRange and CoordinateSystem::GetBounds to library Following what was done with ArrayRangeCompute, the GetRange and GetBounds methods are embedded into the vtkm_cont library for the most common type lists. Also, and probably more importantly, the device adapter is no longer one of the arguments for either of these methods. It is no longer needed as ArrayRangeCompute no longer needs it.
2017-02-24 21:39:37 +00:00
field.GetRange(&result);
Add compute bounds to Fields
2015-07-16 19:10:01 +00:00
Change Field and related methods to use Range and Bounds First, be more explicit when we mean a range of values in a field or a spacial bounds. Use the Range and Bounds structs in Field and CoordinateSystem to make all of this more clear (and reduce a bit of code as well).
2016-05-26 22:02:30 +00:00
std::cout << result << std::endl;
clang-format: apply to the entire tree
2017-05-18 14:29:41 +00:00
VTKM_TEST_ASSERT((test_equal(result.Min, -5.0) && test_equal(result.Max, 5.0)),
"Unexpected scalar field range.");
Add compute bounds to Fields
2015-07-16 19:10:01 +00:00
}
Correct a bad memcpy in ColorTable that gcc 7 found
2018-05-01 21:35:26 +00:00
template <typename T, vtkm::IdComponent NumberOfComponents>
Add compute bounds to Fields
2015-07-16 19:10:01 +00:00
static void TestVecField()
{
const vtkm::Id nvals = 11;
T data[nvals] = { 1, 2, 3, 4, 5, -5, -4, -3, -2, -1, 0 };
vtkm::Vec<T, NumberOfComponents> fieldData[nvals];
Replace std::random_shuffle with std::shuffle std::random_shuffle is deprecated in C++14 because it's using std::rand which uses a non uniform distribution and the underlying algorithm is unspecified. Using std::shuffle can provide a reliable result in a 64 bit version.
2018-08-02 16:15:04 +00:00
std::random_device rng;
std::mt19937 urng(rng());
Correct some warnings about 64bit to 32bit conversion.
2015-07-23 13:06:20 +00:00
for (vtkm::IdComponent i = 0; i < NumberOfComponents; ++i)
Add compute bounds to Fields
2015-07-16 19:10:01 +00:00
{
Replace std::random_shuffle with std::shuffle std::random_shuffle is deprecated in C++14 because it's using std::rand which uses a non uniform distribution and the underlying algorithm is unspecified. Using std::shuffle can provide a reliable result in a 64 bit version.
2018-08-02 16:15:04 +00:00
std::shuffle(data, data + nvals, urng);
Add compute bounds to Fields
2015-07-16 19:10:01 +00:00
for (vtkm::Id j = 0; j < nvals; ++j)
{
fieldData[j][i] = data[j];
}
}
Improvements to moving data into ArrayHandle We have made several improvements to adding data into an `ArrayHandle`. ## Moving data from an `std::vector` For numerous reasons, it is convenient to define data in a `std::vector` and then wrap that into an `ArrayHandle`. It is often the case that an `std::vector` is filled and then becomes unused once it is converted to an `ArrayHandle`. In this case, what we really want is to pass the data off to the `ArrayHandle` so that the `ArrayHandle` is now managing the data and not the `std::vector`. C++11 has a mechanism to do this: move semantics. You can now pass variables to functions as an "rvalue" (right-hand value). When something is passed as an rvalue, it can pull state out of that variable and move it somewhere else. `std::vector` implements this movement so that an rvalue can be moved to another `std::vector` without actually copying the data. `make_ArrayHandle` now also takes advantage of this feature to move rvalue `std::vector`s. There is a special form of `make_ArrayHandle` named `make_ArrayHandleMove` that takes an rvalue. There is also a special overload of `make_ArrayHandle` itself that handles an rvalue `vector`. (However, using the explicit move version is better if you want to make sure the data is actually moved.) ## Make `ArrayHandle` from initalizer list A common use case for using `std::vector` (particularly in our unit tests) is to quickly add an initalizer list into an `ArrayHandle`. Now you can by simply passing an initializer list to `make_ArrayHandle`. ## Deprecated `make_ArrayHandle` with default shallow copy For historical reasons, passing an `std::vector` or a pointer to `make_ArrayHandle` does a shallow copy (i.e. `CopyFlag` defaults to `Off`). Although more efficient, this mode is inherintly unsafe, and making it the default is asking for trouble. To combat this, calling `make_ArrayHandle` without a copy flag is deprecated. In this way, if you wish to do the faster but more unsafe creation of an `ArrayHandle` you should explicitly express that. This requried quite a few changes through the VTK-m source (particularly in the tests). ## Similar changes to `Field` `vtkm::cont::Field` has a `make_Field` helper function that is similar to `make_ArrayHandle`. It also features the ability to create fields from `std::vector`s and C arrays. It also likewise had the same unsafe behavior by default of not copying from the source of the arrays. That behavior has similarly been depreciated. You now have to specify a copy flag. The ability to construct a `Field` from an initializer list of values has also been added.
2020-07-16 16:32:32 +00:00
auto field = vtkm::cont::make_Field(
"TestField", vtkm::cont::Field::Association::POINTS, fieldData, nvals, vtkm::CopyFlag::Off);
Add compute bounds to Fields
2015-07-16 19:10:01 +00:00
Change Field and related methods to use Range and Bounds First, be more explicit when we mean a range of values in a field or a spacial bounds. Use the Range and Bounds structs in Field and CoordinateSystem to make all of this more clear (and reduce a bit of code as well).
2016-05-26 22:02:30 +00:00
vtkm::Range result[NumberOfComponents];
Deprecate templated versions of Field::GetRange Instead, always use precompiled versions of range computing. This means you won't be able to specify the type. Currently, types are limited to scalars vecs up to size 4. The main motivation for this change is to allow you to include Field.h with a non-device compiler. This is an important feature for our customers. I plan in the future to implement a mechanism to pull out a component of most ArrayHandle's as a single array. This would enable us to support a precompiled version that can compute the range of arbitrarily sized Vecs.
2020-10-20 19:22:43 +00:00
field.GetRange(result);
Add compute bounds to Fields
2015-07-16 19:10:01 +00:00
Correct some warnings about 64bit to 32bit conversion.
2015-07-23 13:06:20 +00:00
for (vtkm::IdComponent i = 0; i < NumberOfComponents; ++i)
Add compute bounds to Fields
2015-07-16 19:10:01 +00:00
{
clang-format: apply to the entire tree
2017-05-18 14:29:41 +00:00
VTKM_TEST_ASSERT((test_equal(result[i].Min, -5.0) && test_equal(result[i].Max, 5.0)),
"Unexpected vector field range.");
Add compute bounds to Fields
2015-07-16 19:10:01 +00:00
}
}
CoordinateSystem handles uniform point coordinates. The point of making CoordinateSystem a special type of Field object was so that it could handle special array types like implicit regular point coordinates. Overload the GetData and GetBounds methods to properly handle this type of array.
2015-08-19 04:56:10 +00:00
static void TestUniformCoordinateField()
{
Respect VTK-m convention of parameters all or nothing on a line clang-format BinPack settings have been disabled to make sure that the VTK-m style guideline is obeyed.
2017-05-26 17:53:28 +00:00
vtkm::cont::CoordinateSystem field("TestField",
vtkm::Id3(10, 20, 5),
Update VTK-m code to use new Vec aliases Should make the code easier to read.
2019-07-31 16:20:38 +00:00
vtkm::Vec3f(0.0f, -5.0f, 4.0f),
vtkm::Vec3f(1.0f, 0.5f, 2.0f));
CoordinateSystem handles uniform point coordinates. The point of making CoordinateSystem a special type of Field object was so that it could handle special array types like implicit regular point coordinates. Overload the GetData and GetBounds methods to properly handle this type of array.
2015-08-19 04:56:10 +00:00
Add Field::GetRange and CoordinateSystem::GetBounds to library Following what was done with ArrayRangeCompute, the GetRange and GetBounds methods are embedded into the vtkm_cont library for the most common type lists. Also, and probably more importantly, the device adapter is no longer one of the arguments for either of these methods. It is no longer needed as ArrayRangeCompute no longer needs it.
2017-02-24 21:39:37 +00:00
vtkm::Bounds result = field.GetBounds();
CoordinateSystem handles uniform point coordinates. The point of making CoordinateSystem a special type of Field object was so that it could handle special array types like implicit regular point coordinates. Overload the GetData and GetBounds methods to properly handle this type of array.
2015-08-19 04:56:10 +00:00
Change Field and related methods to use Range and Bounds First, be more explicit when we mean a range of values in a field or a spacial bounds. Use the Range and Bounds structs in Field and CoordinateSystem to make all of this more clear (and reduce a bit of code as well).
2016-05-26 22:02:30 +00:00
VTKM_TEST_ASSERT(test_equal(result.X.Min, 0.0), "Min x wrong.");
VTKM_TEST_ASSERT(test_equal(result.X.Max, 9.0), "Max x wrong.");
VTKM_TEST_ASSERT(test_equal(result.Y.Min, -5.0), "Min y wrong.");
VTKM_TEST_ASSERT(test_equal(result.Y.Max, 4.5), "Max y wrong.");
VTKM_TEST_ASSERT(test_equal(result.Z.Min, 4.0), "Min z wrong.");
VTKM_TEST_ASSERT(test_equal(result.Z.Max, 12.0), "Max z wrong.");
CoordinateSystem handles uniform point coordinates. The point of making CoordinateSystem a special type of Field object was so that it could handle special array types like implicit regular point coordinates. Overload the GetData and GetBounds methods to properly handle this type of array.
2015-08-19 04:56:10 +00:00
}
Add compute bounds to Fields
2015-07-16 19:10:01 +00:00
struct TestAll
{
Remove exports for header-only functions/methods Change the VTKM_CONT_EXPORT to VTKM_CONT. (Likewise for EXEC and EXEC_CONT.) Remove the inline from these macros so that they can be applied to everything, including implementations in a library. Because inline is not declared in these modifies, you have to add the keyword to functions and methods where the implementation is not inlined in the class.
2016-10-19 22:42:58 +00:00
VTKM_CONT void operator()() const
Add compute bounds to Fields
2015-07-16 19:10:01 +00:00
{
std::cout << "Testing (Int32, 1)..." << std::endl;
Change Field and related methods to use Range and Bounds First, be more explicit when we mean a range of values in a field or a spacial bounds. Use the Range and Bounds structs in Field and CoordinateSystem to make all of this more clear (and reduce a bit of code as well).
2016-05-26 22:02:30 +00:00
TestingComputeRange::TestScalarField<vtkm::Int32>();
Add compute bounds to Fields
2015-07-16 19:10:01 +00:00
std::cout << "Testing (Int64, 1)..." << std::endl;
Change Field and related methods to use Range and Bounds First, be more explicit when we mean a range of values in a field or a spacial bounds. Use the Range and Bounds structs in Field and CoordinateSystem to make all of this more clear (and reduce a bit of code as well).
2016-05-26 22:02:30 +00:00
TestingComputeRange::TestScalarField<vtkm::Int64>();
Add compute bounds to Fields
2015-07-16 19:10:01 +00:00
std::cout << "Testing (Float32, 1)..." << std::endl;
Change Field and related methods to use Range and Bounds First, be more explicit when we mean a range of values in a field or a spacial bounds. Use the Range and Bounds structs in Field and CoordinateSystem to make all of this more clear (and reduce a bit of code as well).
2016-05-26 22:02:30 +00:00
TestingComputeRange::TestScalarField<vtkm::Float32>();
Add compute bounds to Fields
2015-07-16 19:10:01 +00:00
std::cout << "Testing (Float64, 1)..." << std::endl;
Change Field and related methods to use Range and Bounds First, be more explicit when we mean a range of values in a field or a spacial bounds. Use the Range and Bounds structs in Field and CoordinateSystem to make all of this more clear (and reduce a bit of code as well).
2016-05-26 22:02:30 +00:00
TestingComputeRange::TestScalarField<vtkm::Float64>();
Add compute bounds to Fields
2015-07-16 19:10:01 +00:00
std::cout << "Testing (Int32, 3)..." << std::endl;
Change Field and related methods to use Range and Bounds First, be more explicit when we mean a range of values in a field or a spacial bounds. Use the Range and Bounds structs in Field and CoordinateSystem to make all of this more clear (and reduce a bit of code as well).
2016-05-26 22:02:30 +00:00
TestingComputeRange::TestVecField<vtkm::Int32, 3>();
Add compute bounds to Fields
2015-07-16 19:10:01 +00:00
std::cout << "Testing (Int64, 3)..." << std::endl;
Change Field and related methods to use Range and Bounds First, be more explicit when we mean a range of values in a field or a spacial bounds. Use the Range and Bounds structs in Field and CoordinateSystem to make all of this more clear (and reduce a bit of code as well).
2016-05-26 22:02:30 +00:00
TestingComputeRange::TestVecField<vtkm::Int64, 3>();
Add compute bounds to Fields
2015-07-16 19:10:01 +00:00
std::cout << "Testing (Float32, 3)..." << std::endl;
Change Field and related methods to use Range and Bounds First, be more explicit when we mean a range of values in a field or a spacial bounds. Use the Range and Bounds structs in Field and CoordinateSystem to make all of this more clear (and reduce a bit of code as well).
2016-05-26 22:02:30 +00:00
TestingComputeRange::TestVecField<vtkm::Float32, 3>();
Add compute bounds to Fields
2015-07-16 19:10:01 +00:00
std::cout << "Testing (Float64, 3)..." << std::endl;
Change Field and related methods to use Range and Bounds First, be more explicit when we mean a range of values in a field or a spacial bounds. Use the Range and Bounds structs in Field and CoordinateSystem to make all of this more clear (and reduce a bit of code as well).
2016-05-26 22:02:30 +00:00
TestingComputeRange::TestVecField<vtkm::Float64, 3>();
Add compute bounds to Fields
2015-07-16 19:10:01 +00:00
Deprecate templated versions of Field::GetRange Instead, always use precompiled versions of range computing. This means you won't be able to specify the type. Currently, types are limited to scalars vecs up to size 4. The main motivation for this change is to allow you to include Field.h with a non-device compiler. This is an important feature for our customers. I plan in the future to implement a mechanism to pull out a component of most ArrayHandle's as a single array. This would enable us to support a precompiled version that can compute the range of arbitrarily sized Vecs.
2020-10-20 19:22:43 +00:00
// TODO: These tests are temporarily disabled because the existing version of
// Field::GetRange does not compute the ranges for vectors of size 9. However,
// issue #575 would fix this issue. This test should be renabled when that is
// implemented.
#if 0
Add compute bounds to Fields
2015-07-16 19:10:01 +00:00
std::cout << "Testing (Int32, 9)..." << std::endl;
Change Field and related methods to use Range and Bounds First, be more explicit when we mean a range of values in a field or a spacial bounds. Use the Range and Bounds structs in Field and CoordinateSystem to make all of this more clear (and reduce a bit of code as well).
2016-05-26 22:02:30 +00:00
TestingComputeRange::TestVecField<vtkm::Int32, 9>();
Add compute bounds to Fields
2015-07-16 19:10:01 +00:00
std::cout << "Testing (Int64, 9)..." << std::endl;
Change Field and related methods to use Range and Bounds First, be more explicit when we mean a range of values in a field or a spacial bounds. Use the Range and Bounds structs in Field and CoordinateSystem to make all of this more clear (and reduce a bit of code as well).
2016-05-26 22:02:30 +00:00
TestingComputeRange::TestVecField<vtkm::Int64, 9>();
Add compute bounds to Fields
2015-07-16 19:10:01 +00:00
std::cout << "Testing (Float32, 9)..." << std::endl;
Change Field and related methods to use Range and Bounds First, be more explicit when we mean a range of values in a field or a spacial bounds. Use the Range and Bounds structs in Field and CoordinateSystem to make all of this more clear (and reduce a bit of code as well).
2016-05-26 22:02:30 +00:00
TestingComputeRange::TestVecField<vtkm::Float32, 9>();
Add compute bounds to Fields
2015-07-16 19:10:01 +00:00
std::cout << "Testing (Float64, 9)..." << std::endl;
Change Field and related methods to use Range and Bounds First, be more explicit when we mean a range of values in a field or a spacial bounds. Use the Range and Bounds structs in Field and CoordinateSystem to make all of this more clear (and reduce a bit of code as well).
2016-05-26 22:02:30 +00:00
TestingComputeRange::TestVecField<vtkm::Float64, 9>();
Deprecate templated versions of Field::GetRange Instead, always use precompiled versions of range computing. This means you won't be able to specify the type. Currently, types are limited to scalars vecs up to size 4. The main motivation for this change is to allow you to include Field.h with a non-device compiler. This is an important feature for our customers. I plan in the future to implement a mechanism to pull out a component of most ArrayHandle's as a single array. This would enable us to support a precompiled version that can compute the range of arbitrarily sized Vecs.
2020-10-20 19:22:43 +00:00
#endif
CoordinateSystem handles uniform point coordinates. The point of making CoordinateSystem a special type of Field object was so that it could handle special array types like implicit regular point coordinates. Overload the GetData and GetBounds methods to properly handle this type of array.
2015-08-19 04:56:10 +00:00
std::cout << "Testing UniformPointCoords..." << std::endl;
Change Field and related methods to use Range and Bounds First, be more explicit when we mean a range of values in a field or a spacial bounds. Use the Range and Bounds structs in Field and CoordinateSystem to make all of this more clear (and reduce a bit of code as well).
2016-05-26 22:02:30 +00:00
TestingComputeRange::TestUniformCoordinateField();
Add compute bounds to Fields
2015-07-16 19:10:01 +00:00
}
};
public:
Testing run methods now take argc/argv to init logging/runtime device `vtkm::cont::testing` now initializes with logging enabled and support for device being passed on the command line, `vtkm::testing` only enables logging.
2019-01-01 22:19:02 +00:00
static VTKM_CONT int Run(int argc, char* argv[])
Add compute bounds to Fields
2015-07-16 19:10:01 +00:00
{
RuntimeDeviceTracker: Remove `Global` from names
2019-03-15 19:59:02 +00:00
vtkm::cont::GetRuntimeDeviceTracker().ForceDevice(DeviceAdapterTag());
Testing run methods now take argc/argv to init logging/runtime device `vtkm::cont::testing` now initializes with logging enabled and support for device being passed on the command line, `vtkm::testing` only enables logging.
2019-01-01 22:19:02 +00:00
return vtkm::cont::testing::Testing::Run(TestAll(), argc, argv);
Add compute bounds to Fields
2015-07-16 19:10:01 +00:00
}
};
}
}
} // namespace vtkm::cont::testing
Change Field and related methods to use Range and Bounds First, be more explicit when we mean a range of values in a field or a spacial bounds. Use the Range and Bounds structs in Field and CoordinateSystem to make all of this more clear (and reduce a bit of code as well).
2016-05-26 22:02:30 +00:00
#endif //vtk_m_cont_testing_TestingComputeRange_h
Reference in New Issue Copy Permalink