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
The input format gap is where most operations research tools lose to their commercial alternatives. Academic solvers are often more powerful than what ships inside mainstream software, but the data bridge problem kills adoption before the solver quality ever gets a fair test.
CSV and XLSX support isn't glamorous to build, but it changes who can actually use the tool. The difference between "technical contact who knows what a .vrp file is" and "operations manager with a spreadsheet" is the difference between a research user and a paying customer. The second group is where the revenue is.
Keeping the optimization core separate from the input layer is the right call. The solver stays clean, the runtime handles messy real-world formats, and you don't have to rewrite anything when a new format shows up.
What's the most common edge case you're seeing in the CSV imports so far?
Thanks. In my current validation, I’m actually testing the CSV layer against the original benchmark instances rather than using unrelated CSV data.
I take the same benchmark problem that GSL has already solved, convert that instance into the unified CSV representation, and then run the CSV through the GSL Runtime.
The important part is that GSL is deterministic, so I’m not only checking whether the CSV can be parsed. I use the GSL engine itself as the audit layer to verify that the converted input still represents the same underlying problem — producing the same optimization result and route structure as the original instance.
I’ve now completed this CSV/ZIP validation across all four current modules: CVRP, VRPTW, MDVRP and MDVRPTW.
The next challenge is less about parsing a single CSV edge case and more about making the input layer robust enough for XLS/XLSX and eventually real operational datasets.
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?
Not a messy enterprise dataset yet — I’m deliberately validating the input layer against the benchmark datasets that GSL already uses for its solver evaluation.
For each test, I start with the original benchmark instance, convert it into the unified CSV format, and then also package it as ZIP.
The GSL Runtime then has to recover the same underlying problem from the different file paths. Because the GSL solver is deterministic, I can use the original instance as the reference and audit whether the CSV/ZIP path produces the same result and route structure.
I’ve now completed this validation for CVRP, VRPTW, MDVRP and MDVRPTW.
The “messy real-world data” part comes next. XLS/XLSX is the next runtime layer I’m working on, and that will be much closer to the kind of variability you see in actual company spreadsheets.
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.
Thanks! That separation is intentional. I want the optimization core to remain stable while the runtime/input layer evolves around the formats used in actual workflows.
XLS/XLSX is the next interesting step, so I’ll share the results once the runtime validation is further along.
Makes sense. I actually sent you an email earlier as well — happy to continue the conversation there. Would be good to hear your thoughts when you get a chance.