VehicleStep service times get multiplied by 10000

[juanluisrto]

After assigning a VehicleStep to a vehicle, all its service values service_at , service_before and service_after get multiplied by 10000.

To reproduce:

import vroom

step =  vroom.VehicleStepSingle(id = 1, service_at = 3, service_before= 5, service_after = 2)

print(step)
""">>> vroom.VehicleStepSingle(1, service_at=3, service_after=2, service_before=5)"""


vehicle = vroom.Vehicle(id = 100, start = 0, end = 0, steps = [step])
print(vehicle.steps)
"""
>>> [vroom.VehicleStepStart(),
>>>  vroom.VehicleStepSingle(1, service_at=30000, service_after=20000, service_before=50000),
>>>  vroom.VehicleStepEnd()]
"""

I think this makes the vehicles execute any preset steps much later than intended (often at the end of the route).
This can be seen in this example:

import numpy as np
import vroom

N_JOBS = 6

# distance between points is always 1
dur_matrix = (-1 * np.identity(N_JOBS) + 1).astype(int)
print(dur_matrix)
"""
[[0 1 1 1 1 1]
 [1 0 1 1 1 1]
 [1 1 0 1 1 1]
 [1 1 1 0 1 1]
 [1 1 1 1 0 1]
 [1 1 1 1 1 0]]
 """

jobs = [vroom.Job(i, location = i) for i in range(N_JOBS)] 

# we force these jobs to be accomplished at the start of the route
steps = [
    vroom.VehicleStepSingle(id = 1, service_at = 1),
    vroom.VehicleStepSingle(id = 2, service_at = 2),
    vroom.VehicleStepSingle(id = 3, service_at = 3),
]

vehicle = vroom.Vehicle(id = 100, start = 0, end = 0, steps = steps)

problem = vroom.Input()
    
problem.set_durations_matrix("car", dur_matrix)

problem.add_job(jobs)
problem.add_vehicle(vehicle)
solution = problem.solve(exploration_level=5, nb_threads=4)

solution.routes

In this case, the three steps get completed at the end of the route.

[juanluisrto]

For now I have realized that this line can be replaced by steps = steps since VehicleStep is converting the already created steps into new ones, applying _vroom.scale_from_user_duration and multiplying times by 100.
When accessing the vehicle.steps attribute this happens again thus getting the time * 100 * 100 upscale.

I guess the second * 100 should be left there. However, the problem of the steps not matching the desired service time constraints is still unresolved. I am exploring the codebase, specially the ForcedServiceclass trying to understand more.

[juanluisrto]

I opened #83 as a fix for the *10000 issue
Still, service times don't work for me as I understand they should

[jonathf]

Yeah, so upstream vroom made a change to scale up some costs and durations, and I've tried to patch all cases so that the user is unaffected by it. You found something I missed. Thanks for fixing that.

That being said, the underlying attributes accessed from cpp are 100, I think the idea is that all user inputs are scaled up like that and the system works internally in the space where all values are 100.

As for why you are seeing the results that you are, I think @jcoupey is the better person to answer that.

[jcoupey]

From what I can tell (problem.solve), you're using vehicle steps in solving mode, not plan mode. In that case, you have to be aware that you're only feeding an initial solution to VROOM (there is no guarantee the ordering won't be changed if the optimization phase finds a more suitable arrangement).

Plus the service_* keys are not used outside of plan mode, see https://github.com/VROOM-Project/vroom/blob/master/docs/API.md#vehicle-steps.

[juanluisrto]

After digging a bit I realized that plan mode is called via the check method of the problem class (if I understood correctly).

However, this is not available in pyvroom since VROOM is compiled without libglpk.
I am trying to compile pyvroom passing the -DUSE_LIBGLPK=true flag but then I get some other errors while importing the library. I'll open now a new issue.