Multi-location skills – one and only one should be selected about vrp HOT 16 OPEN

Sorry for my late reply,
I just comment the line check_e1303_vehicle_breaks_time_is_correct(ctx) :

pub fn validate_vehicles(ctx: &ValidationContext) -> Result<(), Vec<FormatError>> {
    combine_error_results(&[
        check_e1300_no_vehicle_types_with_duplicate_type_ids(ctx),
        check_e1301_no_vehicle_types_with_duplicate_ids(ctx),
        check_e1302_vehicle_shift_time(ctx),
        // check_e1303_vehicle_breaks_time_is_correct(ctx),
        check_e1304_vehicle_reload_time_is_correct(ctx),
        check_e1305_vehicle_limit_area_is_correct(ctx),
        check_e1306_vehicle_dispatch_is_correct(ctx),
        check_e1307_vehicle_has_no_zero_costs(ctx),
    ])
}

It indeed work as expected !
Thanks a lot.

from vrp.

Regarding the refueling example. Would break with specified location after some period of time (or distance) work better for this purpose? Logically, you don't want to refuel your vehicle right after beginning, as it is still full, or in the end, risking to run out of fuel in the middle of tour.

Interval break which has to be taken after specific working time (can be extended for distance too) is supported as experimental (unstable) feature.

from vrp.

Thanks, I didn’t realize that location and even better several locations can be set for breaks.
In this case, I guess the location of the break is optimized regarding the rest of the tour.
I’ll try this solution as it seems to fit quite well my needs.
Thanks a lot.

from vrp.

Thanks to your advice, I am now using breaks to include actions related to the fleet (petrol station, etc.) that should happen during a tour but potentially in different alternative locations. It is working indeed very well.

This leads me to a side question. The solution return the following stop description

"jobId": "break",
"type": "break",

Would it be possible to add a specific jobId by passing an additional and optional property in break definition?
Thanks.

from vrp.

I think it can be a tag property, similar one for a job. However, it would be one per break definition, not per break's location.

from vrp.

Yes, indeed, it could be one tag per break (like refueling). For locations, that can be hendle outside vrp-cli I guess.

from vrp.

I've added a tag property for break in the master branch. The plan is to make a new release this week, I just need to add some extra checks for solution checker

from vrp.

Thanks a lot.

from vrp.

The combination of breaks and tags provides an efficient solution for managing actions concerning vehicles: refueling, cleaning.
However, several of these actions may happen in the same time window (TW), whatever the final order may be. It seems that the breaks option does not handle this specific case.
Would it be possible to add an option to have several breaks in the same TW?
Tanks a lot.

from vrp.

I think it should be possible: if I'm not mistaken, only problem validation prevents it at the moment:

https://github.com/reinterpretcat/vrp/blob/master/vrp-pragmatic/src/validation/vehicles.rs#L91

If you pass true for last parameter (skip_intersection_check), then it should not throw validation error for time window intersection. You can try it locally. For release, I would need to test it a bit

from vrp.

Thanks a lot.
I am not 100% sure about how passing the parameter skip_intersection_check in javascript context, but I'll try.

from vrp.

I meant that you can checkout the source code, modify the line above, build binaries locally and test it

from vrp.

Ok. I'll get it. Thanks

from vrp.

I am currently updating my application with the latest version of vrp_cli (v.1.18.1), and it seems that the tag for vehicle shift breaks is not passed to the solution.
In a previous version, the tag was available under jobTag. Is there some change in the pragmatic format? But looking at the doc, it seems not, but I may have missed something ?
Thanks,

from vrp.

Hi,

no, there was no changes in api contract. I'll check it once I have time (just returned from vacation).

Update: actually, there is can_assign_break_between_jobs test which validates tag assignment in the solution for a break activity and it passes. Do you have a minimal reproducible example?

from vrp.

Sorry, it is my fault.
In a previous version, breaks were slightly different.
At that time, tag was just on the first level:

"breaks": [
  {
    "time": [
      "2019-07-04T12:00:00Z",
      "2019-07-04T14:00:00Z"
    ],
  "duration": 3600.0,
  "locations": [
    {}
  ],
  "tag": "testTag"
}

This is not the case anymore, as clearly stated in our docs...

"breaks": [
  {
    "time": [
      "2019-07-04T12:00:00Z",
      "2019-07-04T14:00:00Z"
    ],
    "places": [
      {
        "tag": "testTag",
        "duration": 3600.0
      }
    ]
  }
]

Sorry for the trouble, and thanks again

from vrp.