About Using OR-Tools

[AlfieDiCaprio]

Hi, sorry to bother you again, I am still exploring and learning your work. If I just want to target the OVRPTW problem and not use MoE, when I set problem to "OVRPTW", num_experts to 1, it seems to be possible?

But if I want to try more nodes (for example, n=500), I first use generate_data to generate the OVRPTW_500 dataset. Then, due to the usage restrictions of get_opt_sol_path, I use the following code to generate the optimal solution based on baseline -> or_tools:
python OR-Tools_baseline.py --problem=OVRPTW --datasets=../data/OVRPTW/ovrptw500_uniform.pkl -n=1000 --cpus=10 -timelimit=20
But the following problem occurred:

>> OR-Tools failed to solve instance 99 - Solver status: 7
>> OR-Tools failed to solve instance 98 - Solver status: 7
>> Solving 100 instances within 22.33s using OR-Tools
Traceback (most recent call last):
File "/root/Routing-MVMoE-main/baselines/OR-Tools_baseline.py", line 421, in <module> print("Average cost: {} +- {}".format(np.mean(costs), 2 * np.std(costs) / np.sqrt(len(costs)))) 
File "/root/miniforge3/lib/python3.10/site-packages/numpy/core/fromnumeric.py", line 3504, in mean return _methods._mean(a, axis=axis, dtype=dtype, 
File "/root/miniforge3/lib/python3.10/site-packages/numpy/core/_methods.py", line 118, in _mean ret = umr_sum(arr, axis, dtype, out, keepdims, where=where) 
TypeError: unsupported operand type(s) for +: 'NoneType' and 'NoneType'

I would like to ask how to correctly use or-tools to generate the optimal solution? Thank you so much!

By the way, I used "ovrptw200_uniform.pkl" under "data-OVRPTW" as the dataset, and or-tools also had the above error.

[RoyalSkye]

Hi, thanks for your interest. If you only consider OVRPTW, you can use single-task model by setting --model_type= SINGLE. For n=500, I'm not sure whether OR-Tools can get a feasible solution within 20s. Could you tune hyperparameters, such as timelimit, first_solution_strategy, and local_search_metaheuristic?

[AlfieDiCaprio]

Thank you for your time and guidance. I noticed that there is ovrptw200_uniform.pkl in data/OVRPTW, so I tried n = 200, but changed to use
first_solution_strategy: PARALLEL_CHEAPEST_INSERTION, LOCAL_CHEAPEST_INSERTION, PATH_CHEAPEST_ARC;
local_search_metaheuristic: GUIDED_LOCAL_SEARCH, TABU_SEARCH, AUTOMATIC;
Set timelimit=3600, but the problem of Solver status: 7 still exists. So I tried n = 100 and used the following command, but the same error was reported.
python OR-Tools_baseline.py --problem=OVRPTW --datasets=../data/OVRPTW/ovrptw100_uniform.pkl -n=1000 --cpus=10 -timelimit=3600
Theoretically, the original code should run successfully when n = 100. Is this related to the fact that I use a Mac (cpu core=11 < 32)? Or if have other considerations, thank you for your reply and contribution!

[RoyalSkye]

I used a linux server to run all exps. My labmate also encountered this issue and resolved it by reinstalling the environments. Could you try initializing a new Conda environment with Python 3.8 and ortools?

[AlfieDiCaprio]

Thank you for your help, but when trying to create a new virtual environment and configure it under NVIDIA GeForce RTX 3090, CUDA 12.2

python=3.8.20
pytorch=1.12.1
ortools=9.12.4544

Using the following command, it is still Solver status: 7
python OR-Tools_baseline.py --problem=OVRPTW --datasets=.. /data/OVRPTW/ovrptw100_uniform.pkl -n=1000 --cpus=32 -timelimit=3600
Finally, I feel that it may be a problem with my server. Thank you very much for your reply above!

[RoyalSkye]

Okay, it's quite weird. I will update you if I find any solution.

[AlfieDiCaprio]

Thanks so much!!

[AlfieDiCaprio]

Dear author, could I pick your brain about my confusion for a minute again? Regarding the problems with various constraints in this paper (MVMoE), it seems that the number of vehicles should be fixed? The objective function is just to minimize the travel cost. In general, each problem is a single-objective problem.I wonder if my understanding is correct? Thank you so much.

[RoyalSkye]

To make OR-Tools runnable, we set the number of vehicles as a large enough number. Actually, the number of vehicle is not fixed. Your understanding regarding other parts is correct!

[AlfieDiCaprio]

Okay, I got it! Thank you soooo much!

[zyp100200]

Thank you for your time and guidance. I noticed that there is ovrptw200_uniform.pkl in data/OVRPTW, so I tried n = 200, but changed to use : , , ; : , , ; Set , but the problem of still exists. So I tried n = 100 and used the following command, but the same error was reported. Theoretically, the original code should run successfully when n = 100. Is this related to the fact that I use a Mac (cpu core=11 < 32)? Or if have other considerations, thank you for your reply and contribution!first_solution_strategy``PARALLEL_CHEAPEST_INSERTION``LOCAL_CHEAPEST_INSERTION``PATH_CHEAPEST_ARC``local_search_metaheuristic``GUIDED_LOCAL_SEARCH``TABU_SEARCH``AUTOMATIC``timelimit=3600``Solver status: 7``python OR-Tools_baseline.py --problem=OVRPTW --datasets=../data/OVRPTW/ovrptw100_uniform.pkl -n=1000 --cpus=10 -timelimit=3600

I'm encountering the same issue, and it's not just limited to OVRPTW. All problems involving open routes with time window constraints have this same problem, such as OVRPLTW, OVRPBTW, etc. Due to lack of experience, I'm not sure how to fix this issue. Could it be because the constraints for both open routes (O) and time windows (TW) aren't being handled correctly?

[zyp100200]

All Open-type problems have this issue。

Thank you for your time and guidance. I noticed that there is ovrptw200_uniform.pkl in data/OVRPTW, so I tried n = 200, but changed to use : , , ; : , , ; Set , but the problem of still exists. So I tried n = 100 and used the following command, but the same error was reported. Theoretically, the original code should run successfully when n = 100. Is this related to the fact that I use a Mac (cpu core=11 < 32)? Or if have other considerations, thank you for your reply and contribution! first_solution_strategyPARALLEL_CHEAPEST_INSERTIONLOCAL_CHEAPEST_INSERTIONPATH_CHEAPEST_ARClocal_search_metaheuristicGUIDED_LOCAL_SEARCHTABU_SEARCHAUTOMATICtimelimit=3600Solver status: 7python OR-Tools_baseline.py --problem=OVRPTW --datasets=../data/OVRPTW/ovrptw100_uniform.pkl -n=1000 --cpus=10 -timelimit=3600

I'm encountering the same issue, and it's not just limited to OVRPTW. All problems involving open routes with time window constraints have this same problem, such as OVRPLTW, OVRPBTW, etc. Due to lack of experience, I'm not sure how to fix this issue. Could it be because the constraints for both open routes (O) and time windows (TW) aren't being handled correctly?

All Open-type problems have this issue.

[zyp100200]

Modified the content of the distance_evaluator function to make the baseline run normally, but I'm not sure if it's correct. The author can refer to it and check whether it's running properly.

def create_distance_evaluator(data):
"""
Creates callback to return distance between points.
Handles both closed and open routes (with dummy_depot).
"""
# Precompute distance matrix for all nodes (including dummy_depot if exists)
num_nodes = data['num_locations']
if data['dummy_depot'] is not None :
num_nodes += 1

_distances = {}
for from_node in range(num_nodes):
    _distances[from_node] = {}
    for to_node in range(num_nodes):
        if from_node == to_node:
            _distances[from_node][to_node] = 0
        elif from_node >= data['num_locations'] or to_node >= data['num_locations']:
            _distances[from_node][to_node] = 0
        else:
            _distances[from_node][to_node] = Euc_distance(
                data['locations'][from_node],
                data['locations'][to_node]
            )
data['distance_matrix'] = _distances

def distance_evaluator(manager, from_index, to_index):
    """Returns the distance between two nodes."""
    from_node = manager.IndexToNode(from_index)
    to_node = manager.IndexToNode(to_index)
    return _distances[from_node][to_node]

return distance_evaluator

[RoyalSkye]

Hi, thanks for your suggestion! I'll check it after NeurIPS deadline.