Cell Set Dimensionality

From VTKM
Revision as of 10:00, 23 March 2016 by Jsmeredith (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

This outlines the pros and cons for restricting a Cell Set to contain cells of a single topological dimensionality (e.g. polygonal elements in one cell set and volumetric elements in another cell set).

Pros

==

1. Many algorithms are specific to one dimensionality, e.g. can old calculate surface normals of a 2D cell set, and can only find external faces of a 3D cell set. Knowing the dimensionality as part of the metadata or within the cell set lets us give useful error messages, have more context-appropriate actions, and simplify the code. This could even e.g. sending smaller tables or having less code per kernel launch.

2. Even when the algorithm is not inherently dimensionality-specific, the actions taken on each dimensionality are often different, so in that case the benefits of the above may still apply.

3. Few cases where it is actually useful to have multiple topological dimensionality elements within a single cell set. (Need input on this -- other than in the event we receive a file like that, what's the real value?)


Cons

==

1. Some input data may not have these split apart, so we need to do the splitting and lose the mapping. (Perhaps we can have some ways of showing a unified picture of these cell sets to mitigate that problem.)

2. Enforcement: when is it enforced? What error is thrown when someone tries to do it wrong?