Difference between revisions of "Cell Set Dimensionality"
Jsmeredith (talk | contribs) (Created page with "This outlines the pros and cons for restricting a Cell Set to contain cells of a single dimensionality. Pros ==== Cons ====") |
Jsmeredith (talk | contribs) |
||
Line 1: | Line 1: | ||
− | This outlines the pros and cons for restricting a Cell Set to contain cells of a single dimensionality. | + | 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 | 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 | 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? |
Latest revision as of 10:00, 23 March 2016
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?