not sure if it should fall in feature request or a straight bug. I notice that if we generate global IDs in a structured dataset and then clip it (ergo we transform it to a unstructured dataset) we loose this IDs, not sure if it is something that ‘would be require to implement’ or if its something that ‘was not supposed to happen’ and then it should be reported as bug?.
in any case, it would be great to be able to ‘keep’ the globalIDs of the structured data to go thought all the pipeline.
to recreate what I am trying to explain:
source: wavelet
globalPointAndCellIDs
Clip
the resulting clip will ‘loose’ the GlobalPointIds.
EDIT:
okey, I found where the problem comes from, and it is not the data conversion itself, it is doing the clip without the crinkle option on. if we use it with the crinkle on the global ids will be conserved.
personally, I think the crinkle option should be set to 1 by default, as it defeats all porpuse of the global IDs filter, the idea of it is to work in a small portion and be able to ‘go back’ to the geometry and then one realize that it is missing this ids, and it is quite difficult to find the ‘reason’ why they disappeared. once you think about it is normal as without crinkle you would ‘cut’ cells so they should conserve the same global ID? maybe (i would tend to say yes but it is not a simple answer), so i understand that this field disappear but would prefer that the default behavior would be keep it.
Crinkle clip should not be needed to keep the point ids, instead they should be transferred to a OriginalGlobalPointIds and OriginalGlobalCellIds fields
Some thoughts on this discussion. Like @mwestphal said, the choice of whether to preserve global ids is up to each filter. I won’t claim that all filters make this choice rationally, but the decisions the Clip filter is making are (mostly) rational. It is because global ids must have a unique value for every point/cell. Violating that could cause problems with filters that operate using the global ids.
The Clip filter has to drop the point global ids because when it cuts away parts of a cell to create a smooth boundary, it has to generate new points that do not exist in the input. You can’t interpolate the ids as you do with most fields as that would be nonsensical, and you can’t just pick an id as that could violate the uniqueness requirement.
The Clip filter also has to drop the cell global ids because when cells get clipped they are often replaced with multiple cells to remesh the new shape. If all those new cells inherited the same global id of the cell that was broken up, that would once again violate the uniqueness constraint.
Now, I said at the start that the Clip filter is mostly rational because there is one thing it could be doing that it does not. VTK supports a different type of id called a pedigree id. The point of this type of id is to record the identifier of the element something originally came from. Pedigree ids don’t have the uniqueness constraint. Although the name of the field would still have global in the name, which could confuse humans, it could internally be marked as pedigree ids to prevent downstream filters from making invalid assumptions about them. Supporting that in the Clip filter would be a reasonable feature request.
I would also note that if crinkle is really the default you want, I suggest using the Extract Cells By Region filter. The performs the same basic operation as Clip with crinkle on, but also gives you more options.
it is not that it is the default perse, but when you activate as it will not cut cells nor create points, etc. it will keep the global id generated previously. IMO it is a better behavior but it is quite niche type of application maybe? and also it would perturbate the users that are already used to have clip without crinkle on in other workflows.