Show IH:GSL Runtime: Moving Beyond .vrp Input
A small but meaningful milestone in the ongoing development of GSL Solver.
GSL originally worked primarily with ".vrp" routing instances. These are already highly structured optimization problems and are great for research benchmarks.
But company data usually doesn't arrive as a research benchmark file.
It can come from CSV exports, spreadsheets, operational tables, or compressed packages.
So I’m extending the GSL Runtime input layer to handle these more practical data paths.
So far, I’ve validated two modules:
CVRP
- ".csv" → GSL → Solver → 126,087.33
- ".zip" → extract ".vrp" → GSL → Solver → 126,087.33
VRPTW
- ".csv" → GSL → Solver → 3,178.01
- ".zip" → extract Solomon ".txt" → GSL → Solver → 3,178.01
The interesting part for me is that the input path can change while the optimization core remains the same.
The ZIP component is simply a runtime layer for inspecting, extracting, and passing the routing input into GSL. It is not a new solver.
I’m now working on XLS/XLSX runtime support. Once the input layer is mature enough, the plan is to bring these formats into the web portal together with clear format specifications and templates.
Current development:
✅ CVRP runtime validation
✅ VRPTW runtime validation
🚧 XLS/XLSX runtime
🚧 MDVRP
🚧 MDVRPTW
🚧 Web portal
Still building — one runtime layer at a time.
#GSL #Optimization #OperationsResearch #Logistics #BuildInPublic
Looks like plumbing but it's the most commercially important thing you've shipped, and you said why yourself: "company data doesn't arrive as a research benchmark file." The gap between a solver that wins on .vrp benchmarks and a product a logistics company can use is exactly this input layer. Most optimization projects die there, brilliant core but getting messy data in needs a PhD, so nobody adopts.
CSV and ZIP landing on identical results (126,087.33) is the proof that matters: a dispatcher hands you a spreadsheet and trusts the answer without understanding the format underneath. That's the line between "impressive research" and "tool my ops team can run."
XLS/XLSX next is right, that's where company data lives. Messiest real input you've thrown at it?
That’s a useful milestone. Keeping the optimization core unchanged while expanding the input layer seems like a sensible way to make GSL more practical without complicating the solver itself.
Interested to see how the XLS/XLSX support turns out.