Routing DataModel: store-then-build (defer device construction to solve)#1556
Routing DataModel: store-then-build (defer device construction to solve)#1556ramakrishnap-nv wants to merge 13 commits into
Conversation
The public DataModel no longer inherits the Cython wrapper and no longer pushes each input to the GPU as it is set. Instead it records the setter calls and materializes the device (Cython) data model lazily -- when a solve runs or a getter is queried -- by replaying the recorded calls onto the wrapper. Size scalars are answered directly from the constructor args so setter-time validation does not trigger a build. This keeps the user's inputs host-resident while a problem is being assembled and exposes the recorded inputs for host-only problem construction (remote / gRPC serialization). Behavior is preserved except that wrapper/C++ validation and dtype-cast warnings now surface at build/solve time rather than at the setter call; two tests are updated to reflect this deferral. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Signed-off-by: Ramakrishna Prabhu <ramakrishnap@nvidia.com>
|
Auto-sync is disabled for draft pull requests in this repository. Workflows must be run manually. Contributors can view more details about this message here. |
ramakrishnap-nv
added
breaking
The recorder/delegator methods were enumerated in _SETTERS/_GETTERS name lists, a second copy of the DataModel method surface that would silently drift when a setter/getter is added to the wrapper. Install them by introspecting the wrapper's method surface instead, so the wrapper stays the single source of truth and adding a method needs no change here. Explicit overrides (matrix setters, size scalars) are skipped by the auto-install. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Signed-off-by: Ramakrishna Prabhu <ramakrishnap@nvidia.com>
The matrix setters kept a shadow dict (self.costs / self.transit_times) solely for the public duplicate-vehicle-type guard, which meant a future setter needing a set-time "already set?" check would silently need its own shadow. Drop the shadows: the matrix setters now auto-record like every other setter, and the guard reads the recorded calls via _recorded(). Add test_recording_covers_wrapper_surface so a new wrapper method that the recording layer does not handle (e.g. a mutator not named set_*/add_*) fails loudly instead of silently dropping its data. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Signed-off-by: Ramakrishna Prabhu <ramakrishnap@nvidia.com>
Clarify three low-severity trade-offs surfaced in review: the _SKIP_GETTERS helper exclusion list, get_num_orders mirroring the wrapper's n_orders == -1 default, and the duplicate-matrix guards reading vehicle_type as recorded args[1]. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Signed-off-by: Ramakrishna Prabhu <ramakrishnap@nvidia.com>
"Recording" named the mechanism; "lazy" names the intent -- the device model is built lazily at solve. Pure rename: _recording.py -> _lazy.py, _RecordingDataModel -> _LazyDataModel, test_recording.py -> test_lazy.py. No behavior change. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Signed-off-by: Ramakrishna Prabhu <ramakrishnap@nvidia.com>
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
📝 WalkthroughWalkthroughChangesRouting
Estimated code review effort: 3 (Moderate) | ~25 minutes Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
CI Test Summary✅ All 22 test job(s) passed. |
|
@coderabbitai review |
✅ Action performedReview finished.
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
🧹 Nitpick comments (1)
python/cuopt/cuopt/routing/vehicle_routing.py (1)
23-60: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winDocument the deferred-validation behavior for users.
The class docstring's "Note" section doesn't mention that, with the lazy build layer, validation errors and dtype-cast warnings for setter inputs now surface at
Solve/BatchSolve/getter time rather than at the setter call itself. This is a real debugging-experience change (per the PR summary, "C++ validation and dtype-cast warnings occur during model building or solving instead of at setter calls") and should be called out for users of the public API.📝 Suggested docstring addition
- Array parameters documented below as ``cudf.Series`` or ``cudf.DataFrame`` also accept an equivalent ``numpy.ndarray`` or ``pandas.Series``/``pandas.DataFrame``. cuDF inputs stay on the GPU; host (numpy/pandas) inputs are copied to the device for the local solve. Python lists and tuples are not supported. + + - Setter inputs are recorded and only validated/cast to device types + when the model is built, i.e. when ``Solve``/``BatchSolve`` runs or a + getter is queried -- not at the setter call itself. Input errors and + dtype-cast warnings may therefore surface later than the offending + setter call.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@python/cuopt/cuopt/routing/vehicle_routing.py` around lines 23 - 60, Update the DataModel class docstring’s Note section to document that setter input validation errors and dtype-cast warnings are deferred by the lazy build layer and surface during Solve, BatchSolve, or getter calls rather than at setter invocation.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Nitpick comments:
In `@python/cuopt/cuopt/routing/vehicle_routing.py`:
- Around line 23-60: Update the DataModel class docstring’s Note section to
document that setter input validation errors and dtype-cast warnings are
deferred by the lazy build layer and surface during Solve, BatchSolve, or getter
calls rather than at setter invocation.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Enterprise
Run ID: dc621816-47b0-4e06-b7b8-9ef0a7185389
📒 Files selected for processing (4)
python/cuopt/cuopt/routing/_lazy.pypython/cuopt/cuopt/routing/vehicle_routing.pypython/cuopt/cuopt/tests/routing/test_lazy.pypython/cuopt/cuopt/tests/routing/test_warnings_exceptions.py
|
@CodeRabbit review |
✅ Action performedReview finished.
|
- Record-time normalization (mixed IR): host inputs (numpy/pandas) are copied to a numpy array the model owns so the recorded calls are a serializable host IR and the user's array can be released; device (cuDF/cupy) inputs stay on device to preserve the zero-copy GPU path (exported to host only on serialize). - Transient build: the device model is no longer cached -- each solve/getter builds fresh and discards -- so an instance never holds both a host IR and a device copy (fixes the memory-doubling regression). - Declarative surface spec instead of dir() on the compiled wrapper, so constructing/recording imports no CUDA (wrapper imported lazily only at build). test_lazy guards the spec against drift. - Thread-safe first-call init. Getters still resolve via a transient build; host-mirror resolution and record-time dtype warnings migrate in follow-ups. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Signed-off-by: Ramakrishna Prabhu <ramakrishnap@nvidia.com>
The DataModel autoclass used :show-inheritance:, which rendered a "Bases:" line referencing the private implementation base (_LazyDataModel) that is not part of the public API -- an unresolved cross-reference that failed the docs build (warnings treated as errors). Drop :show-inheritance: for DataModel so the reference documents the public class and its members without dangling on an implementation detail (rather than suppressing the warning via nitpick_ignore). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Signed-off-by: Ramakrishna Prabhu <ramakrishnap@nvidia.com>
| loudly if a new wrapper method -- e.g. a mutator not named set_*/add_* -- | ||
| is added without being recorded, instead of silently dropping its data. | ||
| """ | ||
| dm = routing.DataModel(1, 1) # triggers _install_methods |
There was a problem hiding this comment.
What happens if user calls dm.random_func_call(x, y, z) ?
Should this be a test or a validation within cuopt
There was a problem hiding this comment.
Good question. dm.random_func_call(x, y, z) raises AttributeError — the recording layer installs only the declared setter/getter surface and has no __getattr__ catch-all, so an unknown or typo'd call fails loudly and never enters the IR (_calls stays empty). So it's standard Python behavior rather than something cuOpt needs to validate. I've added test_unknown_method_is_not_recorded to lock this behavior.
|
Just a few thoughts:
|
…avior - DataModel docstring: note that solver-side (C++) validation and dtype-cast warnings surface at Solve (lazy build), while structural checks stay eager at the setter (coderabbitai). - test_lazy: lock that an unknown/typo'd method call (dm.random_func_call(...)) raises AttributeError and is never recorded -- the recording layer installs only declared setters/getters, with no __getattr__ catch-all (Iroy30). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Signed-off-by: Ramakrishna Prabhu <ramakrishnap@nvidia.com>
Answer the reviewer question "how does a developer add a new function": add a "Adding a new setter/getter" section to the lazy layer docstring listing the three steps (wrapper method, public method, spec entry) and noting that test_lazy catches a missing spec entry in CI. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Signed-off-by: Ramakrishna Prabhu <ramakrishnap@nvidia.com>
Per review, "lazy" was too generic and "host" would be wrong (cuDF inputs pass through and stay on device). "Deferred" names the actual mechanism -- the device build is deferred to solve, for host and device inputs alike -- and avoids colliding with the Cython "wrapper". Pure rename: _lazy.py -> _deferred.py, _LazyDataModel -> _DeferredDataModel, test_lazy.py -> test_deferred.py. No behavior change. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Signed-off-by: Ramakrishna Prabhu <ramakrishnap@nvidia.com>
|
Thanks @Iroy30 — both addressed: 1) Adding a new function to the DataModel. Three steps, now documented in the 2) Naming. Renamed Also from the earlier thread: an unknown/typo'd call like |
Per review discussion: keep the "deferred" name but make the docstrings state plainly that the mechanism is call recording -- the class records the problem and defers building the device model, it does not build anything itself. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Signed-off-by: Ramakrishna Prabhu <ramakrishnap@nvidia.com>
2 participants
Summary
Routing
DataModelnow records its setter calls and builds the device model lazily at solve, instead of pushing each input to the GPU as it is set. This keeps inputs host-resident while a problem is assembled and is the foundation for host-only (remote / gRPC) problem construction.Behavior-preserving, except that C++ validation and dtype-cast warnings now surface at solve time rather than at the setter call. Full routing suite passes.
🤖 Generated with Claude Code