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.
VoronoiTessellator._enforce_barriersallocates ids for barrier-split cell fragments like this (src/vorflow/tessellator.py:128,166ondevelop):node_idcomes from gmsh node tags, which areuint64.Under NumPy 2.x (NEP 50)
np.uint64(n) + 1staysuint64— confirmed locally on NumPy 2.4.1, wherenode_idremainsuint64through 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 wholenode_idcolumn becomes float, and anything downstream assuming integer ids (merge keys, MODFLOW cell numbering, shapefile round-tripping) is affected.This matters because
pyproject.tomlin #12 declaresnumpy>=1.24, and theminimum-dependenciesCI job pinsnumpy==1.24.0exactly.Needs verifying
Run a plain-barrier cut (
is_barrier=True, nostraddle_width, noquad_buffer) against NumPy 1.24 and checkgrid['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:
and assert the column dtype after
_enforce_barriers.Pre-existing on
develop— not introduced by #12.