In VTK-m we have a constant tension between minimizing the number of
types we have to compile for (to reduce compile times and library size)
and maximizing the number of types that our filters support.
Unfortunately, if you don't compile a filter for a specific array type
(value type and storage), trying to run that filter will simply fail.
To compromise between the two, added methods to `DataSet` and `Field`
that will automatically convert the data in the `Field` arrays to a type
that VTK-m will understand. Although this will cause an extra data copy,
it will at least prevent the program from failing, and thus make it more
feasible to reduce types.
This refactor aims to increase the performance of
AddField / Getfield at the expense of memory usage and
some bits of performances when only few fields are used
Moving to non-contiguous memory will impact cpu cache benefits,
however, since each of the Field has again another pointer to
its actual data, this benefits where actually just small.
Also the choice of map v.s. unordered_map is about the number of
elements, very likely few rehashing happenings from until <100
This will also reduce the memory fragmentation caused by vectors.
Signed-off-by: Vicente Adolfo Bolea Sanchez <vicente.bolea@kitware.com>
By removing the ability to have multiple CellSets in a DataSet
we can simplify the following things:
- Cell Fields now don't require a CellSet name when being constructed
- Filters don't need to manage what the active cellset is
a9bbb6ead Permute cells inline
d37ab7732 Add ability to read FIELD section in vtk legacy files
19a610f5e Fix skipping over information in vtk files
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Sujin Philip <sujin.philip@kitware.com>
Merge-request: !1797
A non-const version of GetCoordinateSystem was added to implement a
change to the point transform filter. To make things symmetric (and
provide likely future needs), also add non-const versions of getting the
fields and cell sets.
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.
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.
Adding API to DataSet to `CopyStructure` from another dataset. This
copies the cellsets and coordinate systems while leaving the fields
unchanged.
CreateResult no longer copies all input fields to the output dataset
created.
Furthermore, if a Filter subclass doesn't provide `MapFieldOntoOutput`,
then the default implementation simply copies only the selected fields
to the output dataset.