(user): Some of our client test fail depending on this value! we need to fix them and ideally randomize our behavior from on test to the next so that this doesn't happen in the future.
(user): Since these operators are very fast, add a parameter to cap the max time allocated for this second phase (e.g. Duration max_secondary_ls_time_limit).
(user): It is probably possible to generalize this constraint to a no-cycle in a general graph, or a no-cycle with sum incoming <= 1 and sum outgoing <= 1 (more efficient implementation). On the other hand, having this specific constraint allow us to add specific "cuts" to a VRP problem.
(user): Ideally, we should be able to extract any dimension like these (i.e. capacity, route_length, etc..) automatically from the encoding. The classical way to encode that is to have "current_capacity" variables along the route and linear equations of the form: arc_literal => (current_capacity_tail + demand <= current_capacity_head)
(user): Maybe change the way the conflict limit is enforced? currently it is enforced on each independent internal SAT solve, rather than on the overall number of conflicts across all solves. So in the context of an optimization problem, this is not really usable directly by a client.
(user): Setting this to something like 10 helps in most cases, but the code is currently buggy and can cause the solve to enter a bad state where no progress is made.