Skip to content

Barrier-split node_id may promote to float64 on NumPy 1.x #14

Description

@rhugman

VoronoiTessellator._enforce_barriers allocates ids for barrier-split cell fragments like this (src/vorflow/tessellator.py:128,166 on develop):

max_id = grid_gdf['node_id'].max()
...
max_id += 1
new_row['node_id'] = max_id

node_id comes from gmsh node tags, which are uint64.

Under NumPy 2.x (NEP 50) np.uint64(n) + 1 stays uint64 — confirmed locally on NumPy 2.4.1, where node_id remains uint64 through a barrier cut.

Under NumPy 1.x legacy promotion, uint64 + <python int> promotes to float64. If that holds, every barrier-split fragment gets a float id, the whole node_id column becomes float, and anything downstream assuming integer ids (merge keys, MODFLOW cell numbering, shapefile round-tripping) is affected.

This matters because pyproject.toml in #12 declares numpy>=1.24, and the minimum-dependencies CI job pins numpy==1.24.0 exactly.

Needs verifying

Run a plain-barrier cut (is_barrier=True, no straddle_width, no quad_buffer) against NumPy 1.24 and check grid['node_id'].dtype. I could not exercise the 1.x path from my environment.

CI would not catch it today either — see the companion issue about barrier cell-splitting having no test coverage.

Suggested fix

Make the allocation dtype-explicit regardless of NumPy version:

max_id = int(grid_gdf['node_id'].max())

and assert the column dtype after _enforce_barriers.

Pre-existing on develop — not introduced by #12.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions