profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/krypt-n/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.
mfunk krypt-n person, (sometimes) doing stuff

krypt-n/bar 177

Fork of bar ain't recursive - A lightweight xcb based bar. This is a hot mess, do not use

sasjonge/bl-lecture-notes 2

Dies ist eine Mitschrift/Zusammenfassung zur Vorlesung "Beschreibungslogik" (SoSe2016) von Thomas Schneider an der Universität Bremen.

krypt-n/bl-lecture-notes 0

Dies ist eine Mitschrift/Zusammenfassung zur Vorlesung "Beschreibungslogik" (SoSe2016) von Thomas Schneider an der Universität Bremen.

krypt-n/vroom 0

Vehicle Routing Open-source Optimization Machine

krypt-n/zetavm 0

Multi-Language Platform for Dynamic Programming Languages

PR opened VROOM-Project/vroom

Update API.md

The link for Solving Mode was not working as it was wrong.

This updates the link.

Issue

#511

Tasks

  • [ ] ...
  • [ ] Update docs/API.md (remove if irrelevant)
  • [ ] review
+1 -1

0 comment

1 changed file

pr created time in 2 days

issue openedVROOM-Project/vroom

Link for Solving Mode in API.md is wrong

The link in the mentioned file is given as #mode, which is wrong and does not work. The correct link will be #solving-mode.

created time in 2 days

issue openedVROOM-Project/vroom

vroom/libvroom_examples/libvroom.cpp compiling error

vroom/libvroom_examples/libvroom.cpp(218,42): error C2664: 'vroom::Matrixvroom::Cost::Matrix(size_t)': cannot convert argument 1 from 'initializer list' to 'size_t'

created time in 2 days

issue openedVROOM-Project/vroom

Reduce local search operators scope

The current way local search operators look up for neighboring solutions is a bit naive in that we exhaustively check all options for routes / pairs of routes. Obviously relocating a job in another route at a rank where tasks are very far away does not make sense. In that case we stop early without any validity check because the gain itself is not interesting. Yet probably a lot of time is actually spent evaluating gain for silly moves.

I recall toying with more advanced filtering in the early days of the implementation, e.g. only trying a relocate move to the nearest routes or ranks in routes. From what I recall, it did have a detering impact on quality (some interesting moves missed in the process) and the computing gain was not that relevant because the overall approach was "fast enough" as a first implementation.

Now I think would be a good time to evaluate the speedups we could get from this idea. The question is whether we'll be able to easily find the sweet spot between unnecessary evaluation and missed moves. Either we can come up with some threshold where we'll only miss a marginal number of moves, either we can maybe make this configurable to some extent.

created time in 2 days

issue openedVROOM-Project/vroom

Rework heuristic / exploration level logic

The -x flag sets a trade-off between "exploration level" (hence computing time) and solution quality one can hope to reach. It actually acts on two different factors:

  1. Spawning more or less parallel searches (those run totally independently for now, and are based on various predefined heuristic tunings).
  2. Pushing each of the searches further by adding steps where we incrementally rework bigger parts of the solution in order to get out of a local search minima.

At the end of the day, only the search yielding the best solution is "used", so running 32 searches in parallel (-x 5) is somehow a waste of resources. We've been doing it this way so far because of course we don't know beforehand which of the heuristic tunings will lead to the best solution, and it works ™.

It would be interesting to explore how we could narrow down the number of searches during optimization, only keeping the most promising ones depending on the context.

My hopes here is to be able to reduce "unproductive" computing times, which could bring faster convergence, or an intensification of the search on more promising leads without increasing the overall computing effort.

created time in 2 days

issue commentVROOM-Project/vroom

Add SWAP* operator

Note: the question of validity is not accounted for in the above paper, since HGS-CVRP maintains a population of infeasible solutions, and also validity is trivial for a plain CVRP.

We'd have to adjust this to embed the various required checks for the situations we cover (CVRP + backhauls, TW).

jcoupey

comment created time in 2 days

issue openedVROOM-Project/vroom

Add SWAP* operator

Our local search relies on various SWAP-like neighborhoods that will perform in-place exchanges of tasks (or pair of tasks), either between two different routes, or in the same route. For example the Exchange operator typically will spot situations like the following (edges are gray before applying and red after):

exchange_after

But requiring that both jobs take each other's place in the other route is very limiting and we're missing situations where the real gain would happen when moving tasks across routes while changing their respective ranks. Probably this can happen sometimes during the current search with two subsequent relocate moves but again in a very limited manner: the intermediate state has to be both valid (capacity, TW) and interesting in term of gain.

The drawback of this kind of move is that the a priori complexity is O(n^4) where n is the typical route length. Fortunately, this recent paper from Thibaut Vidal shares a clever way to reduce the required exploration, yet making sure to spot the best new insertion ranks. This brings down the operator lookup complexity to O(n^2).

So it appears we could have our cake and eat it too by superseding the existing Exchange operator with SWAP*: we'd then be able to reach out to more relevant neighboring solutions while not increasing the overall complexity.

created time in 2 days

push eventphate/jlm

Nico Reissmann

commit sha b04352cd270850dc72953fac6eef6ff1b4449103

TODO

view details

push time in 3 days

push eventphate/jlm

Nico Reissmann

commit sha a81a105c4a24adbe77ad5006ffdfa9c91e02e3ad

TODO

view details

push time in 4 days

issue commentVROOM-Project/vroom

Please an explanation about "matrices"

I haven't the last version with the multi profile, but i was asking about this case when i discover the multi profile functionnality. I am getting the last version and i will try and answer the question.

alfredorico

comment created time in 4 days

issue commentVROOM-Project/vroom

Please an explanation about "matrices"

@JonasESEO did you try running vroom on your latest example?

alfredorico

comment created time in 4 days

issue commentVROOM-Project/vroom

Please an explanation about "matrices"

Hello Julien, I have questions about profiles in matrices. I see, in your api and your examples, that you use profiles like Car or Bike.

API.md

"matrices": {
	"car": {
		"durations": [[0, 14], [21, 0]]
	},
	"bike": {
		"durations": [[0, 57], [43, 0]]
	}
}

Is it an obligation to use name profile that OSRM knows ?

example_2.json

{
  "vehicles": [
	{
	  "id":0,
	  "start_index":0,
	  "end_index":3
	}
  ],
  "jobs": [
	{
	  "id":1414,
	  "location_index":1
	},
	{
	  "id":1515,
	  "location_index":2
	}
  ],
  "matrices": {
	"car": {
	  "durations": [
		[0,2104,197,1299],
		[2103,0,2255,3152],
		[197,2256,0,1102],
		[1299,3153,1102,0]
	  ]
	}
  }
}

Why the key profile have not be add to vehicle in the example_2 ?

Below, an example of how i want to use do you think it's possible ?

{
  "vehicles": [
	{
              "profile": "Mercedes"
	  "id":0,
	  "start_index":0,
	  "end_index":3
	},
  	{
              "profile": "Peugeot"
	  "id":0,
	  "start_index":0,
	  "end_index":3
	}
  ],
  "jobs": [
	{
	  "id":1414,
	  "location_index":1
	},
	{
	  "id":1515,
	  "location_index":2
	},
	{
	  "id":1616,
	  "location_index":0
	}
  ],
  "matrices": {
	"Mercedes": {
	  "durations": [
		[0,2104,197,1299],
		[2103,0,2255,3152],
		[197,2256,0,1102],
		[1299,3153,1102,0]
	  ]
	},
            {
	"Peugeot": {
	  "durations": [
		[0,2124,206,1325],
		[220,0,2277,3180],
		[220,2290,0,1120],
		[1325,3185,1120,0]
	  ]
	}
  }
}
alfredorico

comment created time in 5 days

issue commentVROOM-Project/vroom

minimum load / vehicle

Got it. First you need to check your solutions on why higher capacity vehicles are not used fully (hint above: it's probably cheaper). This will provide some pointers on how to design your fleet to get a solution that better fits your use-case.

vercom

comment created time in 5 days

issue commentVROOM-Project/vroom

minimum load / vehicle

Hello, in my case if 12 persons are at the same pickup location at the same time and only 8 persons can step on the bus which has place for 16 people , the 4 persons that have to wait for a minivan will not be very understanding. There we are prepared to spend more time on the route. We are working with people and not cargo !

vercom

comment created time in 5 days

issue closedVROOM-Project/vroom

waiting_time in shipments

hi I don't understand very well the sense for which the waiting_time field appears in the step delivery in solution

the same shipment in input has the time_windows in pickup for example ship 1 that has pickup ad 9:00 in output have a wating_time.. I would expect a pickup at 09:00 and a wating_time in it delivery step

summary of the situation

ship 1 - pickup 09:00       
ship 2 - delivery 08:00
ship 3 - pickup 11:00

output:

START at 07:38 
ship 2 at 07:48 - pickup
ship 2 at 08:05 - delivery
ship 1 at 08:19 - pickup - wating 00:40 
ship 1 at 09:02 - delivery
ship 3 at 09:09 - pickup - waiting 01:50 
ship 3 at 11:03 - delivery
END at 11:10 

detailes jsons

VROOM INPUT PROBLEM:

{"vehicles": [{"id": 1,
   "capacity": [1],
   "profile": "driving-car",
   "start": [11.106489999999999, 46.219789999999996],
   "end": [11.106489999999999, 46.219789999999996],
   "time_window": [1619420400, 1619463600]}],
 "shipments": [
{
    "pickup": {
        "id": 1,
        "location": [11.15076382314735, 46.203298111250554],
        "time_windows": [[1619427600, 1619427900]]},
    "delivery": {
        "id": 1,
        "location": [11.157356081140591, 46.20601432482854]
   },
   "amount": [1]
},
  {"pickup": {"id": 2, "location": [11.156299857014982, 46.19019295043586]},
   "delivery": {"id": 2,
    "location": [11.082415699990579, 46.21197332251006],
    "time_windows": [[1619424000, 1619424300]]},
   "amount": [1]
},
  {"pickup": {"id": 3,
    "location": [11.130646607615002, 46.19056828643731],
    "time_windows": [[1619434800, 1619435100]]},
   "delivery": {"id": 3, "location": [11.157267525947862, 46.217633275365145]},
   "amount": [1]
}
],
 "jobs": []}

VROOM SOLUTION:

{
  "code": 0,
  "unassigned": [],
  "routes": [
    {
      "steps": [
        {
          "type": "start",
          "location": [11.10649,46.21979],
          "load": [0],
          "arrival": 1619422710,
          "duration": 0,
          "distance": 0
        },
        {
          "type": "pickup",
          "location": [11.156299857014982,46.19019295043586],
          "id": 2,
          "service": 0,
          "waiting_time": 0,
          "job": 2,
          "load": [1],
          "arrival": 1619423296,
          "duration": 586,
          "distance": 6909
        },
        {
          "type": "delivery",
          "location": [11.08241569999058,46.21197332251006],
          "id": 2,
          "service": 0,
          "waiting_time": 0,
          "job": 2,
          "load": [0],
          "arrival": 1619424300,
          "duration": 1590,
          "distance": 22654
        },
        {
          "type": "pickup",
          "location": [11.15076382314735,46.203298111250554],
          "id": 1,
          "service": 0,
          "waiting_time": 2428,
          "job": 1,
          "load": [1],
          "arrival": 1619425172,
          "duration": 2462,
          "distance": 33169
        },
        {
          "type": "delivery",
          "location": [11.157356081140591,46.20601432482854],
          "id": 1,
          "service": 0,
          "waiting_time": 0,
          "job": 1,
          "load": [0],
          "arrival": 1619427756,
          "duration": 2618,
          "distance": 33817
        },
        {
          "type": "pickup",
          "location": [11.130646607615002,46.19056828643731],
          "id": 3,
          "service": 0,
          "waiting_time": 6659,
          "job": 3,
          "load": [1],
          "arrival": 1619428141,
          "duration": 3003,
          "distance": 37814
        },
        {
          "type": "delivery",
          "location": [11.157267525947862,46.217633275365145],
          "id": 3,
          "service": 0,
          "waiting_time": 0,
          "job": 3,
          "load": [0],
          "arrival": 1619435039,
          "duration": 3242,
          "distance": 41720
        },
        {
          "type": "end",
          "location": [11.10649,46.21979],
          "load": [0],
          "arrival": 1619435424,
          "duration": 3627,
          "distance": 47399
        }
      ],
      "geometry": "............"
    }
  ]
}

closed time in 5 days

stefanocudini

issue commentVROOM-Project/vroom

waiting_time in shipments

Closing as answered.

stefanocudini

comment created time in 5 days

issue closedVROOM-Project/vroom

speed_factor

Is vehicle speed_factor already implemented in latest docker version ? I see no change in duration using this factor.

I would like to use this factor to correct duration or is there another way to correct duration with traffic information ?

closed time in 5 days

vercom

issue commentVROOM-Project/vroom

speed_factor

Now released and included in the latest Docker image.

vercom

comment created time in 5 days

PR closed VROOM-Project/vroom

Minor typos
+3 -3

1 comment

1 changed file

JakobMiksch

pr closed time in 5 days

issue commentVROOM-Project/vroom

Existing route plan not found

Further investigations point to a wrong upper bound value that is derived from a too small expected planning horizon end. In this loop, we decide how to push the planning horizon end so as to allow lateness. It looks like this currently overestimates actual violations in cases where tasks have no time window, thus stopping too early with a "too low" horizon end.

jcoupey

comment created time in 5 days

issue openedVROOM-Project/vroom

Existing route plan not found

I stumbled on a situation where an "Infeasible route" exception is thrown in plan mode, but the only hard constraint passed in input is a service_after value for start step, so no matter the violation level, a route should be found.

The problem happens because the upper bound for the start step is actually lower than the lower bound in this check. This is usually the sign of too tight timing constraints but here there is no constraints on upper values.

created time in 5 days

issue commentVROOM-Project/vroom

minimum load / vehicle

No there is no such option to ensure a minimum load.

The fact that you are getting under-loaded vehicles in output is a consequence of how the fleet size/availability/spread matches the demand. Imposing this as a new constraint (or using a two-step solving approach) will only narrow down the solving options and result in a more expensive solution in term of overall travel time.

In short: you're probably getting solutions with not all vehicles full because it's cheaper that way based on the current optimization objective. What I'd like to know is: if you're prepared to spend more time on the route in order to fill the vehicles, then what makes this option more interesting in your use-case?

vercom

comment created time in 6 days

issue openedVROOM-Project/vroom

minimum load / vehicle

Is it possible to have a minimum load for each type of vehicle. The problem that I have to solve is shipping different workers to different locations with vans. There are vans for 8 people and vans for 16 people. I want 16 persons busses to transport more than 8 people.

example situation : I have to pickup 130 persons at 50 different locations and bring them to 4 companies. there are timewindows defined for each pickup and delivery.

I have 50 minivans with a capicity of 8 persons and 4 busses with a capacity of 16 persons available.

the number of persons, minivans and busses available, changes every day.

So I think I have to solve this problem in a few steps.

Step 1 solve with only the available number of busses for 16 persons. ->( here I would have the minimum load ) Step 2 Exclude the persons already solved in step 1 and solve the remaining shipments with only minivans.

For step 2 : In order to solve the problem with a minimum number of vehicles, I know that if I try with 100 minivans only the minivans needed will be used. (in this case there will be no fare sharing).

Maybe there's a better solution for this ?

created time in 6 days

push eventphate/jlm

Nico Reissmann

commit sha d8fa159a5a7d2c7ee6a568da08c7b7a73b6ee1c3

libjlm/ir: add region-check to lambda::node::finalize method

view details

Nico Reissmann

commit sha 8b7b1844f17aceac41bfb4a4a2a29fa4166646c7

libjlm/util: add disjoint-set data structure

view details

Nico Reissmann

commit sha f22a2e12fba63a40a78666b0bcbef6b18b7a7f0f

libjlm/opt: add lambda_aamux and call_aamux operators

view details

Nico Reissmann

commit sha 354a80b2dd5c875231c733e187d85ce25deeffee

libjlm/opt: add points-to graph data structure

view details

Nico Reissmann

commit sha f2fd6e8d03d003b4de862d37863818d30d74c8d7

tests: add alias analysis tests

view details

Nico Reissmann

commit sha 157b87e4cdd611389e32d9e21714f10033641e72

libjlm/opt: add Steensgaard alias analysis

view details

Nico Reissmann

commit sha 5beab26c93c9e0afe212a90fbefe0cfa61bfecbd

jlm-opt: add command line flag for Steensgaard alias analysis optimization

view details

Nico Reissmann

commit sha cabd3609e6edaf57e1405b73f2785b1416e7a772

TODO

view details

Nico Reissmann

commit sha 7430ba9b4b07a8b95d051b1ba6607510bad8a135

TODO

view details

Nico Reissmann

commit sha ea89bed22fb58b13f5fca6cc08a371265208bc30

TODO

view details

push time in 6 days

issue commentVROOM-Project/vroom

Vroom for pollster that makes surveys on schedules and geolocations

I don't see any problem with translating SLA into various time windows. Whatever the reason behind setting time window constraints on tasks, you'll have the guarantee that any optimized task will match those constraints (or show up as unassigned).

alfredorico

comment created time in 9 days

issue commentVROOM-Project/vroom

Please an explanation about "matrices"

Using the matrices key only makes sense if you want to bypass the routing engine to retrieve the travel durations. In that case you have to provide directly yourself the values you'd like taken into account.

The above example simply means the travel duration between places with location_index 0 and 1 will be matrices.car.durations[0][1] = 14 for a vehicle with "profile": "car" and matrices.car.durations[0][1] = 57 for a vehicle with "profile": "bike".

alfredorico

comment created time in 9 days

issue openedVROOM-Project/vroom

Needs an explanation about "matrices"

Hi,

Could any one explain to me how to use "matrices" ? I don't understand what is for. What is the meaning of "duration" key and what represent the positions of array.

"matrices": {
    "car": {
        "durations": [[0, 14], [21, 0]]
    },
    "bike": {
        "durations": [[0, 57], [43, 0]]
    }
}

Thanks in advance by your comments.

created time in 9 days

issue closedVROOM-Project/vroom

About the Special Matrix Problem

Hello to everyone,

The following sample problem is given about the use of a special matrix at this address.

{ "vehicles": [ { "id":0, "start_index":0, "end_index":3 } ], "jobs": [ { "id":1414, "location_index":1 }, { "id":1515, "location_index":2 } ], "matrices": { "car": { "durations": [ [0,2104,197,1299], [2103,0,2255,3152], [197,2256,0,1102], [1299,3153,1102,0] ] } } }

When I send this route to my server, I get the following response.

{ "code": 2, "error": "No start or end specified for vehicle 0." }

The start_index and end_index parameters took part in the problem, but I still get an error.

Thank you in advance for your support.

closed time in 9 days

Akif95

issue commentVROOM-Project/vroom

About the Special Matrix Problem

Thank u, problem solved.

Akif95

comment created time in 9 days

issue commentVROOM-Project/vroom

Vroom for pollster that makes surveys on schedules and geolocations

Thanks by your comments @jcoupey.

Any comments about third point?. I think this is important for trying achieve a planing week. For example, a job with time_windows with for example 72 hours interval, vroom output assign a Timestamp on a specific day for the job to be done inside that interval?

Thank you very much!...

alfredorico

comment created time in 9 days