Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
lucaslorentz opened this issue Dec 15, 2023 · 6 comments
Closed

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

lucaslorentz opened this issue Dec 15, 2023 · 6 comments

Comments

@lucaslorentz
Copy link

lucaslorentz commented Dec 15, 2023

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 '<unnamed>' 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: <vrp_core::solver::search::ruin::adjusted_string_removal::AdjustedStringRemoval as vrp_core::solver::search::ruin::Ruin>::run
   6: <vrp_core::solver::search::ruin::CompositeRuin as vrp_core::solver::search::ruin::Ruin>::run
   7: <vrp_core::solver::search::ruin_recreate::RuinAndRecreate as rosomaxa::hyper::HeuristicSearchOperator>::search
   8: rosomaxa::hyper::dynamic_selective::SearchAgent<C,O,S>::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: <rayon_core::job::StackJob<L,F,R> as rayon_core::job::Job>::execute
  15: rayon_core::registry::WorkerThread::wait_until_cold
  16: rayon_core::registry::ThreadBuilder::run
@lucaslorentz
Copy link
Author

lucaslorentz commented Dec 15, 2023

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
Copy link
Owner

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
Copy link
Author

lucaslorentz commented Dec 15, 2023

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
Copy link
Owner

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
Copy link
Owner

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

@lucaslorentz
Copy link
Author

lucaslorentz commented Dec 15, 2023

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.

reinterpretcat added a commit that referenced this issue Dec 22, 2023
This release combines many changes, but essentials are:
- internal route state api simplification
- increased performance
- several experimental features
- bug fixes

* original job place index in activity place to simplify activity-job
 place matching
* `experimental`: a new type of location in pragmatic format to model
 zero distance/duration from it to any other location.
  This could be useful to model optional vehicle start location.
* allow user to pass alternative objectives in goal context to guide
 the search
* `experimental`: a new `fast-service` objective function to serve jobs
 as soon as possible

* experimental `dispatch` feature

* apply code style refactoring
* improve selection sampling search
* update dependencies
* improve a bit documentation
* refactor route state
* do not use hashmaps to store activity states

* double reload assignment when initial solution is used (#126)
* unexpected total_order behavior in dynamic heuristic (#128)
* improve validation rule for break with time offset  (#129)
* fix issue with skills (#133)
* do not cluster jobs if they are defined in relations (#141)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants