Repository navigation
Preserve coordinate dtype when casting RectilinearGrid to UnstructuredGrid - #8723
Conversation
…dGrid vtkAppendFilter selects its output point precision by inspecting the input's points, but a RectilinearGrid stores its points implicitly (not as a vtkPointSet), so the filter cannot detect the coordinate precision and falls back to single precision. This silently downcast float64 coordinates to float32 in cast_to_unstructured_grid, breaking workflows that rely on double-precision coordinates (e.g. geographic data). Detect a double-precision RectilinearGrid from its stored coordinate arrays and set the append filter's output precision explicitly to double in that case. Other dataset types are unaffected (vtkPointSet inputs already report their precision to the filter). Fixes pyvista#7931
banesullivan
left a comment
There was a problem hiding this comment.
This is probably also an issue for ImageData.
I'm wondering if we should just set the default to double precision. This might be a performance regression, though.
Ideally, I'd like to see a sweep of all data set types in the test to validate that we can do single and double precision unstructured grid cast appropriately.
Address review feedback: - Extend the precision fix to ImageData. Like RectilinearGrid it has no stored point array, so vtkAppendFilter could not detect its precision and downcast to single. Its coordinates derive from the origin and spacing, which VTK always stores in double precision, so the cast now produces double-precision points. vtkPointSet inputs are still left to the filter's default, which already preserves their precision (no blanket double- precision default, avoiding a memory regression for single-precision data). - Replace the RectilinearGrid-only test with a sweep over PolyData, StructuredGrid, UnstructuredGrid, PointSet and RectilinearGrid in both single and double precision, plus a dedicated ImageData case.
|
Thanks for the review! Addressed in the follow-up commit: ImageData — good catch, it had the same problem. Like Defaulting everything to double — I held off on this for exactly the performance/memory reason you mentioned: it would double the point-array footprint for genuinely single-precision Test sweep — replaced the Verified the full matrix locally; the existing |
|
Happy to add that canary test here if useful — i.e. assert the current buggy VTK behavior directly ( |
|
Ah, our messages crossed — I see you already pushed exactly that canary plus the VTK-bug links. Looks great, nothing to add from me. |
Description
cast_to_unstructured_gridsilently downcasts aRectilinearGrid'sfloat64coordinates tofloat32, as reported in #7931.Root cause
cast_to_unstructured_gridruns the input throughvtkAppendFilter. That filter chooses its output point precision by inspecting the input's points — but onlyvtkPointSetsubclasses store explicit points. ARectilinearGridstores its points implicitly (as per-axis coordinate arrays), so it is not avtkPointSet. The filter therefore cannot read the coordinate precision and falls back to its default of single precision, downcastingfloat64coordinates and breaking workflows that depend on double-precision coordinates (e.g. geographic data).Fix
When the input is a
RectilinearGrid, detect whether any of its stored coordinate arrays is double precision and, if so, set the append filter's output precision to double explicitly. Other dataset types are unaffected:vtkPointSetinputs (PolyData,StructuredGrid, …) already report their precision to the filter, so their behavior is unchanged. (VTK_DOUBLEis added to the_vtkimport allowlist to support the check.)Reproduction
Verification
RectilinearGridfloat64RectilinearGridfloat32RectilinearGridmixed f64/f32PolyData(Sphere) float32PolyData(Sphere) float64ImageDataAdded
test_cast_rectilinear_grid_to_unstructured_grid_keeps_dtype(parametrized overfloat64/float32), which also checks point/cell counts and that the coordinate values round-trip exactly. Existing cast tests pass;ruffandmypyare clean on the changed files.Fixes #7931