IntVarLocalSearchFilter Initialization Failure in Python

[celalblgn]

Bug Report Summary: IntVarLocalSearchFilter Initialization Failure in Python (v9.12.4544)
Environment:
OR-Tools Version: 9.12.4544 (Installed via pip)
Python Version: 3.13
Operating System: macOS
Architecture: Arm (Apple Silicon)
Problem Description:
It is currently impossible to initialize a custom local search filter class inheriting from ortools.constraint_solver.pywrapcp.IntVarLocalSearchFilter using the standard Python constructor signature in OR-Tools v9.12.4544.

Intended Use Case:

We are trying to implement a custom LocalSearchFilter to perform a Bin Packing feasibility check during the VRP solver's local search phase. The filter needs access to the routing variables (NextVar instances) to evaluate proposed route changes.
Steps Taken & Errors Encountered:
Defining the Custom Filter:

    from ortools.constraint_solver import pywrapcp

    class CustomFilter(pywrapcp.IntVarLocalSearchFilter):
        def __init__(self, routing: pywrapcp.RoutingModel, manager: pywrapcp.RoutingIndexManager):
            # Get the list of relevant IntVars (e.g., NextVar)
            variables = [routing.NextVar(i) for i in range(manager.GetNumberOfIndices())]
            # Call the base class constructor as per documentation
            super().__init__(variables) # <-- Error occurs here
            # ... rest of init ...

        def Accept(self, delta, assignment, _):
            # ... implementation ...
            return True # or False

Registering the Filter:

    # Inside solver setup
    my_filter = CustomFilter(routing_model, routing_manager)
    routing_model.AddLocalSearchFilter(my_filter)

Observed Behavior & Errors:

Standard Call (super().init(variables)): This is the correct call according to the documentation 1, which expects a single vars argument. However, this fails with:

TypeError: sequence(operations_research::IntVar*) expected

This indicates the Python list of IntVar objects is not being correctly converted/accepted by the underlying C++ binding as the expected sequence type.

Unpacking Call (super().__init__(*variables)): Attempting to unpack the list fails with:
TypeError: IntVarLocalSearchFilter.__init__() takes 2 positional arguments but N were given (where N > 2)

This confirms the constructor expects a single sequence argument, not multiple individual variable arguments.

Parameterless Call (super().__init__()): Fails with:
TypeError: IntVarLocalSearchFilter.__init__() missing 1 required positional argument: 'vars'

This confirms the vars argument is mandatory.

Conclusion:

The Python bindings for IntVarLocalSearchFilter.init in OR-Tools v9.12.4544 appear to be broken. The standard method of passing a Python list of IntVar objects, as required by the constructor's signature, results in a TypeError indicating the Python list is not being correctly interpreted as the required C++ sequence type. This prevents the use of custom IntVarLocalSearchFilters in Python for this version.
Workaround:
We are currently unable to integrate the BPP check during local search and are resorting to a post-processing check after the VRP solution is found.

[Mizux]

@celalblgn
could you try to run the sample: examples/contrib/pyls_api.py ?
note: in this one, Solve(2) use a class SumFilter(pywrapcp.IntVarLocalSearchFilter):

see:

or-tools/examples/contrib/pyls_api.py

Lines 48 to 78 in 9b77015

	class SumFilter(pywrapcp.IntVarLocalSearchFilter):
	"""Filter to speed up LS computation."""
	def __init__(self, vars):
	pywrapcp.IntVarLocalSearchFilter.__init__(self, vars)
	self.__sum = 0
	def OnSynchronize(self, delta):
	self.__sum = sum(self.Value(index) for index in range(self.Size()))
	def Accept(self, delta, unused_delta_delta, unused_objective_min,
	unused_objective_max):
	solution_delta = delta.IntVarContainer()
	solution_delta_size = solution_delta.Size()
	for i in range(solution_delta_size):
	if not solution_delta.Element(i).Activated():
	return True
	new_sum = self.__sum
	for i in range(solution_delta_size):
	element = solution_delta.Element(i)
	int_var = element.Var()
	touched_var_index = self.IndexFromVar(int_var)
	old_value = self.Value(touched_var_index)
	new_value = element.Value()
	new_sum += new_value - old_value
	return new_sum < self.__sum
	def IsIncremental(self):
	return False

ps: Tomorrow i'll try to test on a macOS to see if I can reproduce the error...

DevNote:

or-tools/ortools/constraint_solver/constraint_solveri.h

Lines 3175 to 3177 in 2159231

	class OR_DLL IntVarLocalSearchFilter : public LocalSearchFilter {
	public:
	explicit IntVarLocalSearchFilter(const std::vector<IntVar*>& vars);

or-tools/ortools/constraint_solver/local_search.cc

Lines 2565 to 2568 in 9b77015

	IntVarLocalSearchFilter::IntVarLocalSearchFilter(
	const std::vector<IntVar*>& vars) {
	AddVars(vars);
	}

[StevenGay]

Hello celalblgn,

I know it does not solve the problem you have, but you could pass routing.Nexts() directly to super().__init__().

About your bin-packing constraint, is it different from a capacity constraint?
The routing library has a very efficient filter for this, it takes into account the sum of negative and positive demands happening on the route versus a capacity.

[Mizux]

        variables = [routing.NextVar(i) for i in range(manager.GetNumberOfIndices())]

Beware routing.NextVar(i) is not defined on vehicle's End node, I think you should replace this line by

   variables = [routing.NextVar(manager.NodeToIndex(i)) for i in range(manager.GetNumberOfNodes())]

otherwise you should get a zsh: segmentation fault (core dumped) python ./program.py

ref: #2773 (comment)

devNote:

I've tested with a main build (and with venv and ortools 9.12), but on linux, by hacking this sample a follow, didn't get any crash... :

diff --git a/ortools/routing/samples/vrp_global_span.py b/ortools/routing/samples/vrp_global_span.py
index 7d474eff0b..7572e31683 100644
--- a/ortools/routing/samples/vrp_global_span.py
+++ b/ortools/routing/samples/vrp_global_span.py
@@ -26,6 +26,7 @@ Distances are in meters.
 # [START import]
 from ortools.routing import enums_pb2
 from ortools.routing import pywraprouting
+from ortools.constraint_solver import pywrapcp
 # [END import]
 
 
@@ -87,6 +88,23 @@ def print_solution(data, manager, routing, solution):
 # [END solution_printer]
 
 
+class CustomFilter(pywrapcp.IntVarLocalSearchFilter):
+    def __init__(self, routing: pywraprouting.RoutingModel, manager: pywraprouting.RoutingIndexManager):
+        # Get the list of relevant IntVars (e.g., NextVar)
+        #variables = [routing.NextVar(i) for i in range(manager.GetNumberOfIndices())]
+        variables = [routing.NextVar(manager.NodeToIndex(i)) for i in range(manager.GetNumberOfNodes())]
+        # Call the base class constructor as per documentation
+        super().__init__(variables) # <-- Error occurs here
+        # ... rest of init ...
+
+    def Accept(self, delta, unused_delta_delta, unused_objective_min, unused_objective_max):
+        # ... implementation ...
+        return True # or False
+
+    def IsIncremental(self):
+        return False
+
 def main():
     """Entry point of the program."""
     # Instantiate the data problem.
@@ -106,6 +124,10 @@ def main():
     routing = pywraprouting.RoutingModel(manager)
     # [END routing_model]
 
+    # Inside solver setup
+    my_filter = CustomFilter(routing, manager)
+    routing.AddLocalSearchFilter(my_filter)
+
     # Create and register a transit callback.
     # [START transit_callback]
     def distance_callback(from_index, to_index):

[celalblgn]

Hi ,
Thanks a lot for this awesome library and your help — it’s been really useful in my project!

Based on our tests, I can provide the following feedback ;

We tested both our CustomFilter and the sample SumFilter . Both filters resulted in a crash (bus error/segmentation fault)
Here's what we tried:

Initially, CustomFilter gave a

syntax error: sequence(operations_research::IntVar*) expected

After fixing the next_vars definition to use manager.NodeToIndex(i), it registered successfully but resulted in a segmentation fault during solving

We then implemented the sample SumFilter exactly as provided, and it also caused a bus error
We tried converting the list of next_vars to a tuple before passing it to the filter constructor, but still got a bus error
The post-processing approach works reliably, which is our current workaround. However, it would be more efficient if we could use the IntVarLocalSearchFilter to prune infeasible solutions during local search.
Our findings suggest this is a general issue with the IntVarLocalSearchFilter, not specific to our filter implementation.

CustomFilter is not only capacity controller, it also checks loading sequence and goods loading optimization.

Let me know if you need any extra info or if I can help test something on my side. Happy to support however I can. Appreciate your time and all the work you’re putting into this project!