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).
ThreadIndicies constructor was templated on the invocation type, which created
thousand's of versions of that symbol which all had the same behavior. So now
remove that and move that logic into a Worklet function since it requires
the invocation info.
These asserts are consolidated into the unified Assert.h. Also made some
minor edits to add asserts where appropriate and a little bit of
reconfiguring as found.
85084f2c ScatterIdentity::GetVisitArray parameters are now named properly
86ecad65 ScatterIdentity::GetOutputToInputMap parameters are now named properly
40896e2b Allocate the scatter arrays to be proper length.
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Kenneth Moreland <kmorel@sandia.gov>
Merge-request: !359
I ran into a few minor issues with the constructors to the Field class.
The big change I made was that I removed the Field constructors that
take an example type and create an empty field of that type. The problem
was that the example type was easily confused with some other type that
was supposed to describe an array. This lead to some odd behavior in the
compiler and resulted in errors in unexpected places.
The use case for this constructor is dubious. There were several tests
in the code that would create an empty field, add it to a data set, then
get it back out to pass to the worklet. The code is much simpler if you
just make an ArrayHandle of the right type and use that in the worklet
invoke directly. It is also faster to compile with smaller code because
the type is known statically (whereas it is lost the other way).
The other change was to declare references to ArrayHandle and
DynamicArrayHandle as const. There is nothing in the behavior that
invalidates the const, and it accepts arrays constructed in the
parameter.
The map topology worklets are to have convenience classes for all the
common mappings. However WorkletMapCellToPoint was left out as an
oversight. This adds the class.
4153c2c7 Found a few more places where we don't need to return by value.
dd85fc13 Document why we certain classes member variables need to be const ref.
6fb86da8 DynamicArrayHandle Casting methods now holds by const * const.
c1560e2d Perform less unnecessary copies when deducing a worklets parameters.
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Kenneth Moreland <kmorel@sandia.gov>
Merge-request: !320
There was an inconsistency in naming classes where axes-aligned grids
with even spacing were sometimes called "uniform" and sometimes called
"regular". Maintain consistency by always calling them uniform.
Previously, DynamicArrayHandle and DynamicCellSet had slightly different
interfaces to their CastTo feature. It was a bit confusing and not all
that easy to use.
This change simplifies and unifies them by making each class have a single
CopyTo method that takes a reference to a cast object (an ArrayHandle or
CellSet, respectively) and fills that object with the data contained if
the cast is successfull. This interface gets around having to declare
strange types.
Each object also has a Cast method that has to have a template parameter
specified and returns a reference of that type (if possible).
In addition, the old behavior is preserved for DynamicArrayHandle (but
not DynamicCellSet). To avoid confusion, the name of that cast method is
CastToTypeStorage. However, the method was chaned to not take parameters
to make it consistent with the other Cast method.
Also, the IsType methods have been modified to reflect changes in
cast/copy. IsType now no longer takes arguments. However, an alternate
IsSameType does the same thing but does take an argument.
4bb3cce0 Use the DataSetBuilderExplicitIterative helper where it is useful.
eba2fb49 Fixed some warnings in the DataSetBuilder code.
dd312516 Fix issue found be moving over to DataSetBuilderExplicit.
e7456fa1 Update vtkm tests and examples to use DataSetBuilders.
449c425a Allow DataSetBuilderExplicit to create CellSetSingleType.
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Kenneth Moreland <kmorel@sandia.gov>
Merge-request: !318
Mainly issue dealing with dimensionality of cell sets and what that represents.
Have added in code to allow user to specify a custom dimensionality so that
tests continue to work properly.
956cedfd Turn off the benchmarking ExternalsFaces.
18b866d6 Threshold worklet is not templated on device adapter.
dbee9275 ExternalFaces worklet is not templated on device adapter.
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !315
f86382f0 Fix support for CoordinateSystems using ArrayHandleCartesianProduct.
d6a2a142 Add toleranced compare for values. Add tests for vtkm::Float32,Float64,Id typed arrays.
5d438353 Add toleranced comparisions for bounds validation. Also, add vtkm::Float32 and vtkm::Float64 to the testing for rectilinear and regular datasets.
b225ae97 Rectilinear coordinates (created with DataSetBuilderRectilinear) are now converted to vtkm::FloatDefault. This reduces the number of types to consider when casting inside CoordinateSystem, and was felt by all to be a reasonable restriction.
d755e43d Use ArrayHandleCompositeVector to represent separated point arrays for DataSetBuilderExplicit.h.
c7b0ffb8 Add tests for DataSetBuilderExplicit. Added cont/testing/ExplicitTestData.h which includes several explicit datasets. These datasets come from VTK data generated in VisIt. The new unit tests build datasets in several different ways and do some basic validation.
b4d04fff Add specialization of printSummary_ArrayHandle for UInt8. It prints them as characters, which are a little hard to understand to this computer scientist.
bd929c20 Fix compiler warnings.
...
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Kenneth Moreland <kmorel@sandia.gov>
Merge-request: !262
82a573f7 MarchingCubes is now able to not generate normals.
502e7c28 Merge branch 'cleanup_scatter_counting_uses' into marching_cubes_normal_generation_option
8079dc28 MarchingCubes generate step now requires a ScatterCounting object.
4cd2f582 Add a default constructor for ScatterCounting.
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Kenneth Moreland <kmorel@sandia.gov>
Merge-request: !300
WorkletMapPointToCell is a convenience subclass of WorkletMapTopology.
As such, it renames all the From/To signature tags to say Point/Cell to
be easier to read. However, the alias for FromCount was missing. Add the
alias PointCount.
By restricting the types explicitly in the ControlSignature we reduce
the code bloat, if we ever pass in a DynamicArrayHandle as one of those
parameters.
Without a default constructor for ScatterCounting any class that wants
to hold onto a ScatterCounting object is required to know what device
they are running on. By allowing default construction, we can move that
requirement to just have a method on the object require a device adapter
object.
Previously each device adapter only had a unique string name. This was
not the best when it came to developing data structures to track the status
of a given device at runtime.
This adds in a unique numeric identifier to each device adapter. This will
allow classes to easily create bitmasks / lookup tables for the validity of
devices.
a7127f0f Adding vtkm::cont::RuntimeDeviceInformation.
7d249e89 Move DeviceAdapterTraits into vtkm::cont as they are user API.
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Kenneth Moreland <kmorel@sandia.gov>
Merge-request: !287
The RuntimeDeviceInformation class allows developers to check if a given
device is supported on a machine at runtime. This allows developers to properly
check for CUDA support before running any worklets.
When writing multiple backend code users of vtkm need to use the
DeviceAdapterTraits classes, so therefore we should move them to vtkm::cont
to signify this.
The two worklets for marching cubes use tables stored in arrays that
have random access. Previously, they arrays were passed using the
ExecObject tag in ControlSignature along with ExecutionWholeArrayConst.
This changes to using a WholeArrayIn tag and just passing the
ArrayHandle directly to the Invoke method. The end result is the same,
but the code is a bit cleaner.
The WholeArrayIn, WholeArrayInOut, and WholeArrayOut ControlSignature
tags behave similarly to using an ExecObject tag with an
ExecutionWholeArray or ExecutionWholeArrayConst object. However, the
WholeArray* tags can simplify some implementations in two ways. First,
it allows you to specify more precisely what data is passed in. You have
to pass in an ArrayHandle or else an error will occur (as opposed to be
able to pass in any type of execution object). Second, this allows you
to easily pass in arrays stored in DynamicArrayHandle objects. The
Invoke mechanism will automatically find the appropriate static class.
This cannot be done easily with ExecutionWholeArray.
When a C++ object is constructed, the fields (ivars) of that object are
initialized in the order they are declared in the structure regardless
of the order of initializers listed in the constructor. Thus, it is good
C++ convention to list the initializers of the constructor in the same
order they are declared in the class so that there is no confusion about
the order of initialization (which can matter if there are any
dependencies). To help enforce this convention, some compilers warn if
the order does not match. This commit fixes that issue.
This commit also removes trailing whitespace at the end of some lines in
StreamLineUniformGrid.h. My editor does this automatically because
trailing whitespace bugs some programmers.
Previously, there was a table holding the number of vertices produced
for each MC case. However, what we really need is the number of
triangles, so we would have to divide that by 3. Instead, just store the
number of triangles.
The previous implementation was declaring static arrays in methods,
which cannot be used on a CUDA device. Instead, make static tables that
can be passed to the device with array handles (much like clip tables
do).
The tetrahedralize algorithms have been changed to use the Scatter
classes to build indices rather than build them on their own.
To implement this efficiently with structured grids, a new ScatterUniform
class was made. I also added a new execution argument tag that allows
you to get the thread indices object from within the worklet.
It is the case that there are two ways to create the output to input map in
a count scatter. The first is to use a parallel find for every output index.
The second, which is used when there are lots of output, is to iterate over
the input and write out the reverse map. In this case, it is trivial to also
write out the visit indices, so do that instead of a bunch more searches.
The original isosurface code was not treating the origin and spacing of
the point coordinates correctly. Instead, it was ignoring the origin and
spacing and instead scaling all point coordinates to be in the unit cube
in world space (except there was also an off-by-one error in that). This
change recompensates by adjusting the origin and spacing to make the
correct position where the geometry was previously errantly placed.
Now that ScatterCounting is implemented, we can use that to implement a
good part of the triangle generation in the isosurface algorithm. This
changes the worklet from a basic map to a topology map, which also
reduces a lot of code.
This changes the interface to the ThreadIndices classes to have both
input and output indices. It also adds a visit index to ThreadIndices.
Also added the VisitIndex execution signature tag, which relies on this
behavior.
Previously we always ran DynamicTransformCont even if we knew all the types.
By checking for Dynamic types first, we save roughly 3% on the binary size.
This also is a good starting point for a redesign of DynamicTransformCont
DispatcherMapField was templated on the device adapter but it
actually doesn't need to be, only BasicInvoke and subsequent
methods need to be templated on the device.
This now allows for even more efficient construction of uniform point
coordinates when running under the 3d scheduler, since we don't need to go
from 3d index to flat index to 3d index, instead we stay in 3d index
Change Fetches to use ThreadIndices instead of Invocation.
Previously, all Fetch objects received an Invocation object in their
Load and Store methods. The point of this was that it allowed the Fetch
to get data from any of the execution objects. However, every Fetch
either just got data directly from its associated execution object or
else used a secondary execution object (the input domain) to get indices
into their own execution object.
This left two potential areas for improvement. First, pulling data out
of the Invocation object was unnecessarily complicated. It would be much
nicer to get data directly from the associated execution object. Second,
when getting index information from the input domain, it was often the
case that extra computations were necessary (particularly on structured
cell sets). There was no way to share the index information among
Fetches, and therefore the computations were replicated.
This change removes the Invocation from the Fetch Load and Store.
Instead, it passes the associated execution object and a new object type
called the ThreadIndices. The ThreadIndices are customized for the input
domain and therefore have all the information needed for a redirected
lookup. It is also a thread-local object so it can cache computed
indices and save on computation time.
See merge request !233
Previously, all Fetch objects received an Invocation object in their
Load and Store methods. The point of this was that it allowed the Fetch
to get data from any of the execution objects. However, every Fetch
either just got data directly from its associated execution object or
else used a secondary execution object (the input domain) to get indices
into their own execution object.
This left two potential areas for improvement. First, pulling data out
of the Invocation object was unnecessarily complicated. It would be much
nicer to get data directly from the associated execution object. Second,
when getting index information from the input domain, it was often the
case that extra computations were necessary (particularly on structured
cell sets). There was no way to share the index information among
Fetches, and therefore the computations were replicated.
This change removes the Invocation from the Fetch Load and Store.
Instead, it passes the associated execution object and a new object type
called the ThreadIndices. The ThreadIndices are customized for the input
domain and therefore have all the information needed for a redirected
lookup. It is also a thread-local object so it can cache computed
indices and save on computation time.
Xcode 7 warnings
The XCode 7 compiler has a new warning for unused typedefs. The Boost code we use has some instances where this warning gets issued. Suppress these warnings.
See merge request !199
This is to be used in place of BOOST_STATIC_ASSERT so that we can
control its implementation.
The implementation is designed to fix the issue where the latest XCode
clang compiler gives a warning about a unused typedefs when the boost
static assert is used within a function. (This warning also happens when
using the C++11 static_assert keyword.) You can suppress this warning
with _Pragma commands, but _Pragma commands inside a block is not
supported in GCC. The implementation of VTKM_STATIC_ASSERT handles all
current cases.
5e72d3a8 Rename kernels directory to splatkernels to avoid confusion
7a2225cf Add Copyright text
d04e4dfa Remove c++11 constexpr keyword
ed5faf5b Fix for M_PI on windows, use vtkm::Pi()
fe284ffb Add unit test for splat kernel integral.
29001e37 Change GaussianSplatter to KernelSplatter to support other kernels
378cb17e Code cleanup, style, debug, unused vars
65d2980f Fix clang compile error, cleanup debug messages
...
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Robert Maynard <robert.maynard@kitware.com>
Merge-request: !193
The boost assert macros seem to have an issue where they define an
unused typedef. This is causing the XCode 7 compiler to issue a warning.
Since the offending code is in a macro, the warning is identified with
the VTK-m header even though the code is in boost. To get around this,
wrap all uses of the boost assert that is causing the warning in the
third party pre/post macros to disable the warning.
Performance testing has shown that the combined lower-bounds + update-connectivity
worklet is marginally, but consistently faster than DeviceAdapterAlgorithm::LowerBounds
followed by an update-connectivity worklet. It also requires less memory.
Template the splatter algorithm over Kernel type and use abstract kernel
interface to fetch the kernel value.
Add Gaussian, Spline3rdOrder kernel classes templated over dimension.
Other kernels can/will be added in future.
Kernel classes are defined such that the integral of the volume is unity
as is the convention in (for example) SPH simulations.
Clean up the implementation to take a uniform grid dataset as input
and splat using the correct world coordinates of the points into
the volume. Kernels are centred around the splat points in world coordinates
(floating point) and not quantized to the nearest voxel.
Skip the generation of all volume points which is unnecessary (memory usage).
Add ability to specify a radius array with one entry per splat point so
that the size of each splat may be controlled arbitrarily.
form of an ArrayHandle. Histogram takes the number of bins and returns the bin array.
Statistics returns a structure with standard stats plus raw and central moments.
Although this is labeled as a unit test, this is more of an integration
test to make sure that when a uniform point coordinate is passed as a
field to a WorkletTopologyMap from points to cells with a regular cell
set, you get the specialized VecRectilinearPointCoordinates in the
worklet argument.
adding cell-to-point topology support and worklet
This adds code to support a cell-to-point topological mapping worklet.
For explicit cell set, there is code to calculate a cell-to-point topology from the canonical point-to-cell topology. (It is not parallelized at this point.) Most of the required code for structured grids was already in place.
See merge request !154
The names of the cell shapes and header files changed superficially. The
check in missed the clip and external faces. Update that code.
There are also some less superficial changes that allow you to manage
cell shapes with tags. It might be worthwhile to update this code to use
that new infrastructure.
Previously, when you requested a CellShape in the ExecutionSignature,
you just got an ID stored in a vtkm::IdComponent. This change returns a
cell shape tag of the appropriate type (or generic if the type is not
known at compile time). This will allow functions called from the
worklet to specialize on the cell type better.
We have been using the term "shape" in the cell set and connectivity
classes. To be consistent, use the term "shape" for the geometric
identify of the cell everywhere.
templating topology worklet to support mappings other than point-to-cell
This adds a FromTopology and ToTopology template type to the topology worklet, removing hard-coded types.
This is a precursor step necessary before we can add other mappings (like cell-to-point, etc.).
See merge request !140
Previously, coordinate systems in a DataSet simply pointed to field data
specifying the coordinate information (although the ability to get that
back out of the DataSet was missing). This makes sense since point
coordinates are in fact just fields with a particular semantic meaning
to them.
However, there is an issue with this approach. It turns out that there
are special representations that are very common for point coordinates
and very uncommon for other types of fields. For example, a uniform
(a.k.a. regular or image) grid has point coordinates that are easily
derived from the point index, but such fields are quite uncommon
elsewhere.
Representing this kind of structure in the Field list of a DataSet is
problematic. Either all fields have to check to see if they are this
type, which will cause an explosion of unnecessary generated code, or
you will have to actually write out the coordinates in memory, which is
really wasteful but what was done previously.
However, by storing fields representing coordinate systems in a separate
batch, we can use these special types without the stated explosion.
The constructor for execution whole array was wrong and would result in compilation error if used. This fixes that and adds a test path for testing ExecutionWholeArray with ExecutionWholeArrayConst.
This class was used to store a group of from field data in a topology
map. However, the fetching has been changed to use a customized class
for each type of fetch that can be optimized for the fetch type and does
not require to know the number of items in the fetch at compile time.
Thus, this class is no longer needed, so it is being removed.
This change removes the requirement to specify some maximum cell length
in each of the worklets, which is basically impossible. It also makes
some of the loading more lazy, which might help reduce the number of
registers required in a worklet.
We want to be able to get topological connections where it is difficult
to know how many values you get each time. In this change, the type of
the vector holding the from indices is determined from the connectivity
object, and the worklet does not know the type (it must be templated).
Although you do not need to specify the max number for this value set
(you still currently do for field values), we still need to change the
type for explicit sets that uses something that does not rely on the Vec
class. The cell-to-point method also needs a Vec wrapper that allows it
to shorten the vector dynamically.
Previously, all arrays passed to worklets were designated as either
input or output. No in-place operation was permitted. This change adds
the FieldInOut tag for ControlSignature in both WorkletMapField and
WorkletMapTopology that allows you to read and write from the same
array.
Clean up CellSet
Underneath the CellSet implementation is a set of supporting classes that manage the actual structure in both the control and execution environments. However, the implementation of these classes was a bit confusing and inconsistent. The following changes are made:
* Most significantly, there is no longer any Connectivity classes in the control environment. This functionality has been wrapped up into the CellSet classes, which is more consistent and easier to understand. (There was a definite distinction between CellSet and Connectivity, but it was subtle and difficult to understand.) This also means that edits to CellSets happen to CellSets directly.
* The set of classes for structured and explicit cell sets match. There is different functionality within, but the class naming and meaning are consistent.
* Make the class names more consistent with the rest of VTK-m class names. Specifically classes like ExplicitConnectivity become ConnectivityExplicit. Also, the words regular and structured were being used interchangeably. Now, always use structured except when dealing specifically with grids of regular spacing.
* The connectivity classes were using the nomenclature "From" and "To" to specify topological elements of links. The same concept in worklet classes were using the nomenclature "Src" and "Dest." For consistency, all references are changed to "From" and "To".
* Unlike explicit cell sets, structured cell sets have functionality shared between control and execution environments. Rather than duplicate it or create unique exposed classes, have a shared internal implementation in vtkm::internal.
See merge request !117
(Re-) Add a helper structure that holds the connectivity information for
a particular topology connection (e.g. from points to cells) to make it
easier to manage connections in multiple different directions in
CellSetExplicit.
Unlike the previous version of connectivity, this structure is
considered "internal" and not exposed through the API so that
CellSetExplicit can better manage the data. Also, many of the helper
methods remain in CellSetExplicit since they were specific for point-to-
Also, CellSetExplicit has a mechanism to take an arbitrary pair of
TopologyElementTags and get the appropriate connectivity. This should
simplify adding connections in the future.
In the CellSet and related classes, a connection was referred to by a
"from" topology element and a "to" topology element. However, in the
worklet control signature tags the elements were referred to by "src"
and "dest." To make things consistent, use "from" and "to" everywhere.
Most of VTK-m follows the convention of calling the 0D topology elements
"points" (which follows the convention of VTK). However, there were
several places where they were referred to as "nodes." Make things
consistent by calling them points everywhere.
Also merged some redundant ExecutionSignature tags.
Previously there was a Connectivity* structure for both the control
environment and the execution environment. This was necessary before
because the connectivity is explicit to the from and to topology
elements, so you would get this structure from the appropriate call to
CellSet*. However, the symantics are changed so that the type of
connectivity is selected in the worklet's dispatcher. Thus, it is now
much cleaner to manage the CellSet structure in the CellSet class itself
and just have a single set of Connectivity* classes in the execution
environment.
Previously, the items used to identify parts of topology like points,
cells, faces, etc. were in an enumeration. However, they are only really
used in template specialization, and it is easier to use tags in this
case. So, change the enumeration to a set of tag structures. Also made
the following changes:
* Renamed TopologyType to TopologyElement, which is more indicative of
what we are referring to.
* Moved the structures from the vtkm::cont namespace to the vtkm
namespace. There is no reason not to be able to use them from either the
control or execution environments.
* Added a VTKM_IS_TOPOLOGY_ELEMENT_TAG macro to do type checks on
template arguments that are supposed to be topology element tags.
On one of my compile platforms, GCC was giving conversion warnings from
any boost include that was not wrapped in pragmas to disable conversion
warnings. To make things easier and more robust, I created a pair of
macros, VTKM_BOOST_PRE_INCLUDE and VTKM_BOOST_POST_INCLUDE, that should
be wrapped around any #include of a boost header file.
The Invoke of the topology dispatcher is also changed to expect a
concrete cell set (which the DynamicCellSet is automatically cast to)
rather than a connectivity structure. The dispatcher calls the
GetNodeToCellConnectivity method for you. (That is currently the only
one supported.)
MSVC ArrayHandle fail
Fix the fact that UnitTestArrayHandle is failing on the Windows dashboards. Also fix some of the MSVC warnings.
See merge request !101
The most common changes were making class members uppercase and spelled
out, adding "this->" whenever a class member is used, and declare
functions and members with export macros. Also fixed some uses of int
(instead of vtkm::Id or something similar) and a bit of indentation. I
also sprinkled some const goodness over the code.
It should be noted that I had about a week delay between first making
these changes and checking them in. In the mean time Sujin also made
some similar changes, so there might be some repetative changes.
Remove the usage of enable_if as return type to reduce binary size.
Using enable_if/disable_if as a return type has a negative impact on
binary size compared to use a boost::true/false_type as a method parameter.
For comparison the WorkletTests_TBB sees a 6-7% reduction in binary size when
compiled with O3.
Origin WorkletTests_TBB size details:
__TEXT __DATA __OBJC others dec hex
2363392 49152 0 4297793536 4300206080 1004ff000
Updated WorkletTests_TBB size details:
__TEXT __DATA __OBJC others dec hex
2215936 49152 0 4297568256 4299833344 1004a4000
See merge request !90
Using enable_if/disable_if as a return type has a negative impact on
binary size compared to use a boost::true/false_type as a method parameter.
For comparison the WorkletTests_TBB sees a 6-7% reduction in binary size when
compiled with O3.
Origin WorkletTests_TBB size details:
__TEXT __DATA __OBJC others dec hex
2363392 49152 0 4297793536 4300206080 1004ff000
Updated WorkletTests_TBB size details:
__TEXT __DATA __OBJC others dec hex
2215936 49152 0 4297568256 4299833344 1004a4000
Some fixes to VertexClustering
VertexClustering previously only worked with data of a specific floating
point type (32 bit for point coordinates). Add some templates to accept
either 32 bit or 64 bit floating points for point coordintes and be a
bit more careful about implicit type conversions.
I also made some changes to conform better with the VTK-m coding
standards. The most common changes are using 2 space indentation for all
block levels, capitolizing and using camel case for all class members,
and prefixing "this->" to all use of internal class members.
See merge request !64
When mixing precision, it is possible for the computation to pick a grid
size greater than the requested number of dimensions. This change
ensures that you never get more dimensions than requested. (Thanks to
Chun-Ming Chen for the fix.)
The test now behaves the same way as it did before the last change.
VertexClustering previously only worked with data of a specific floating
point type (32 bit for point coordinates). Add some templates to accept
either 32 bit or 64 bit floating points for point coordintes and be a
bit more careful about implicit type conversions.
I also made some changes to conform better with the VTK-m coding
standards. The most common changes are using 2 space indentation for all
block levels, capitolizing and using camel case for all class members,
and prefixing "this->" to all use of internal class members.
Implement a way to pass a portal to worklet as a parameter.
This is built ontop of the ExecutionObjectBase work, and is designed to show
other developers how they can create custom objects that are shared among
all worklets, but are passed as parameters to the worklet.
See merge request !60
This is built ontop of the ExecutionObjectBase work, and is designed to show
other developers how they can create custom objects that are shared among
all worklets, but are passed as parameters to the worklet.
