Error - called `Option::unwrap()` on a `None` value

[lucaslorentz]

Hey, congrats on the project! I'm considering adopting it and I'm doing some tests.

All more common stuff worked very well for me so far. But I'm getting this error on a specific scenario:

called `Option::unwrap()` on a `None` value

I carefully deleted everything in my scenario until I got the minimal reproducible problem. Turns out it is a problem when combining:

• 2 jobs with same location
• vinicity clustering
• and relations

Could you please have a look? I hope you can easily fix it with the info below.

Problem

``` { "plan": { "jobs": [ { "id": "job_1", "pickups": [], "deliveries": [ { "places": [ { "location": { "lat": -23.6201069, "lng": -46.7615237 }, "duration": 1.0 } ], "demand": [1] } ], "services": [] }, { "id": "job_2", "pickups": [], "deliveries": [ { "places": [ { "location": { "lat": -23.6201069, "lng": -46.7615237 }, "duration": 1.0 } ], "demand": [1] } ], "services": [] } ], "relations": [ { "type": "any", "jobs": ["job_1"], "vehicleId": "vehicle_1" } ], "clustering": { "type": "vicinity", "profile": { "matrix": "bike", "scale": 0.5 }, "threshold": { "duration": 30.0, "distance": 30.0 }, "visiting": "continue", "serving": { "type": "original", "parking": 1.0 } } }, "fleet": { "vehicles": [ { "typeId": "bike", "vehicleIds": ["vehicle_1"], "profile": { "matrix": "bike" }, "costs": { "fixed": 0.0, "distance": 0.0002, "time": 0.005 }, "shifts": [ { "start": { "earliest": "2023-12-15T00:00:00+01:00", "location": { "lat": -23.5415617, "lng": -46.7139935 } }, "end": { "latest": "2023-12-25T00:00:00+01:00", "location": { "lat": -23.5415617, "lng": -46.7139935 } } } ], "capacity": [30] } ], "profiles": [{ "name": "bike" }] } } ```

Stacktrace

``` thread '' panicked at /Users/lucas/.cargo/registry/src/index.crates.io-6f17d22bba15001f/vrp-core-1.22.1/src/models/problem/jobs.rs:245:58: called `Option::unwrap()` on a `None` value stack backtrace: 0: rust_begin_unwind at /rustc/a28077b28a02b92985b3a3faecf92813155f1ea1/library/std/src/panicking.rs:597:5 1: core::panicking::panic_fmt at /rustc/a28077b28a02b92985b3a3faecf92813155f1ea1/library/core/src/panicking.rs:72:14 2: core::panicking::panic at /rustc/a28077b28a02b92985b3a3faecf92813155f1ea1/library/core/src/panicking.rs:127:5 3: vrp_core::models::problem::jobs::Jobs::neighbors 4: vrp_core::solver::search::utils::selection::select_neighbors 5: ::run 6: ::run 7: ::search 8: rosomaxa::hyper::dynamic_selective::SearchAgent::search 9: rayon::iter::plumbing::Folder::consume_iter 10: rayon::iter::plumbing::bridge_producer_consumer::helper 11: rayon_core::join::join_context::{{closure}} 12: rayon_core::registry::in_worker 13: rayon::iter::plumbing::bridge_producer_consumer::helper 14: as rayon_core::job::Job>::execute 15: rayon_core::registry::WorkerThread::wait_until_cold 16: rayon_core::registry::ThreadBuilder::run ```

[lucaslorentz]

Forgot to mention, but error seems to be different from #140.

It fails with manhattan distances as well, no need to use a custom matrix.

[reinterpretcat]

Hi, thanks for feedback!

Just to note: vicinity clustering is pretty an experimental feature.

I've briefly checked the problem and seems related to relation feature usage with vicinity feature. The root cause (most likely, still investigating) is that job1 and job2 are merged into one job in preprocessing step and this new job is used in internal job registry, not old ones. Possible solutions so far:

• add validation rule to disallow usage of these two features together (no my favorite)
• do not cluster jobs which are defined in relations (so far, preferable)

I guess you want to have two jobs to be clustered and then assigned to specific vehicle. I would need to think how to make this possible if you don't want upfront which jobs can be clustered together (otherwise you can use skills to lock them to specific vehicle)

[lucaslorentz]

Interesting, thanks for the info. So, the clustering logic does take "skills" into account, but not yet "relations". I also got it working by using "compatibility" to prevent clustering of those jobs, but I will probably change to use skills, like you suggested.

[reinterpretcat]

Yes, adding different skills/compatibility will prevent jobs to be clustered.

I'll will fix the issue to avoid panic by preventing jobs from relation to be clustered.

[reinterpretcat]

I've added the fix into the current master, will take some time to release all the changes

[lucaslorentz]

Thanks for the improvement. Ideally, the configured relations should separate jobs in different clusters, instead of preventing them from clustering.

I will stop using clustering for now. Just realized I don't need it. I was using it mostly to group the same location into a single stop, but I believe this is done already even without clustering.