oj! Algorithms

Using the Optimisation Service

2026-10-02T00:00:00Z

Optimisation-as-a-Service was introduced four years ago. It has since been reworked substantially and now runs native solvers — HiGHS, SCIP and Clarabel — alongside ojAlgo’s own, behind the same ExpressionsBasedModel code you already have.

This post walks through three steps:

Run your existing ExpressionsBasedModel code against a public test server.
Deploy your own instance.
Add a licence key to enable the native solvers and multi-core solving.

1 – Try It with the Public Test Server

The example uses the service’s client library. It is one Maven dependency with no transitive dependencies of its own:

<dependency>
    <groupId>se.optimatika</groupId>
    <artifactId>optimisation-service-client</artifactId>
    <version>1.0.0</version>
</dependency>

The client is optional — the service has a plain REST API that any language can call — but with ojAlgo it is by far the simplest route.

The example below makes an ExpressionsBasedModel solve remotely, on a public test server we have made available. It runs as it is, and the comments show the two things you change in your own code: create the model from an environment configured with a remote solver, and call submit(Sense) instead of minimise() or maximise().

Example Code

OptimisationAsAService.java

import java.util.concurrent.ExecutionException;
import java.util.concurrent.Future;

import org.ojalgo.OjAlgoUtils;
import org.ojalgo.netio.BasicLogger;
import org.ojalgo.optimisation.ExpressionsBasedModel;
import org.ojalgo.optimisation.Optimisation;
import org.ojalgo.optimisation.Optimisation.Environment;
import org.ojalgo.optimisation.Optimisation.Result;
import org.ojalgo.optimisation.Optimisation.Sense;
import org.ojalgo.optimisation.Variable;

import se.optimatika.optimisation.service.client.OptClientV1;

/**
 * A program that shows how to use Optimatika's Optimisation-as-a-Service.
 *
 * @see https://www.ojalgo.org/2026/10/using-the-optimisation-service/
 * @see https://www.ojalgo.org/2022/10/optimisation-as-a-service/
 */
public class OptimisationAsAService {

    public static void main(final String[] args) throws InterruptedException, ExecutionException {

        BasicLogger.debug();
        BasicLogger.debug(OptimisationAsAService.class);
        BasicLogger.debug(OjAlgoUtils.getTitle());
        BasicLogger.debug(OjAlgoUtils.getDate());
        BasicLogger.debug();

        /*
         * Create a client for the optimisation service.
         */

        OptClientV1 client = OptClientV1.newInstance("https://optimisation-test-service-840974723912.europe-north2.run.app");

        /*
         * Verify the service is up and running.
         */

        if (!client.isServiceAvailable()) {
            BasicLogger.error("Service is not available!");
            return;
        }

        BasicLogger.debug("Service environment: {}", client.getServiceEnvironment());

        /*
         * If you already have a working model built using ojAlgo's ExpressionsBasedModel you can use that as
         * is. Here's how:
         */

        Environment environment = Optimisation.newEnvironment();
        /*
         * Even if you never used Optimisation.Environment before, there is always an implicit default
         * environment. What we did here is simply to create a separate environment to use explicitly. Then
         * configure that to use a remote solver.
         */
        environment.setRemoteSolver(client::putOnQueue, client::pollResult);
        /*
         * Finally, use the environment as the model factory.
         */
        ExpressionsBasedModel model = environment.newModel();

        /*
         * Let's just build a trivial model...
         */

        Variable varA = model.newVariable("A").lower(0).weight(10);
        Variable varB = model.newVariable("B").lower(0).weight(-10);

        model.newExpression("SumIs2").set(varA, 1).set(varB, 1).level(2);

        /*
         * Now, to actually solve remotely, call model.submit(Sense)
         */

        Future<Result> max = model.submit(Sense.MAX);
        /*
         * Submitting a large MIP model to solve remotely, it may take a while before you get the response.
         */
        Result result = max.get();

        BasicLogger.debug();
        BasicLogger.debug("Maximised => state={}, value={}", result.getState(), result.getValue());
        BasicLogger.debug("A={}, B={}", result.get(0), result.get(1));

        Future<Result> min = model.submit(Sense.MIN);
        result = min.get();

        BasicLogger.debug("Minimised => state={}, value={}", result.getState(), result.getValue());
        BasicLogger.debug("A={}, B={}", result.get(0), result.get(1));

        // To summarise what you need to do in code:
        //
        // 1) Create the model instance using an environment configured to solve remotely
        // 2) Solve using model.submit(Sense) rather than model.minimise() or model.maximise()
        //
        // Nothing else!

    }

}

Console Output

class OptimisationAsAService
ojAlgo
2026-10-01

Service environment: {"build":{"module":"polar","built":"2026-09-23T14:49:34Z","commit":"ba4f80c","branch":"develop","dirty":"false"},"runtime":"1GB/4threads x86_64 [2GB/8threads, 8MB/8threads, 256kB/2threads, 32kB/2threads]","licence":"Polar (max 4 vCPUs, full solver suite — 2/2 keys valid: 2df1722d granted 2 vCPU; b7a3f2aa granted 4 vCPU)","solvers":{"probed":true,"available":["LP-Clarabel","LP-HiGHS","LP-JVM","LP-SCIP","MILP-HiGHS","MILP-JVM","MILP-SCIP","MIQCLP-SCIP","MIQCQP-SCIP","MIQP-JVM","MIQP-SCIP","QCLP-Clarabel","QCLP-SCIP","QCQP-Clarabel","QCQP-SCIP","QP-Clarabel","QP-HiGHS","QP-JVM"]}}

Maximised => state=OPTIMAL, value=20.0
A=2, B=0
Minimised => state=OPTIMAL, value=-20.0
A=0, B=2

The licence and solvers fields show the test server running the full solver suite — HiGHS, SCIP and Clarabel alongside ojAlgo’s own. It is for experimentation only — restricted on problem size and solve time, and it may be removed at any time. Don’t send it anything confidential. For real use, run your own instance.

2 – Deploy Your Own Instance

The service ships as a public container image, so it runs anywhere containers run. No registry account or credentials are needed:

ghcr.io/optimatika/optimisation-service

Each of the major clouds has a product that deploys a container with little more than the image name:

AWS — Amazon ECS Express Mode (the successor to App Runner)
GCP — Cloud Run
Azure — Container Apps

We find Google Cloud Run particularly convenient. With a GCP account and the Google Cloud CLI installed, this is all it takes:

gcloud run deploy my-opt-serv-test \
  --image ghcr.io/optimatika/optimisation-service \
  --region europe-north1 \
  --cpu 4 \
  --memory 2Gi \
  --max-instances 1 \
  --allow-unauthenticated

The image is the only fixed part; name, region, CPU and memory are up to you. Two of the flags matter more than they look:

--max-instances 1 — results are held in memory by the instance that solved them. With several instances, a poll can reach one that has never seen your model. To scale out, run separate services rather than letting one service autoscale.
--allow-unauthenticated — makes the instance reachable by anyone who has the URL. The service has no authentication of its own; it is designed to sit inside your network. That is fine for a short test from your laptop. For anything else, restrict who can reach it: --ingress internal limits it to your own VPC, or put an authenticating gateway in front of it. The security notes in the documentation cover this.

By default Cloud Run allocates CPU only while it is handling a request, and the service solves in the background between polls. In our tests that made no practical difference — a MIPLIB model took about 12 seconds either way — but if long solves seem to stall, --no-cpu-throttling gives the instance CPU all the time, at the cost of paying for it while it is up.

The command prints the service URL. Later commands take the service name you chose (my-opt-serv-test), not the URL. Point OptClientV1.newInstance(...) in the example at that URL and run it again.

If you would rather click than type, the Cloud Run console does the same job. Its Create service form asks for the same things the command above passes as flags: the image URL, a service name, a region, and whether the service is publicly reachable. Set the maximum number of instances to 1 in its scaling settings before you create it.

Screenshot: the lower half of Cloud Run’s Create service form. The region shown is just an example; any region works. Allow public access is the console’s name for --allow-unauthenticated, with the same caveat as above.

Without a licence key the service runs in restricted mode: ojAlgo’s own solvers on a single core, for models of up to 1,000 variables or constraints. That is free, and enough to test your setup end to end. Once that works, the same instance becomes the full service with a licence key — nothing to redeploy.

3 – Unlock the Full Solver Suite

The native solvers and multi-core solving come with an Optimatika subscription. It gives you licence keys for the number of vCPUs in your tier, support, and access to the ojAlgo-extensions repository with the solver integrations.

A subscription issues one key per step of the ladder — a Standard subscription issues two. Supply all of them, separated by spaces, so that a later plan change never leaves the server without a valid key:

gcloud run services update my-opt-serv-test \
  --region europe-north1 \
  --update-env-vars "OPTIMATIKA_LICENCE_KEY=key-one key-two"

The update restarts the service with the keys in place. Use --update-env-vars rather than --set-env-vars: it adds the key and keeps any other variables the service has, where --set-env-vars replaces them all. The same command works on a service that is already running — nothing else about it changes. For a production service, keep the keys in Secret Manager instead of a plain environment variable (--update-secrets OPTIMATIKA_LICENCE_KEY=optimatika-licence:latest; the service account needs the Secret Manager Secret Accessor role).

To confirm the keys were accepted, ask the server what it sees:

curl -s https://your-service-url/optimisation/v1/environment

The licence field reports how many keys validated and the capacity they resolved to — for a Standard subscription, max 4 vCPUs, full solver suite — 2/2 keys valid — and solvers lists the native solvers, exactly as in the console output above.

Your data stays with you. Models, input data and results never leave your deployment — they are held in memory only and expire an hour after last access. Optimatika hosts nothing and never sees your models. The server makes one outbound call: the licence check, which sends the licence key — nothing about your models — to the payment provider to confirm the subscription is in force.

Deployment on Kubernetes, sizing, the REST API and the full configuration reference are in the Optimisation Service documentation.

MIP Benchmark: MIPLIB

2026-09-14T00:00:00Z

Previous benchmarks have covered LP and QP solvers, but never MIP solvers. The November 2025 report gave two reasons: there was no other pure Java MIP solver to compare with, and no suitable set of test models. With MIP, a tiny model can be harder than a very large one, so size alone is not a useful filter. Finding models that are hard enough to be meaningful but tractable enough that the benchmark finishes in reasonable time is a problem of its own.

Since then we found a pure Java alternative in SSC-LP, and worked on constructing a suitable test set. Here is our first-ever MIP benchmark:

The solvers

ojAlgo v57.3.0 (Java)
HiGHS v1.15.1 via ojAlgo-highs v2.0.0 (native code)
SCIP v10.0.3 via ojAlgo-scip v1.0.0 (native code)
SSC-LP v4.7.8 via ojAlgo-ssclp v1.0.0-SNAPSHOT (Java)

All four solvers are open source. ojAlgo and SSC-LP are pure Java. HiGHS and SCIP are native code. All are invoked through ExpressionsBasedModel — the three third-party solvers via ojAlgo solver integrations maintained by Optimatika. HiGHS and SCIP are also both available through the Optimisation Service. This is the first time we include SCIP in a benchmark — it is widely regarded as the strongest open-source MIP solver, with HiGHS as the up-and-coming challenger.

SSC-LP is an ambitious project — not just an LP solver but a MIP solver, with an online solver GUI as well. It is the only other pure Java solver we could find with MIP support, which is why it is included here. We have built an ojAlgo integration, but SSC-LP is licensed under GPLv3 without a linking exception, so the integration cannot be released.

The test set

The MIPLIB models are tough. It contains models no solver has ever solved, and models labeled "easy" are defined as those that at least one of the top commercial and/or academic solvers can solve within an hour — that's far beyond the scale where LP and QP benchmarks operate, and far beyond the time and compute resources we're willing to invest.

To construct our test set we started with the MIPLIB 2017 "easy" and "benchmark" models, then added models from earlier MIPLIB editions hoping to find more workable instances. Filtering to models with at most 1,000 variables and 1,000 constraints gave us 148 models. That size limit is an attempt to keep the benchmark runnable in reasonable time, but with MIP models size is a poor predictor of difficulty.

We ran preliminary benchmarks on all 148 models to determine which ones are genuinely "easy". (When doing this we also included some commercial solvers we had access to.) No solver handles all of them, and every solver succeeds on some that others fail on.

We use a time limit of 300 seconds (5 minutes) per model. A solver that does not find a proven optimal solution within that limit is marked as FAILED. There is no distinction between not being able to solve a model at all and requiring just over 5 minutes to do so.

Top commercial solvers typically solve around 90% of these models. Open source native code solvers like HiGHS and SCIP handle roughly 75%. ojAlgo reaches just under 50%.

There were 103 models that all native code solvers in our test could solve — most importantly both SCIP and HiGHS. If every native solver handles a model, it is reasonable to call it easy. This gives clean execution time comparisons, but it somewhat tilts the set in favour of native code: there are models in the full collection that ojAlgo solves and some native solvers do not (gen-ip002 and gen-ip054 are two), and those are excluded from the test set we used here.

Results

Solver	Success Rate	Solved	Fastest
SCIP	100%	103	41
HiGHS	100%	103	28
ojAlgo	62%	64	34
SSC-LP	25%	26	0

Both native code solvers solve all 103 models (as expected from the definition of the test set). ojAlgo solves 64 of them — every model with under 100 variables (21 of 21), and decreasing from there as models grow. SSC-LP, the other pure Java option, manages 26.

The x-axis is the geometric mean of SCIP and HiGHS execution times and the y-axis is each solver's execution time for the same model. Both axes are logarithmic. Because the x-axis is the native solver average, HiGHS and SCIP dots naturally scatter around the implicit diagonal — points above it are slower than the average, points below are faster. Trend lines are shown for ojAlgo and SSC-LP. The ojAlgo trend line sits below the native solvers, meaning ojAlgo is typically faster on the models it solves. SSC-LP sits well above.

SCIP edges out HiGHS overall, finishing faster on 41 models to HiGHS's 28.

SSC-LP solves 26 models — all of them small, and even on those it is the slowest solver by a wide margin. On the stein27 model SSC-LP takes over 4 minutes where ojAlgo finishes in 48 milliseconds.

Discussion

On the models ojAlgo can handle, it is remarkably fast. Of the 64 models it solves, it is the outright fastest solver — faster than both HiGHS and SCIP — on 34 of them, just over half. The median execution time for ojAlgo on those 64 models is roughly half that of HiGHS and half that of SCIP. On models with fewer than 100 variables ojAlgo solves everything, and it is the fastest solver more often than not.

That is worth repeating: on the models ojAlgo can handle, it is often faster than native code.

The gap grows with problem size and structural difficulty. Between 100 and 300 variables ojAlgo still solves most models (21 of 31) and remains competitive on speed. Above 500 variables the success rate drops — only 5 of 16 models between 500 and 750 variables, and 3 of 13 between 750 and 1,000. When ojAlgo does struggle, it struggles badly. On a handful of models — enlight_hard, vpm1, pigeon-08 — it finds the optimal solution but takes orders of magnitude longer than SCIP or HiGHS to get there.

SSC-LP, despite its ambitious scope, is not a practical alternative. Between the GPLv3 licence that prevents releasing an integration, and performance that trails every other solver by a wide margin, it does not offer a path forward for users who need more than ojAlgo alone can provide.

This does not mean ojAlgo cannot handle models with more than 1,000 variables. MIPLIB models are deliberately hard — they are curated to challenge solvers, not to represent typical workloads. And this benchmark uses a 5-minute time limit, where MIPLIB itself allows a full hour just to classify a model as "easy." Many real-world MIP models with thousands of variables have structure that solvers exploit well, and ojAlgo handles those routinely. What the benchmark does show is that on structurally difficult models, the gap between pure Java and native code widens as models grow.

Where ojAlgo is not the answer

The benchmark is clear about the limits. On very large models, structurally difficult formulations, and numerically challenging problems, ojAlgo will not match the native solvers. The 39 models it cannot solve here — and the wider set it cannot reach in the full MIPLIB collection — are not edge cases. They are the kind of models that appear in production when a business grows, a formulation tightens, or data scales up.

That is why all four solvers in this benchmark were invoked through the same ExpressionsBasedModel API. The model you write does not encode which solver runs it. Optimatika maintains a large set of third-party solver integrations — including the top commercial solvers and the best open source native solvers. Your model code does not change; you choose the solver that fits the problem.

Even with free solvers, using them directly means interfacing with native code, packaging platform-specific binaries for every target environment, and ongoing maintenance as JDK versions and solver versions move independently. That is real engineering work, and it never stops. The Optimisation Service exists to absorb it — it puts a suite of native solvers in a server you deploy in your own cluster, so your application stays pure Java while the solving moves to native code. No native code in your build, no platform-specific binaries to package, no solver licences to manage.

Methodology

The benchmark was run on a MacBook Pro with an M5 Pro chip and 48 GB of RAM. Each model-solver combination is evaluated with a time limit of 300 seconds (5 minutes). If a solver finds a proven optimal solution within the time limit, the execution time is recorded. Otherwise the model is marked as FAILED.

All solvers are invoked via ojAlgo's ExpressionsBasedModel. The time measured corresponds only to the solver-specific code — model parsing and presolve are excluded.

The benchmark code and raw results:

LP & QP Performance with v57

2026-06-27T00:00:00Z

With the release of ojAlgo v57.0.0 comes significant changes to both the LP and QP solvers, including improvements to the revised simplex and an entirely new ADMM QP solver alongside the existing active-set solver. Time to measure the results.

This is an update to the LP & QP Java Performance Report from November 2025, now with ojAlgo v57.0.0 and updated versions of the other solvers.

Solvers

ojAlgo v57.0.0 (Open Source, Java, LP & QP)
Hipparchus v4.0.3 (Open Source, Java, LP & QP)
Clarabel v0.11.1 via Clarabel4j v3.2.2 (Open Source, native code accessed from Java, QP only)
OR-Tools / GLOP v9.15.6755 (Open Source, native code, LP only)
HiGHS v1.13.1 (Open Source, native code, LP & QP)

LP: Netlib 10k

The full Netlib LP collection with up to 10,000 variables or constraints — 97 models in total.

Execution time vs number of variables

Each dot represents one model-solver pair. The x-axis is the number of variables in the model and the y-axis is the execution time. Both axes are logarithmic. Each solver has its own colour with a trend line fitted to its results.

For smaller models (up to a few hundred variables) ojAlgo is comparable to OR-Tools and HiGHS. As models grow the native code solvers pull ahead, which is expected. ojAlgo and Hipparchus have roughly the same slope, but ojAlgo is positioned significantly lower — consistently faster. Hipparchus also fails on nearly half the models.

Execution time relative to OR-Tools

The x-axis is OR-Tools (GLOP) execution time and the y-axis is each other solver's execution time for the same model. Both axes are logarithmic. The dashed diagonal represents identical performance — points above are slower, points below are faster.

The HiGHS trend line sits close to the diagonal, confirming it performs similarly to GLOP overall. ojAlgo starts near the diagonal for smaller models but diverges upward as model size increases. Hipparchus, when it solves at all, is almost always the slowest — its trend line sits well above the others.

QP: Maros & Meszaros 10k

The Maros and Meszaros collection of convex QP problems with up to 10,000 variables — 48 models.

Execution time vs number of variables

Same layout as the LP chart: each dot is one model-solver pair with the number of variables on the x-axis and execution time on the y-axis. Both axes are logarithmic. Each solver has a colour-coded trend line.

For small problems (under ~100 variables) ojAlgo is often the fastest. As models grow, Clarabel scales best. ojAlgo and HiGHS are in a similar range for medium-sized models, with ojAlgo faster more often than not. Hipparchus solves about 58% of the models and has the steepest trend line, indicating the worst scaling.

Execution time relative to Clarabel

The x-axis is Clarabel execution time and the y-axis is each other solver's execution time for the same model. Both axes are logarithmic. The dashed diagonal represents identical performance.

ojAlgo is faster than Clarabel on roughly half the models they both solve, and slower on the other half — the two are genuinely competitive. HiGHS has fewer data points because it fails on 15% of the models, including several that both ojAlgo and Clarabel handle. Hipparchus is consistently above the other trend lines when it does produce a result.

Success Rates

Being fast is good, but being able to solve the model at all is more important. A solver that fails or times out on a model scores no time — it simply doesn't appear in the charts above.

Solver	LP (97 models)	QP (48 models)
OR-Tools / GLOP	100%	—
HiGHS	100%	85%
Clarabel	—	94%
ojAlgo	99%	96%
Hipparchus	57%	58%

ojAlgo solves 96 of 97 LP models and 46 of 48 QP models. For QP, ojAlgo has the highest success rate of all solvers tested — it is the only solver that can handle HUES-MOD and HUESTIS where all others fail.

Compared to v56

The LP solver has improved steadily since v56. Success rate on the full Netlib 10k set went from 88% to 99% — models that previously timed out now solve.

The bigger story is the new ADMM QP solver. It solves more models than both Clarabel and HiGHS. On the smallest models it is the absolute fastest choice, and it is faster than HiGHS on all but some of the very largest. Only Clarabel scales better on the big end, and Clarabel is native Rust code. For a solver implemented in 100% Java this is a remarkably strong result.

Methodology

The QP benchmark was run on a MacBook Air M4 and the LP benchmark on a MacBook Pro. The exact hardware shouldn't matter much — the charts show relative performance between solvers, not absolute speed numbers.

Each model-solver combination is evaluated repeatedly until consecutive execution times stabilise within 1%. The fastest stable time is recorded. If a solver fails to find a correct solution, times out, or crashes, no time is recorded and the pair is marked as FAILED.

All solvers are invoked via ojAlgo's ExpressionsBasedModel. The time measured corresponds only to the solver-specific code — model parsing and presolve are excluded.

The benchmark code and raw results:

ojAlgo v57

2026-06-20T00:00:00Z

ojAlgo v57.0.0 has been released!

This is also the first release announced on the new ojalgo.org site, which has been rebuilt from the ground up using Eleventy replacing the old WordPress setup. The site is now fully static, fast, and easy to maintain.

New ADMM QP Solver

The highlight of v57 is a new ADMM (OSQP-style) QP solver named AlternatingDirectionSolver. The ConvexSolver.Configuration now lets you specify either the ACTIVE_SET or ADMM algorithm. If you don't specify, simple logic will select for you. The new solver also works with iterative refinement.

Optimisation Environment

A new Optimisation.Environment class holds solver integrations, presolvers, variable/expression factories, and 3rd-party configurators. Use Optimisation.newEnvironment() to create isolated configurations and Environment.newModel() as the model factory.

Revised Simplex Improvements

The revised simplex solver now freezes the constraint matrix to R064CSC before solving and uses raw double[] working vectors, reducing per-iteration allocations and improving cache locality. The SparseDecomposition (backed by SparseLU) is now the default basis engine, with an adaptive refactorisation heuristic that triggers re-decomposition based on fill-in.

Integer Solver Enhancements

The IntegerSolver gained root-phase strong-branching probes, a true global dual bound, and warm-start support for bound-only changes. Together these significantly improve branch-and-bound performance and the quality of solutions found early.

Matrix Decomposition Factors

Decompositions now expose individual factors via MatrixDecomposition.Solver.getFactors() returning List<InvertibleFactor>. Each factor supports ftran/btran operations on both PhysicalStore and raw double[] arrays.

Breaking Changes

A few changes require attention when upgrading:

ModelStrategy.initialise(...) signature simplified to no-arg. Any third-party ModelStrategy subclass needs updating.
ExpressionsBasedModel.getVariableValues() is now a cheap extraction only and returns State.UNEXPLORED. Code that relied on validated state/objective behaviour must call getVariableValuesValidated() instead.
UpdatableSolver.getEntityMap() now returns Optional<EntityMap>.
The ExpressionsBasedModel.Validator class and setKnownSolution(...) methods have been removed.
Optimisation.Result multiplier methods are deprecated in favour of getDualSolution() and getDualValues().

Read the complete change log for all the details:

https://github.com/optimatika/ojAlgo/blob/develop/CHANGELOG.md

<dependency>
    <groupId>org.ojalgo</groupId>
    <artifactId>ojalgo</artifactId>
    <version>57.0.0</version>
</dependency>

QP News

2026-01-02T17:36:04Z

Two recent releases with a lot of QP related news.

<dependency>
    <groupId>org.ojalgo</groupId>
    <artifactId>ojalgo</artifactId>
    <version>56.2.0</version>
</dependency>

<dependency>
    <groupId>org.ojalgo</groupId>
    <artifactId>ojalgo-clarabel4j</artifactId>
    <version>0.1.0</version>
</dependency>

What’s new?

ojAlgo-clarabel4j is a new 3:d party solver integration, integrating Clarabel via clarabel4j. To be honest the integration is kind of half done. Plain QP works great, but setting up all the various types of cones for more complex constraints is not yet done. There is partial support for Second-Order Cone Program (SOCP) but nothing for Exponential Cone Program, Power Cone Program or Semidefinite Program (SDP). Integrating with ExpressionsBasedModel, SOCP will be the primary cone type to support. Clarabel4j integrates with Clarabel using Java’s new Java’s new Foreign Function and Memory (FFM) API, and requires Java 25.

In ojAlgo itself the QP solver has been tuned and tweaked in several ways making it slightly faster and more robust. Then there is also a new null-space projection pre-processor (eliminating equality constraints and reducing the number of variables). Applying this, or not, may have a huge impact on performance. The problem is that it’s not so easy to determine when it should be applied. There is default logic to enable/disable this, but you really should experiment to see if it helps your case or not. (It currently does not work in combination with extended precision.)

/**
 * Null-Space projection. (Eliminating equality constraints and reducing the number of variables.)
 * <p>
 * TRUE means yes, FALSE no, and NULL auto. Even if configured to TRUE there must also be both
 * equality and inequality constraints for this to actually be used.
 */
public Configuration projection(final Boolean projection) {
    myProjection = projection;
    return this;
}

v56.2.0 also contains many sparse linear algebra improvements. Particularly in relation to R064CSC (sparse compressed columns) and a new SparseQDLDL decomposition (sparse quasi-definite LDL). This is all part of ongoing work towards an all new OSQP-based QP solver. The idea is that this will complement (not replace) the existing active set solver. Based on what I’ve seen so far the active set solver is very accurate, fast on smaller models but may struggle to find the optimal “active set” on larger models. The OSQP solver (so far) is not as accurate but appears to scale much better.

Performance

Ran the same benchmark as in the LP & QP Performance Report (the QP 1k Maros and Meszaros benchmark) but with JOptimizer replaced by Clarabel4j and the newer ojAlgo version.

LP & QP Java Performance Report

CPLEX and Hipparchus are the same (versions) as before, and nothing has changes. CPLEX handles 94% of the cases and Hipparchus 82%.

JOptimizer, that performed really poorly, has been replaced with Clarabel4j – and it performs really well. Apart from good execution times it handles all the cases (100% success rate).

ojAlgo generally performs better than in the last benchmark (slope of the curve is slightly flatter) and it handles one more case, bringing it to a 94% success rate (same as CPLEX).

Looking at the slopes of the trend lines, you may get the impression that Clarabel4j scales worse than CPLEX, and that the Java solvers scale really poorly. I believe the truth is more that CPLEX has significant overhead when calling native code, and this overhead is very much visible with the many smaller models in this set of test models. It’s an old JNI-based integration, while Clarabel4j is FFM-based (and therefore requires Java 25). The Java solvers have no such overhead at all. If we could get this overhead out of the equation the slopes would be more equal – I believe. The Java solvers would of course still be slower, but the slopes of the trend lines would be more similar.

Comparing the Java solvers ojAlgo is consistently about 1 order of magnitude faster than Hipparchus, and ojAlgo has a success rate of 94% while Hipparchus is at 82%. An interesting note is that with the 2 models ojAlgo fail to solve Hipparchus succeeded, and with the 6 that Hipparchus failed ojAlgo succeeded – they complement each other.

Benchmark details, raw results and execution logs can be found here: https://github.com/optimatika/ojAlgo-mathematical-programming-benchmark/tree/master/results/2026/01

LP & QP Java Performance Report

2025-11-04T20:41:30Z

ojAlgo aims to have the best set of pure Java solvers available, and to be roughly on par with good native code solvers when the models are not too big or numerically challenging. Below are the results from 3 benchmark executions comparing ojAlgo to the best Java alternatives as well as some native code reference. The solvers used in the benchmarks are:

ojAlgo (Open Source, Java, LP & QP)
Hipparchus (Open Source, Java, LP & QP)
JOptimizer (Open Source, Java, QP only)
OR-Tools, GLOP (Open Source, native code, LP only)
CPLEX (Commercial, native code, LP & QP) – community/trial version limited to 1,000 variables or constraints.

LP 1k

Netlib LP models with no more than 1,000 variables or constraints. (44 models)

Both the x- and y-axis have execution time in nano seconds as their scale. CPLEX acts as a reference (the common x-value).

For these problem sizes ojAlgo is totally comparable to OR-Tools.

Hipparchus fails to solve about 1/3 of the models and is always the slower alternative (by a good margin).

The slope of the trend lines indicate that the Java solvers will struggle, at some point, when the models get bigger.

LP 10k

Netlib LP models up to 10,000 variables or constraints. (97 models, including the 44 previous)

This time CPLEX could not be used. Therefore OR-Tools doubles as the reference – that’s why all the blue dots are perfectly on the trend line.

Primarily we see here that the Java solvers scale worse than native code solvers. There is also an increase in the number of models the Java solvers cannot solve. In this set ojAlgo can solve about 90% of the models while Hipparchus is almost down to 50%.

QP 1k

Maros and Meszaros collection of convex problems, limited to 1,000 variables and pure quadratic models, all variables quadratic. (33 models)

Here, the x-axis show the number of variables in the model

For really small models (around 10 variables or less) don’t bother with native code solvers.
At around 100 variables ojAlgo still performs about the same as native code, while Hipparchus appears slower.
Close to 1,000 variables both ojAlgo and Hipparchus are clearly distanced by native code.

Previously JOptimizer was the only Java QP alternative, but Hipparchus now also has a QP solver, and Hipparchus performs much better than JOptimizer. The main problem with JOptimizer is that it can only solve about 20% of the models. Future benchmarks will most likely only compare with Hipparchus. It is worth noting that none of the solvers could solve all the models – not even CPLEX.

Solver Success Rate

It’s not always clear from the charts above that some solvers can’t handle all the models. Not being able to solve a model at all is of course much more of a problem than solving it slower than others. Therefore we also show a table of success rates. There is a strong correlation between being fast (scaling well) and being able to solve many cases.

Solver	LP 1k	LP 10k	QP 1k
CPLEX	100%		94%
OR-Tools	100%	100%
JOptimizer			21%
Hipparchus	68%	55%	82%
ojAlgo	100%	¹ 88% / 93%	91%

With ojAlgo there are actually 4 different LP solvers/configurations. 88% is the best single solver/configuration, 93% is the combination of all. ↩︎

What about MIP

There are 2 main reasons why there’s no MIP benchmark included here:

There is no other pure Java MIP solver to compare with
We don’t know of any suitable MIP test library to use. MIPLIB does contain a large collection of MIP models, but these are too hard or time consuming to solve.

In MIPLIB there are plenty of models that no solver have ever solved, and a model is considered “easy” if top-of-the-line commercial native code solvers can solve it in less than an hour. That’s entirely different execution times than with the LP and QP models used in these comparisons.

Results / Interpretation

Well, not that much to say actually. In therms of pure Java alternatives there aren’t that many. It’s essentially just ojAlgo and Hipparchus. As shown in these benchmarks (and others) ojAlgo performs better. For LP there is no contest – nothing indicates that Hipparchus would (ever) be better than ojAlgo. For QP maybe you can try Hipparchus when/if ojAlgo fails. Even if ojAlgo overall performs better and handles more cases, there may be differences in what the solvers are good at, that could make Hipparchus a better choice in some cases. For MIP ojAlgo is the only Java alternative.

There are many native code solvers, commercial as well as open source, of different categories – and there are many good choices. ojAlgo is for when you want to avoid native code and/or commercial licenses. Up towards 1,000 variables ojAlgo compares well. The differences are probably not noticeable, unless measured.

Benchmark Code & Methodology

The benchmark code can be found here: https://github.com/optimatika/ojAlgo-mathematical-programming-benchmark

More specifically the raw results and execution logs can be found here: https://github.com/optimatika/ojAlgo-mathematical-programming-benchmark/tree/master/results/2025/11

Model and Solve the Traveling Salesman Problem

2025-08-19T15:50:46Z

The Traveling Salesman Problem (TSP) is a classic optimization problem in which a salesman must visit a set of cities exactly once and return to the starting city, while minimizing the total travel distance. Formally, given a list of cities and the distances between each pair, the goal is to find the shortest possible route that visits each city once and returns to the origin. TSP is widely studied in operations research, computer science, and logistics due to its practical relevance and computational complexity.

Although the problem is simple to state, solving it is hard, and modelling it effectively for a solver is not trivial. The TSP can be naively modeled by introducing binary decision variables $x_{i,j,t}$ , where $x_{i,j,t}$ = 1 indicates that the salesman travels from city i to city j at time (or step) t in the tour.

\min \sum_{t=0}^{n-1} \sum_{i=1}^{n} \sum_{\substack{j=1 \\ j \neq i}}^{n} c_{i,j} \, x_{i,j,t}

We then add these 4 groups of constraints to ensure:

Each city is exited exactly once
Each city is entered exactly once
At each time step, exactly one move is made
Entering a city at time t must be followed by exiting the same city at t+1

This formulation scales very poorly. For n cities, it introduces $n^3$ binary variables and $4n$ constraints that each cover $n^2$ variables – it introduces unnecessary symmetry and redundancy, which can severely degrade the performance of MILP solvers. In the example code below we don’t even try to use this formulation as it’s too slow. Instead it explores two alternatives.

The Base For More Compact Formulations

Instead of $x_{i,j,t}$ we only define $x_{i,j}$ . This drastically reduces the size and complexity of the model. Now we only have 2 sets of constraints. They’re smaller sets and each of the constraints are simpler:

\sum_{\substack{j=1 \\ j \neq i}}^{n} x_{i,j} = 1 \quad \forall \; i = 1,\dots,n

\sum_{\substack{i=1 \\ i \neq j}}^{n} x_{i,j} = 1 \quad \forall \; j = 1,\dots,n

All in all this is MUCH simpler, but now we don’t have a construct to enforce that there needs to be precisely 1 route that pass through all the cities. More precisely what can happen now (if we don’t add anything) is that we don’t get a single tour, but several small subtours. Imagine we have 4 cities – two close to each other on the west coast and two close to each other on the east coast. We will get a solution with one subtour covering the west coast and another the east coast. The requirement is to have a single tour covering all the cities. We need to add something…

Miller–Tucker–Zemlin (MTZ)

The Miller-Tucker-Zemlin (MTZ) constraints are a classical method for eliminating subtours in TSP formulations using a compact set of linear constraints. The idea is to assign an auxiliary variable $u_i$ to each city i, representing the position of city i in the tour (except for the starting city, which typically has $u_0$ = 0). The MTZ constraints then enforce that if a route from city i to city j is used (i.e., $x_{i,j}$ = 1), then the position of j must follow that of i, by satisfying the inequality:

u_i + 1 \leq u_j + (n-1)(1 - x_{i,j}) \quad \text{for all } i \neq j,\; i, j \in \{1, \ldots, n-1\}

This enforces a valid sequence: if the tour goes from i to j, then j must be visited later than i. If not, the constraint is relaxed.

There’s essentially one such constraint per binary variable (that’s a lot) but they’re sparse. Compared to the naive formulation, with $n^3$ binary variables, this is still a huge improvement. However, the MTZ constraints are not particularly intuitive, and more importantly, they often result in weak linear relaxations: the MIP solver spends more time in the branch-and-bound tree due to poor bounds at each node.

Dantzig–Fulkerson–Johnson (DFJ)

What if we do not add anything up front to enforce getting a single tour. Instead we can incrementally add constraints to disallow the specific subtours we actually see. When a solution has multiple subtours rather than a single all encompassing tour, we modify the model to disallow those specific subtours, and solve again. Repeat that until the solution is a single tour — a process known as lazy constraint generation or cutting planes. This turns out to be very effective. Although we have to invoke the solver multiple times, modifying the model in-between, each of those invocations are fast. Despite the added complexity in implementation, the DFJ formulation produces much tighter LP relaxations, leading to faster and more reliable solving, especially for larger instances.

Example Code

TravelingSalesmanProblem.java

import java.math.BigDecimal;
import java.util.ArrayList;
import java.util.HashSet;
import java.util.List;
import java.util.Random;
import java.util.Set;

import org.ojalgo.OjAlgoUtils;
import org.ojalgo.function.constant.PrimitiveMath;
import org.ojalgo.function.special.MissingMath;
import org.ojalgo.netio.BasicLogger;
import org.ojalgo.optimisation.Expression;
import org.ojalgo.optimisation.ExpressionsBasedModel;
import org.ojalgo.optimisation.Optimisation;
import org.ojalgo.optimisation.Variable;
import org.ojalgo.optimisation.integer.IntegerSolver;
import org.ojalgo.optimisation.integer.IntegerStrategy;
import org.ojalgo.type.CalendarDateUnit;
import org.ojalgo.type.Stopwatch;
import org.ojalgo.type.context.NumberContext;

/**
 * An example of how to model and solve the Traveling Salesman Problem (TSP) using ojAlgo. Two alternative
 * models are developed and compared:
 * <ul>
 * <li>Miller–Tucker–Zemlin (MTZ)
 * <li>Dantzig–Fulkerson–Johnson (DFJ)
 * </ul>
 *
 * @see https://www.ojalgo.org/2025/08/model-and-solve-the-traveling-salesman-problem/
 */
public class TravelingSalesmanProblem {

    static final Random RANDOM = new Random(47);
    static final Stopwatch STOPWATCH = new Stopwatch();

    public static void main(final String[] args) {

        BasicLogger.debug();
        BasicLogger.debug(TravelingSalesmanProblem.class);
        BasicLogger.debug(OjAlgoUtils.getTitle());
        BasicLogger.debug(OjAlgoUtils.getDate());
        BasicLogger.debug();

        STOPWATCH.reset();

        // Specify the problem size (the number of cities to visit)
        int nbCities = 25;

        double nbPossibleRoutes = TravelingSalesmanProblem.calculateNumberOfPossibleRoutes(nbCities);

        BasicLogger.debug("Solving TSP with {} cities and {} possible routes", nbCities, nbPossibleRoutes);

        double[][] distances = TravelingSalesmanProblem.generateRandomDistances(nbCities);

        ExpressionsBasedModel baseModel = new ExpressionsBasedModel();
        baseModel.options.progress(IntegerSolver.class);
        baseModel.options.solution = NumberContext.of(6);
        baseModel.options.integer(IntegerStrategy.DEFAULT.withGapTolerance(NumberContext.of(3)));

        // Decision variables: x[i][j] = 1 if path from i to j is used, 0 otherwise
        // The weights on the variables make up the objective function – to minimise the total distance
        Variable[][] baseVariables = new Variable[nbCities][nbCities];
        for (int i = 0; i < nbCities; i++) { // from
            for (int j = 0; j < nbCities; j++) { // to
                if (i != j) {
                    baseVariables[i][j] = baseModel.addVariable("x_" + i + "_" + j).binary().weight(distances[i][j]);
                } else {
                    baseVariables[i][j] = null;
                }
            }
        }

        // Constraint: Each city is entered exactly once
        for (int j = 0; j < nbCities; j++) {
            Expression inConstraint = baseModel.addExpression("In_" + j).level(1);
            for (int i = 0; i < nbCities; i++) {
                if (i != j) {
                    inConstraint.set(baseVariables[i][j], 1);
                }
            }
        }

        // Constraint: Each city is exited exactly once
        for (int i = 0; i < nbCities; i++) {
            Expression outConstraint = baseModel.addExpression("Out_" + i).level(1);
            for (int j = 0; j < nbCities; j++) {
                if (i != j) {
                    outConstraint.set(baseVariables[i][j], 1);
                }
            }
        }

        BasicLogger.debug("Problem data and base model generated in {}", STOPWATCH.stop());

        /*
         * Miller-Tucker-Zemlin (MTZ) formulation for subtour elimination.
         */

        ExpressionsBasedModel modMTZ = baseModel.copy();

        // MTZ variables: u[i] represents the position of city i in the tour
        Variable[] u = new Variable[nbCities];
        for (int i = 0; i < nbCities; i++) {
            u[i] = modMTZ.addVariable("u_" + i);
            if (i == 0) {
                // Fix u[0] = 0 (starting city has position 0 in the tour)
                u[0].level(0);
            } else {
                u[i].lower(1).upper(nbCities - 1);
            }
        }

        // MTZ subtour elimination constraints
        for (int i = 1; i < nbCities; i++) {
            for (int j = 1; j < nbCities; j++) {
                if (i != j) {
                    // u_i - u_j + n*x_ij <= n-1
                    Expression mtzConstraint = modMTZ.addExpression("MTZ_" + i + "_" + j).upper(nbCities - 1);
                    mtzConstraint.set(u[i], 1);
                    mtzConstraint.set(u[j], -1);
                    mtzConstraint.set(baseVariables[i][j], nbCities);
                }
            }
        }

        BasicLogger.debug();
        BasicLogger.debug("Starting MTZ optimization...");
        BasicLogger.debug();
        STOPWATCH.reset();

        Optimisation.Result resMTZ = modMTZ.minimise();
        Set<List<Integer>> toursMTZ = TravelingSalesmanProblem.extractTours(resMTZ, baseVariables, modMTZ);

        BasicLogger.debug();
        BasicLogger.debug("Solving and extracting the tour took {}", STOPWATCH.stop(CalendarDateUnit.SECOND));

        TravelingSalesmanProblem.print("MTZ", resMTZ, toursMTZ);

        /*
         * Dantzig–Fulkerson–Johnson (DFJ) formulation with lazy subtour elimination.
         */

        ExpressionsBasedModel modDFJ = baseModel.copy();

        BasicLogger.debug();
        BasicLogger.debug("Starting DFJ optimization...");
        BasicLogger.debug();
        STOPWATCH.reset();

        // Lazy subtour elimination (DFJ):
        Optimisation.Result resDFJ;
        Set<List<Integer>> toursDFJ;
        int iteration = 0;

        do {
            iteration++;
            BasicLogger.debug("Iteration {}", iteration);
            resDFJ = modDFJ.minimise();
            toursDFJ = TravelingSalesmanProblem.extractTours(resDFJ, baseVariables, modDFJ);

            if (toursDFJ.size() > 1) {
                BasicLogger.debug("Subtours detected: {}", toursDFJ.size());
                for (List<Integer> subtour : toursDFJ) {
                    if (subtour.size() < nbCities) {
                        // Add DFJ cut: sum x[i][j] <= |S| - 1 for all i,j in S
                        Expression cut = modDFJ.addExpression("DFJ_CUT_" + iteration + "_" + subtour.hashCode()).upper(subtour.size() - 1);
                        for (int i : subtour) {
                            for (int j : subtour) {
                                if (i != j) {
                                    cut.set(baseVariables[i][j], 1);
                                }
                            }
                        }
                    }
                }
            }
        } while (toursDFJ.size() > 1);

        BasicLogger.debug();
        BasicLogger.debug("Solving and extracting the tour took {}", STOPWATCH.stop(CalendarDateUnit.SECOND));

        TravelingSalesmanProblem.print("DFJ", resDFJ, toursDFJ);
    }

    /**
     * Calculates the total number of possible routes for a TSP with n cities. Formula is (n-1)!/2 since we
     * can fix the starting city and the direction doesn't matter.
     *
     * <pre>
     * A -> B -> C -> D -> A is the same as A -> D -> C -> B -> A
     * and
     * B -> C -> D -> A -> B
     * and
     * C -> D -> A -> B -> C
     * as well
     * </pre>
     *
     * It doesn't matter in which city you start/finish, and it doesn't matter in which direction you travel –
     * it's still the same route.
     *
     * @param n Number of cities
     * @return The number of possible routes
     */
    static double calculateNumberOfPossibleRoutes(final int n) {
        return MissingMath.factorial(n - 1) / PrimitiveMath.TWO;
    }

    /**
     * Extracts all (sub)tours from the optimisation solution. Each tour is represented as a List<Integer>
     * (ordered sequence of cities). Returning to the initial city is not expressed explicitly (each city is
     * only referenced once).
     *
     * @param result    The optimisation result containing the variable values
     * @param variables The indices of the decision variables in the model
     * @return A Set of tours, where each tour is a List of city indices
     */
    static Set<List<Integer>> extractTours(final Optimisation.Result result, final Variable[][] variables, final ExpressionsBasedModel model) {

        Set<List<Integer>> tours = new HashSet<>();

        int n = variables.length;

        boolean[] visited = new boolean[n];
        for (int start = 0; start < n; start++) {
            if (!visited[start]) {
                List<Integer> tour = new ArrayList<>();
                int current = start;
                do {
                    tour.add(current);
                    visited[current] = true;
                    int next = -1;
                    for (int j = 0; j < n; j++) {
                        if (current != j) {
                            int varIndex = model.indexOf(variables[current][j]);
                            BigDecimal value = result.get(varIndex);
                            if (value.doubleValue() > 0.5) {
                                next = j;
                                break;
                            }
                        }
                    }
                    current = next;
                } while (current != -1 && !tour.contains(current));
                tours.add(tour);
            }
        }

        return tours;
    }

    /**
     * Generates random distances. Creates a full matrix, but the elements on the diagonal are all zeros, and
     * the lower/left triangle contain the same numbers as the upper/right.
     *
     * @param nbCities The number of cities
     * @return A symmetric distance matrix.
     */
    static double[][] generateRandomDistances(final int nbCities) {

        // Grid size is 10km times the number of cities
        double gridSize = 10.0 * nbCities;

        double[] xCoordinates = new double[nbCities];
        double[] yCoordinates = new double[nbCities];

        for (int i = 0; i < nbCities; i++) {
            xCoordinates[i] = RANDOM.nextDouble() * gridSize;
            yCoordinates[i] = RANDOM.nextDouble() * gridSize;
        }

        double[][] distances = new double[nbCities][nbCities];

        for (int i = 0; i < nbCities; i++) {
            for (int j = i + 1; j < nbCities; j++) {
                double deltaX = xCoordinates[i] - xCoordinates[j];
                double deltaY = yCoordinates[i] - yCoordinates[j];
                double directDistance = Math.sqrt(deltaX * deltaX + deltaY * deltaY);
                double alongTheRoad = directDistance * (1.0 + (RANDOM.nextDouble() / 2.0));

                distances[i][j] = alongTheRoad;
                distances[j][i] = alongTheRoad;
            }
        }

        return distances;
    }

    /**
     * Normalizes a tour to a canonical form. The normalized tour will start with the smallest city index and
     * be oriented in the direction that produces the lexicographically smallest sequence. This ensures that
     * equivalent tours have the same representation regardless of starting point or direction.
     *
     * @param tour The tour to normalize (a List of city indices)
     * @return A new normalized tour, or the original tour if it's empty or has only one city
     */
    static List<Integer> normalizeTour(final List<Integer> tour) {

        if (tour == null || tour.size() <= 1) {
            return tour;
        }

        // Find the minimum city index
        int minCity = tour.stream().min(Integer::compareTo).orElse(tour.get(0));
        int minIndex = tour.indexOf(minCity);

        // Create forward tour starting from minimum city
        List<Integer> forwardTour = new ArrayList<>();
        for (int i = 0; i < tour.size(); i++) {
            forwardTour.add(tour.get((minIndex + i) % tour.size()));
        }

        // Create reverse tour starting from minimum city
        List<Integer> reverseTour = new ArrayList<>();
        reverseTour.add(minCity);
        for (int i = 1; i < tour.size(); i++) {
            int reverseIndex = (minIndex - i + tour.size()) % tour.size();
            reverseTour.add(tour.get(reverseIndex));
        }

        // Return the lexicographically smaller tour
        for (int i = 1; i < tour.size(); i++) {
            int forwardCity = forwardTour.get(i);
            int reverseCity = reverseTour.get(i);
            if (forwardCity < reverseCity) {
                return forwardTour;
            } else if (forwardCity > reverseCity) {
                return reverseTour;
            }
        }

        // If tours are identical, return the forward tour
        return forwardTour;
    }

    static void print(final String identifier, final Optimisation.Result reuslt, final Set<List<Integer>> subtours) {

        List<Integer> tour = TravelingSalesmanProblem.normalizeTour(subtours.stream().findAny().get());

        BasicLogger.debug();
        BasicLogger.debug("Result for {} formulation", identifier);

        if (reuslt.getState().isOptimal() && subtours.size() == 1) {
            BasicLogger.debug("Total distance: {}", reuslt.getValue());
            BasicLogger.debug("Tour: {}", tour);
        } else {
            BasicLogger.debug("No optimal solution found. State: {}", reuslt.getState());
        }

        BasicLogger.debug();
    }

}

Console Output

class TravelingSalesmanProblem
ojAlgo
2025-08-19

Solving TSP with 25 cities and 3.102242008666197E23 possible routes
Problem data and base model generated in 7.7278416E7ns

Starting MTZ optimization...

[2083.652434707925, Infinity] -> FEASIBLE 2211.907151261451 @ { 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, -5.551115123125783E-17, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.9999999999999999, 0.0, 2.220446049250313E-16, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, -5.551115123125783E-17, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 2.220446049250313E-16, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 12.999999999999996, 17.999999999999996, 9.999999999999996, 22.0, 2.0, 4.999999999999996, 6.9999999999999964, 19.999999999999993, 7.9999999999999964, 11.999999999999996, 23.0, 15.999999999999996, 3.0, 13.999999999999996, 24.0, 5.999999999999996, 10.999999999999996, 3.999999999999999, 20.999999999999993, 1.0, 18.999999999999996, 8.999999999999996, 14.999999999999996, 16.999999999999996 }
	 @ 975 (961) 526=0.68 2083.652434707925 [...]
[2028.9127048624127, 2211.907151261451] -> FEASIBLE 2152.9260258956333 @ { 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 5.551115123125783E-17, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 5.551115123125783E-17, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 11.000000000000002, 18.0, 8.000000000000002, 22.0, 2.0, 13.000000000000002, 5.000000000000002, 20.0, 6.000000000000002, 10.000000000000002, 23.0, 16.0, 3.0, 12.000000000000002, 24.0, 14.000000000000002, 9.000000000000002, 4.0, 21.0, 1.0, 19.0, 7.000000000000002, 15.000000000000002, 17.0 }
	 @ 916 (816) 342=0.6799999999999999 2028.9127048624127 [...]
[1652.6373864491775, 2152.9260258956333] -> FEASIBLE 1661.096972701105 @ { 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 15.999999999999972, 17.99999999999997, 12.999999999999972, 21.999999999999975, 2.0, 7.999999999999972, 9.999999999999972, 19.99999999999998, 10.999999999999972, 14.999999999999972, 22.999999999999975, 6.999999999999972, 3.0, 16.99999999999997, 23.999999999999975, 8.999999999999972, 13.999999999999972, 3.9999999999999774, 20.99999999999998, 1.0, 18.99999999999997, 11.999999999999972, 5.999999999999972, 4.999999999999978 }
	 @ 1418 (1321) 391=0.6799999999999999 1652.6373864491775 [...]
[1479.4375417117249, 1661.096972701105] -> FEASIBLE 1496.1737241558637 @ { 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.1102230246251565E-16, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.1102230246251565E-16, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.1102230246251565E-16, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 16.0, 17.999999999999996, 13.0, 23.0, 2.0, 8.0, 10.0, 21.0, 11.0, 15.0, 22.0, 7.000000000000001, 3.0, 17.0, 24.0, 9.0, 14.0, 5.000000000000001, 20.0, 1.0, 18.999999999999996, 12.0, 6.000000000000001, 4.0 }
	 @ 1743 (1742) 326=0.200000000000001 1479.4375417117249 [...]
[1429.8689241745487, 1496.1737241558637] -> FEASIBLE 1430.8741933078757 @ { 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.9999999999999999, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 2.7755575615628914E-17, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.9999999999999998, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 4.440892098500626E-16, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.3877787807814457E-17, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 2.7755575615628914E-16, 0.0, 0.0, 0.0, 0.0, 0.0, 0.9999999999999998, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.9999999999999996, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, -1.3877787807814457E-17, 1.6653345369377348E-16, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 2.7755575615628914E-17, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 2.7755575615628914E-17, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.9999999999999996, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 8.0, 13.000000000000007, 6.000000000000001, 21.999999999999996, 14.000000000000007, 15.999999999999993, 10.00000000000001, 2.0, 11.00000000000001, 5.000000000000002, 1.0, 17.999999999999986, 15.000000000000007, 9.0, 23.999999999999986, 16.999999999999993, 7.000000000000001, 20.999999999999993, 3.0, 22.999999999999993, 12.000000000000007, 4.000000000000002, 18.999999999999986, 19.999999999999986 }
	 @ 5223 (4935) 14=0.1600000000000001 1429.8689241745487 [...]
[1243.1366642753605, 1430.8741933078757] -> FEASIBLE 1243.7822491359157 @ { 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, -3.469446951953614E-18, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, -6.938893903907228E-18, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 1.9984014443253033E-17, 0.0, 0.0, 0.0, 0.0, -6.938893903907228E-18, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.9999999999999999, -6.938893903907228E-18, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, -3.469446951953614E-18, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, -1.9984014443253033E-17, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, -4.85722573273506E-17, 0.0, 1.0, -3.469446951953614E-18, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, -6.938893903907228E-18, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 6.938893903907228E-18, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0000000000000002, 0.0, 0.0, -4.85722573273506E-17, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.9999999999999999, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 16.0, 11.000000000000014, 14.000000000000007, 6.000000000000015, 21.999999999999993, 21.0, 19.0, 8.000000000000014, 17.999999999999993, 13.000000000000012, 7.000000000000015, 2.0000000000000115, 22.999999999999993, 17.0, 24.0, 20.0, 15.0, 4.0000000000000115, 9.000000000000014, 1.0, 10.000000000000014, 12.000000000000016, 3.0000000000000115, 5.000000000000015 }
	 @ 8578 (8573) 326=0.12000000000000122 1243.1366642753605 [...]
[1210.6635775998573, 1243.7822491359157] -> FEASIBLE 1229.8082467449985 @ { 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.249000902703301E-16, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.9999999999999998, 0.0, 0.0, 0.0, 0.0, 2.465190328815662E-32, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 4.379932397882043E-16, 0.0, 0.0, 0.0, 0.0, 0.0, -1.5239925154645657E-18, 0.0, 0.0, 0.0, 0.0, 0.9999999999999992, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 8.021874181595761E-17, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, -1.9949319973733282E-17, 0.0, 0.0, 0.0, 1.9949319973733282E-17, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 3.3001892235661776E-16, 0.0, 0.0, 0.0, 0.0, 0.0, 1.049263324006574E-16, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 2.465190328815662E-32, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 3.3001892235661776E-16, 0.0, 0.9999999999999997, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.9999999999999996, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, -1.3877787807814447E-16, 0.0, 0.0, 0.0, 0.9999999999999997, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, -2.7755575615628716E-17, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 16.999999999999968, 12.000000000000007, 14.999999999999972, 6.99999999999999, 23.999999999999908, 21.99999999999991, 19.99999999999993, 9.000000000000005, 18.99999999999993, 13.999999999999993, 7.999999999999996, 2.9999999999999964, 22.999999999999908, 17.99999999999993, 1.0, 20.999999999999908, 15.999999999999968, 4.999999999999996, 10.000000000000005, 2.000000000000001, 11.000000000000007, 13.00000000000001, 3.9999999999999964, 5.999999999999999 }
	 @ 7037 (1671) 411=0.92 1210.6635775998573 [...]
Done 13463 IntegerSolver iterations in 21.349221334s with NodeStatistics [I=7, E=8, S=6116, A=1202]

Solving and extracting the tour took 21.422092333s

Result for MTZ formulation
Total distance: 1229.8082467449983
Tour: [0, 5, 13, 6, 16, 7, 9, 14, 1, 17, 3, 10, 22, 2, 21, 19, 8, 11, 4, 24, 18, 23, 12, 20, 15]


Starting DFJ optimization...

Iteration 1
[NaN, Infinity] -> FEASIBLE 997.9024380299688 @ { 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0 }
	 @ 14664 (14664) -1=NaN NaN [...]
Done 1 IntegerSolver iterations in 0.036968s with NodeStatistics [I=1, E=0, S=0, A=0]
Subtours detected: 12
Iteration 2
[1197.2246815906085, Infinity] -> FEASIBLE 1200.3201157279843 @ { 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0 }
	 @ 14670 (14668) 68=0.5 1197.2246815906085 [...]
Done 4 IntegerSolver iterations in 0.020112417s with NodeStatistics [I=1, E=0, S=0, A=3]
Subtours detected: 8
Iteration 3
[NaN, Infinity] -> FEASIBLE 1214.9564225839797 @ { 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0 }
	 @ 14670 (14670) -1=NaN NaN [...]
Done 1 IntegerSolver iterations in 0.003958583s with NodeStatistics [I=1, E=0, S=0, A=0]
Subtours detected: 2
Iteration 4
[1304.2006859742303, Infinity] -> FEASIBLE 1336.0821494540824 @ { 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0 }
	 @ 14688 (14686) 330=0.5 1304.2006859742303 [...]
[1228.787942482549, 1336.0821494540824] -> FEASIBLE 1229.8082467449983 @ { 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0 }
	 @ 14690 (14671) 202=0.5 1228.787942482549 [...]
[1252.536468174225, 1229.8082467449983] -> FEASIBLE 1258.4430405321773 @ { 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0 }
	 @ 14706 (14702) 337=0.5 1252.536468174225 [...]
Done 29 IntegerSolver iterations in 0.026365583s with NodeStatistics [I=3, E=5, S=3, A=8]

Solving and extracting the tour took 0.101992625s

Result for DFJ formulation
Total distance: 1229.8082467449983
Tour: [0, 5, 13, 6, 16, 7, 9, 14, 1, 17, 3, 10, 22, 2, 21, 19, 8, 11, 4, 24, 18, 23, 12, 20, 15]

Key Takeaways

Naive 3-Index is helpful as a teaching tool but computationally infeasible for nontrivial instances.
MTZ is often used for moderate-sized problems and does not require callbacks or custom logic, but the resulting MIP model is hard to solve.
DFJ is preferred in practice —although it requires cut generation, those are actually easy to generate and the resulting MIP models are typically fast to solve. In the 25 city example (above) the DFJ formulation executes about 200x faster than the MTZ formulation.

Hooking Your Solver to ojAlgo

2025-02-08T14:29:04Z

This post aims to demonstrate how to make a solver usable from ExpressionsBasedModel. To do that we first implement a very simple solver, and then the integration.

There are some very high-level ojAlgo concepts (interfaces) you should know about:

Optimisation.Model – a description of an optimisation problem.
Optimisation.Solver – a specific algorithm implementation.
Optimisation.Integration – translates between a model’s general problem description and a solver’s specific data structure.

There needs to be one Optimisation.Integration per Optimisation.Model / Optimisation.Solver combination. It makes sense to have multiple solver implementations handling different kinds of problems, but only one tool to model them. In ojAlgo the modelling tool is ExpressionsBasedModel.

Now imagine you have some existing 3:d party solver and you want to make that available to (usable from) ojAlgo’s ExpressionsBasedModel. We need to create two classes – one that implements Optimisation.Solver and another that implements Optimisation.Integration. It’s important to distinguish between these two. The integration must be stateless. There will only ever be one instance created, that you register with the model. The solver implements the actual algorithm (delegating to the 3:d party solver). There’s typically a new solver instance created every time you solve a new problem.

Example Code

HookingUpSolver.java

import static org.ojalgo.function.constant.PrimitiveMath.*;

import java.util.ArrayList;
import java.util.List;

import org.ojalgo.OjAlgoUtils;
import org.ojalgo.equation.Equation;
import org.ojalgo.matrix.store.PhysicalStore;
import org.ojalgo.matrix.store.R064Store;
import org.ojalgo.matrix.task.iterative.ConjugateGradientSolver;
import org.ojalgo.netio.BasicLogger;
import org.ojalgo.optimisation.Expression;
import org.ojalgo.optimisation.ExpressionsBasedModel;
import org.ojalgo.optimisation.Optimisation;
import org.ojalgo.optimisation.Variable;
import org.ojalgo.optimisation.convex.ConvexSolver;
import org.ojalgo.optimisation.integer.IntegerSolver;
import org.ojalgo.optimisation.linear.LinearSolver;
import org.ojalgo.structure.Structure1D.IntIndex;
import org.ojalgo.structure.Structure2D.IntRowColumn;

/**
 * An example of how to:
 * <ol>
 * <li>implement a simple solver, and
 * <li>hook that up to be used with {@link ExpressionsBasedModel}.
 * </ol>
 *
 * @see https://www.ojalgo.org/2025/02/hooking-your-solver-to-ojalgo/
 */
public class HookingUpSolver {

    /**
     * The {@link Optimisation.Integration} interface actually declares a few more methods than what we
     * implement here. Since we extend the abstract {@link ExpressionsBasedModel.Integration} class, and use
     * it the standard way, several things are taken care of for us.
     */
    static final class UnconstrainedIntegration extends ExpressionsBasedModel.Integration<UnconstrainedSolver> {

        /**
         * Turn parameter scaling on/off
         */
        private static final boolean ADJUSTED = false;

        /**
         * Build the solver instance.
         */
        @Override
        public HookingUpSolver.UnconstrainedSolver build(final ExpressionsBasedModel model) {

            List<Variable> variables = model.getVariables();

            Expression objective = model.objective();

            /*
             * In this case we know that the objective function is quadratic, and that there are no
             * constraints. We can use this information to build a simple equation system. Essentially we take
             * the partial derivatives of the objective function with respect to each variable, and create a
             * system of linear equations by equating each of them to 0.0.
             */

            List<Equation> equations = new ArrayList<>(variables.size());
            for (int i = 0, limit = variables.size(); i < limit; i++) {
                equations.add(Equation.sparse(i, limit));
            }

            for (IntRowColumn quadraticKey : objective.getQuadraticKeySet()) {
                double quadraticValue = objective.doubleValue(quadraticKey, ADJUSTED);
                equations.get(quadraticKey.row).add(quadraticKey.column, quadraticValue);
                equations.get(quadraticKey.column).add(quadraticKey.row, quadraticValue);
            }

            for (IntIndex linearKey : objective.getLinearKeySet()) {
                double linearValue = objective.doubleValue(linearKey, ADJUSTED);
                equations.get(linearKey.index).setRHS(-linearValue);
            }

            return new UnconstrainedSolver(equations, model.options);
        }

        /**
         * Can the solver, built by this integration, handle the model?
         */
        @Override
        public boolean isCapable(final ExpressionsBasedModel model) {

            /*
             * Verify that the model is unconstrained and that the objective function is quadratic (not just
             * linear). ExpressionsBasedModel cannot model expressions of higher order than 2, and we check
             * that at least one factor is quadratic – that's NOT enough to guarantee that the problem is
             * solvable by this solver, but it's a good start. To be thorough we should check the eigenvalues
             * of the Hessian.
             */
            return model.constraints().count() == 0 && model.objective().isAnyQuadraticFactorNonZero();
        }

    }

    /**
     * Solves unconstrained optimisation problems. A very simple implementation that only works for (some)
     * quadratic problems modelled in {@link ExpressionsBasedModel}.
     * <p>
     * Actually this solver solves an equation system, and doesn't know where that comes from. Transforming
     * the unconstrained optimisation model into an equation system that this solver can solve is done by the
     * {@link UnconstrainedIntegration} class.
     * <p>
     * If this solver should be usable without that integration class (without {@link ExpressionsBasedModel}),
     * it would need some other way to build the equation system from a multivariate function or similar.
     */
    static final class UnconstrainedSolver implements Optimisation.Solver {

        /**
         * Requires the equation system body matrix to be symmetric and positive-definite. So this wont be
         * able to solve anything we throw at it
         */
        private final ConjugateGradientSolver myDelegateSolver = new ConjugateGradientSolver();
        private final List<Equation> myEquations;

        UnconstrainedSolver(final List<Equation> equations, final Optimisation.Options options) {
            super();
            myEquations = equations;
            myDelegateSolver.configurator().debug(options.logger_appender);
        }

        @Override
        public Result solve(final Result kickStarter) {

            PhysicalStore<Double> solution = R064Store.FACTORY.column(kickStarter);

            /*
             * Solve the equation system, updating the solution vector, returning an error/accuracy measure.
             */
            double error = myDelegateSolver.resolve(myEquations, solution);

            /*
             * Is the solution good enough?
             */
            State state = error < HUNDREDTH ? Optimisation.State.OPTIMAL : Optimisation.State.APPROXIMATE;

            /*
             * The objective function value
             */
            double value = this.evaluate(solution);

            return Result.wrap(solution).withState(state).withValue(value);
        }

        /**
         * Evaluate the objective function at the given solution.
         */
        private double evaluate(final PhysicalStore<Double> solution) {

            double tmpVal;
            double retVal = ZERO;

            for (Equation equation : myEquations) {
                tmpVal = equation.dot(solution) * HALF;
                tmpVal -= equation.getRHS();
                retVal += tmpVal * solution.doubleValue(equation.index);
            }

            return retVal;
        }

    }

    /**
     * Integrations absolutely must be stateless, and you typically only ever need one instance.
     */
    static final ExpressionsBasedModel.Integration<UnconstrainedSolver> INTEGRATION = new UnconstrainedIntegration();

    /**
     * Solve a small problem you'll find towards the end of this document:
     * https://www.ece.mcmaster.ca/~xwu/part4.pdf
     * <p>
     * Using the custom solver and integration defined above.
     */
    public static void main(final String[] args) {

        BasicLogger.debug();
        BasicLogger.debug(HookingUpSolver.class);
        BasicLogger.debug(OjAlgoUtils.getTitle());
        BasicLogger.debug(OjAlgoUtils.getDate());
        BasicLogger.debug();

        /*
         * Register the solver integration with ExpressionsBasedModel. This is a one-time operation – you only
         * need to do this once per JVM.
         */
        ExpressionsBasedModel.addIntegration(INTEGRATION);
        /*
         * Provided it's capable to solve the problem, ExpressionsBasedModel will now use the
         * UnconstrainedSolver rather than the default set of solvers. The integration's isCapable method
         * determines if the solver will be used.
         */

        ExpressionsBasedModel model = new ExpressionsBasedModel();

        /*
         * max: 2xy + 2x - x^2 - 2y^2
         */

        Variable x = model.addVariable("x");
        Variable y = model.addVariable("y");

        Expression expression = model.addExpression().weight(1);
        /*
         * Setting a weight on the expression is what turns it into (part of) the objective function. In a
         * more complex case the objective function could be a weighted combination of several expressions.
         * Here we only have one expression but still need to set a non-zero weight.
         */
        expression.set(x, y, 2); // +2xy
        expression.set(x, 2); // +2x
        expression.set(x, x, -1); // -x^2
        expression.set(y, y, -2); // -2y^2

        BasicLogger.debug("Expected result: {}", Optimisation.Result.of(2.0, Optimisation.State.OPTIMAL, 2.0, 1.0));
        BasicLogger.debug();

        /*
         * Turn on debug logging of the solver. With each iteration the current solution is printed as well as
         * a measure of the current error and the iteration number.
         */
        model.options.debug(UnconstrainedSolver.class);

        Optimisation.Result result = model.maximise();

        BasicLogger.debug();
        BasicLogger.debug("Actual result: {}", result);

        /*
         * ojAlgo's buil-in solvers are integrated with ExpressionsBasedModel the same way any other solver
         * is. The main built-in solvers are:
         */
        ExpressionsBasedModel.addIntegration(LinearSolver.INTEGRATION);
        ExpressionsBasedModel.addIntegration(ConvexSolver.INTEGRATION);
        ExpressionsBasedModel.addIntegration(IntegerSolver.INTEGRATION);
        /*
         * To learn how more complex integrations are built, study the source code of those.
         */
        /*
         * The only difference between the built-in solvers and custom ones is that you never have worry about
         * adding/registering built-in solver integrations. Adding them explicitly, like we just did above,
         * works fine but is entirely redundant. You only need to add/register solvers you want to use rather
         * than the built-in ones.
         */

    }

}

Console Output

class HookingUpSolver
ojAlgo
2025-02-08

Expected result: OPTIMAL 2.0 @ { 2.0, 1.0 }

0: NaN – { 0.0, 0.0 }
1: 0.8944271909999159 – { 1.0, 0.0 }
2: 0.0 – { 2.0, 1.0 }

Actual result: OPTIMAL 2.0 @ { 2, 1 }

Interpretation

Not that much to say. The solver output shows the initial solution, as well as the solutions after each iteration. With the second iteration the optimal solution is found.

Available 3:d Party Solver Integrations

There are multiple 3:d party solvers integrated with ojAlgo’s ExpressionsBasedModel. ojAlgo itself has zero dependencies, so each of these are in a separate dependency artifact.

Gurobi

https://www.gurobi.com

Top quality commercial solver.
Native code with a java interface.
Can solve all types of problems you can model with ExpressionsBasedModel.

<!-- https://mvnrepository.com/artifact/org.ojalgo/ojalgo-gurobi -->
<dependency>
    <groupId>org.ojalgo</groupId>
    <artifactId>ojalgo-gurobi</artifactId>
    <version>3.1.0</version>
</dependency>

org.ojalgo.optimisation.solver.gurobi.SolverGurobi#INTEGRATION

CPLEX

https://www.ibm.com/products/ilog-cplex-optimization-studio

Top quality commercial solver.
Native code with a java interface.
Can solve all types of problems you can model with ExpressionsBasedModel.

<!-- https://mvnrepository.com/artifact/org.ojalgo/ojalgo-cplex -->
<dependency>
    <groupId>org.ojalgo</groupId>
    <artifactId>ojalgo-cplex</artifactId>
    <version>3.1.0</version>
</dependency>

org.ojalgo.optimisation.solver.cplex.SolverCPLEX#INTEGRATION

OR-Tools

https://developers.google.com/optimization

A collection of open source solvers, and also possible to use some commercial
Native code with a java interface.
Great support for LP, ok for MIP and I believe some support for QP. In addition to that it contains a constraint programming solver that is supposedly rather good.

<!-- https://mvnrepository.com/artifact/org.ojalgo/ojalgo-ortools -->
<dependency>
    <groupId>org.ojalgo</groupId>
    <artifactId>ojalgo-ortools</artifactId>
    <version>2.0.0</version>
</dependency>

org.ojalgo.optimisation.solver.ortools.SolverORTools#INTEGRATION

MOSEK

https://www.mosek.com

Top quality commercial solver.
Native code with a java interface.
Can solve all types of problems you can model with ExpressionsBasedModel.

<!-- https://mvnrepository.com/artifact/org.ojalgo/ojalgo-mosek -->
<dependency>
    <groupId>org.ojalgo</groupId>
    <artifactId>ojalgo-mosek</artifactId>
    <version>3.2.0</version>
</dependency>

org.ojalgo.optimisation.solver.mosek.SolverMosek#INTEGRATION

Hipparchus

https://www.hipparchus.org

Open Source
Pure Java
Hipparchus started as a fork of Apache Commons Math. It contains both LP and convex (QP) solvers. Not sure about its QP capability, but the built-in ojAlgo solvers should be better than Hipparchus’. For LP they definitely are.

<!-- https://mvnrepository.com/artifact/org.ojalgo/ojalgo-hipparchus -->
<dependency>
    <groupId>org.ojalgo</groupId>
    <artifactId>ojalgo-hipparchus</artifactId>
    <version>2.0.0</version>
</dependency>

org.ojalgo.optimisation.solver.hipparchus.SolverHipparchus#INTEGRATION

Apache Commons Math

https://commons.apache.org/proper/commons-math/

Open source
Pure Java
Apache Commons Math (ACM) contains an LP solver. It offers no benefit over ojAlgo’s LP solver. In addition the ACM project seems to have problems. v3.6.1 is almost a decade old and v4.0.0 still only exists in beta (which is more than 2 years old). As far as I know the developers moved to Hipparchus.

<!-- https://mvnrepository.com/artifact/org.ojalgo/ojalgo-commons-math3 -->
<dependency>
    <groupId>org.ojalgo</groupId>
    <artifactId>ojalgo-commons-math3</artifactId>
    <version>4.0.1</version>
</dependency>

org.ojalgo.optimisation.solver.acm.SolverACM#INTEGRATION

JOptimizer

https://github.com/vincentk/joptimizer (not the original)

Open source
Pure Java
A collection of solvers for convex optimisation problems. In theory JOptimizer should be able to solve some types of problems the standard ojAlgo solvers cannot (quadratically constrained). In practice we find that this library doesn’t work very well, and as far as we know the project is abandoned.

<!-- https://mvnrepository.com/artifact/org.ojalgo/ojalgo-joptimizer -->
<dependency>
    <groupId>org.ojalgo</groupId>
    <artifactId>ojalgo-joptimizer</artifactId>
    <version>3.0.3</version>
</dependency>

org.ojalgo.optimisation.solver.joptimizer.SolverJOptimizer#INTEGRATION

All of these 3:d party solver integrations are available, with source code, from https://mvnrepository.com/artifact/org.ojalgo

Even if the solvers are not of interest to you, the integration code may be. They serve as additional examples of how to write a 3:d party solver integration. Start by looking at the OR-Tools and CPLEX integrations.

Mall Customer Segmentation

2024-12-23T05:48:08Z

This post describes how to do clustering with ojAlgo. Support for clustering is new with v55.1.0. This version added basic implementations of k-means and greedy clustering, but in a very general and configurable way.

Paired with that there is a Point class corresponding to a (k-means) multidimensional data point, and using that, preconfigured clustering. Convert whatever data you have to a List<Point> and then call Point.cluster(points), and it’ll do its magic.

The example below demonstrates how to do this using a case Mall Customer Segmentation Data from Kaggle. The given task is broadly to understand the customer base so that marketing can be done effectively. If you want to execute the example code, you have to download the customer data file. The csv file containing the customer data looks like this:

CustomerID,Gender,Age,Annual Income (k$),Spending Score (1-100)
1,Male,19,15,39
2,Male,21,15,81
3,Female,20,16,6
4,Female,23,16,77
5,Female,31,17,40
6,Female,22,17,76
7,Female,35,18,6
8,Female,23,18,94
9,Male,64,19,3

The CustomerID is just a number identifying the individual customer – not of interest here.
The Gender is Male or Female. There are 44% males and 56% females. When parsing the file we use boolean for this, where Male=true.
Age is the age of the customer. The range of values is roughly 20-70
Annual Income is stated in thousands of dollars (k$). The range is something like 25-125.
Spending Score is not well defined, but somehow represents how “good” the customer is. The range is 0-100

Normally data needs to be preprocessed and standardised before it can be used with a clustering algorithm. In this case the data is directly usable (almost). What we want to control is the magnitude of the differences between the various measurements, also weighting in the relative importance of the different attributes.

Annual Income and Spending Score both have a range of about 100 (difference between smallest and largest value) so they compare well.
Age has a range of 50, but we’ll leave it like that assuming it’s slightly less important than Annual Income and Spending Score.
Gender is categorical data. As such it is problematic to include in clustering. Either leave it out or give the categories some numerical value. Most people over at Kaggle seem to leave it out. Since there are only 2 categories (boolean, male/female) assigning a numerical value should work. In the example code below Male is given the value 10 and female 0. (Kind of equating a gender difference with 10 years age difference.)

The image below (by Abdallah abuelftouh @ Kaggle) show ranges and correlations for the different parameters (except gender).

https://www.kaggle.com/code/abdallahabuelftouh/kmeans-mall-customer-segmentation-data

The charts show that there is an interesting “pattern” in the correlation between Annual Income and Spending Score, and also some inverse/negated correlation between Age and Spending Score.

Example Code

CustomerSegmentation.java

import java.io.File;
import java.util.Collection;
import java.util.List;
import java.util.Map;
import java.util.function.Function;
import java.util.stream.Collectors;

import org.ojalgo.OjAlgoUtils;
import org.ojalgo.data.cluster.FeatureBasedClusterer;
import org.ojalgo.data.cluster.Point;
import org.ojalgo.data.cluster.Point.Factory;
import org.ojalgo.netio.ASCII;
import org.ojalgo.netio.BasicLogger;
import org.ojalgo.netio.FromFileReader;
import org.ojalgo.netio.TextLineReader;
import org.ojalgo.type.CalendarDateUnit;
import org.ojalgo.type.Stopwatch;

/**
 * Example how to use ojAlgo's clustering capabilities. This example uses the Mall_Customers.csv data set from
 * Kaggle. To run the program you need to download the data set from there, and change the path in the
 * MALL_CUSTOMERS_CSV constant below.
 *
 * @see https://www.ojalgo.org/2024/12/mall-customer-segmentation/
 * @see https://www.kaggle.com/datasets/vjchoudhary7/customer-segmentation-tutorial-in-python/data
 */
public class CustomerSegmentation {

    static final class Customer {

        static boolean filter(final String line) {
            return TextLineReader.isLineOK(line) && ASCII.isDigit(line.charAt(0));
        }

        static Customer parse(final String line) {

            String[] parts = line.split(",");

            int customerID = Integer.parseInt(parts[0]);
            boolean gender = "Male".equals(parts[1]);
            int age = Integer.parseInt(parts[2]);
            int annualIncome = Integer.parseInt(parts[3]);
            int spendingScore = Integer.parseInt(parts[4]);

            return new Customer(customerID, gender, age, annualIncome, spendingScore);
        }

        /**
         * Age
         */
        int age;
        /**
         * Annual Income (k$)
         */
        int annualIncome;
        /**
         * CustomerID
         */
        int customerID;
        /**
         * Gender (Male=true=10, Female=false=0)
         */
        boolean gender;
        /**
         * Spending Score (1-100)
         */
        int spendingScore;

        Customer(final int customerID, final boolean gender, final int age, final int annualIncome, final int spendingScore) {
            super();
            this.customerID = customerID;
            this.gender = gender;
            this.age = age;
            this.annualIncome = annualIncome;
            this.spendingScore = spendingScore;
        }

    }

    static final File MALL_CUSTOMERS_CSV = new File("/Users/apete/Developer/data/kaggle/Mall_Customers.csv");
    static final Stopwatch STOPWATCH = new Stopwatch();

    public static void main(final String[] args) {

        BasicLogger.debug();
        BasicLogger.debug(CustomerSegmentation.class);
        BasicLogger.debug(OjAlgoUtils.getTitle());
        BasicLogger.debug(OjAlgoUtils.getDate());
        BasicLogger.debug();

        STOPWATCH.reset();

        try (FromFileReader<Customer> reader = TextLineReader.of(MALL_CUSTOMERS_CSV).withFilteredParser(Customer::filter, Customer::parse)) {

            List<Customer> customers = reader.stream().collect(Collectors.toList());

            BasicLogger.debug("Number of customers: {}", customers.size());

            /*
             * Here's how to do the clustering
             */

            /*
             * 1) Construct a feature extractor function. This is very important to do well, and it will
             * depend on your data and what you want to achieve. Try changing this and see how the results
             * differ.
             */

            Function<Customer, float[]> extractor = customer -> new float[] { customer.gender ? 10 : 0, customer.age, customer.annualIncome,
                    customer.spendingScore };

            /*
             * 2) Select a clustering algorithm. The FeatureBasedClusterer class has several static factory
             * methods for common algorithms. Here we pick an automatically tuned/configured k-means
             * implementation. (Try another one. You can use the same feature extractor function.)
             */
            FeatureBasedClusterer algorithm = FeatureBasedClusterer.newAutomatic();

            /*
             * 3) Perform the clustering. The result is a list of clusters. Each cluster is a Map containing
             * the original items as keys and the extracted features as values.
             */

            List<Map<Customer, float[]>> clusters = algorithm.cluster(customers, extractor);

            /*
             * That's it! Now let's see what we got.
             */

            BasicLogger.debug();
            BasicLogger.debug("Complete data set");
            BasicLogger.debug("============================================");
            CustomerSegmentation.describe(clusters);
            BasicLogger.debug("Clusters (ordered by decreasing size)");
            BasicLogger.debug("============================================");
            for (Map<Customer, float[]> cluster : clusters) {
                CustomerSegmentation.describe(cluster);
            }

        } catch (Exception cause) {
            throw new RuntimeException(cause);
        }

        BasicLogger.debug("Done: {}", STOPWATCH.stop(CalendarDateUnit.MILLIS));
    }

    private static void describe(final Collection<Point> cluster) {
        BasicLogger.debug("Size: {}", cluster.size());
        BasicLogger.debug("Average: {}", Point.mean(cluster));
        BasicLogger.debug();
    }

    static void describe(final List<Map<Customer, float[]>> clusters) {
        Factory newFactory = Point.newFactory();
        List<Point> points = clusters.stream().flatMap(c -> c.values().stream()).map(c -> newFactory.newPoint(c)).collect(Collectors.toList());
        CustomerSegmentation.describe(points);
    }

    static void describe(final Map<Customer, float[]> cluster) {
        Factory newFactory = Point.newFactory();
        List<Point> points = cluster.values().stream().map(c -> newFactory.newPoint(c)).collect(Collectors.toList());
        CustomerSegmentation.describe(points);
    }

}

Console Output

class CustomerSegmentation
ojAlgo
2024-12-23

Number of customers: 200

Complete data set
============================================
Size: 200
Average: [4.4, 38.85, 60.56, 50.2]

Clusters (ordered by decreasing size)
============================================
Size: 76
Average: [3.9473684, 43.776318, 54.789474, 49.789474]

Size: 39
Average: [4.6153846, 32.692307, 86.53846, 82.128204]

Size: 38
Average: [5.263158, 40.394737, 87.0, 18.631578]

Size: 25
Average: [4.8, 24.48, 27.08, 76.12]

Size: 22
Average: [3.6363637, 46.409092, 26.818182, 20.09091]

Done: 78.260791ms

Interpretation

Complete data set
============================================
Size: 200
Average: [4.4, 38.85, 60.56, 50.2]

Over all there are 44% males, the average age is 38.85, average annual income 60.56k and average spending score 50.2.

Clusters (ordered by decreasing size)
============================================
Size: 76
Average: [3.9473684, 43.776318, 54.789474, 49.789474]

The largest cluster is fairly similar to the over all averages, but with a tendency towards being female, above average age and earning below average.

Size: 39
Average: [4.6153846, 32.692307, 86.53846, 82.128204]

Then there is a group of high earners / high spenders. Fairly young people in this group.

Size: 38
Average: [5.263158, 40.394737, 87.0, 18.631578]

The individuals in this group are also high earners, but clearly do not spend their money (at the Mall). This is also the only group where males are in a majority.

Size: 25
Average: [4.8, 24.48, 27.08, 76.12]

This is the opposite, some very young people that do not have money, but are big spenders anyway.

Size: 22
Average: [3.6363637, 46.409092, 26.818182, 20.09091]

And finally, low income low spending. These are generally older people. They’re also predominantly female

Further if we compare the 2 groups/clusters representing high income earners, we see that the average Age is significantly higher with the low Spending Score. The 2 groups/clusters representing low income earners show the same pattern, and here the age difference is huge.

1BRC using ojAlgo

2024-02-04T16:08:56Z

The One Billion Row Challenge (1BRC) is a fun exploration of how far modern Java can be pushed for aggregating one billion rows from a text file. Grab all your (virtual) threads, reach out to SIMD, optimize your GC, or pull any other trick, and create the fastest implementation for solving this task!

https://github.com/gunnarmorling/1brc

The One Billion Row Challenge just finished. I followed the development throughout the month with great interest, and I’m truly amazed by the results. A few days (or even weeks) into the challenge, when great progress had already been made, I would never have guessed that it would be possible to bring the execution time down to 1.5s – well done!

However impressed I am with the achievements I also find the results somewhat discouraging. The code of the fastest contributions look very different from what me and my colleagues write in our daily work. To write really fast (Java) code it seems you should:

Use Unsafe, although you know you shouldn’t
Not use any built-in, general purpose, classes. Everything needs to be custom built for precisely the problem at hand.
Create as few Java objects as possible, and don’t use the heap – allocate whatever memory you need off-heap.
Exploit every low level hack imaginable.
Use GraalVM Native Image – not just any JVM.

That’s not a recipe for writing portable concise maintainable code. It would be a very bad idea to start writing code like this, in general. We make performance/design trade-offs all the time. It’s a natural part of the craft of writing code. What I find discouraging is how far from the clean code I’d like to see the fast code is.

What we can do is to perhaps go halfway. Whenever you’ve built something using the latest and greatest high level api:s, and got it working correctly, know that it can probably be 100 times faster. Maybe, you should try to make it 10 times faster. That can probably be done without entirely destroying the cleanliness of the code.

The baseline implementation of 1BRC is not artificially slow. I can very well imagine colleagues writing that code, and leaving it like that. Possibly they would make the stream parallel (bad idea in itself). It is possible to do much better than the baseline and still have clean code. The example below demonstrates one way to do that, using tools provided with ojAlgo. It is 10 times faster than the baseline, and is still clear concise code.

Example Code

OneBRC.java

import java.io.File;
import java.io.IOException;
import java.io.UncheckedIOException;
import java.nio.file.Files;
import java.util.DoubleSummaryStatistics;
import java.util.HashMap;
import java.util.Map;
import java.util.Map.Entry;
import java.util.Set;
import java.util.SortedMap;
import java.util.TreeMap;
import java.util.stream.Collector;
import java.util.stream.Collectors;

import org.ojalgo.OjAlgoUtils;
import org.ojalgo.concurrent.ProcessingService;
import org.ojalgo.netio.BasicLogger;
import org.ojalgo.netio.SegmentedFile;
import org.ojalgo.netio.SegmentedFile.Segment;
import org.ojalgo.netio.TextLineReader;
import org.ojalgo.type.CalendarDateUnit;
import org.ojalgo.type.Stopwatch;
import org.ojalgo.type.function.TwoStepMapper;
import org.ojalgo.type.keyvalue.EntryPair;
import org.ojalgo.type.keyvalue.EntryPair.KeyedPrimitive;

/**
 * An example of how to use the SegmentedFile and ProcessingService classes to process a large file in
 * parallel.
 * <p>
 * This is an implementation of the 1BRC using ojAlgo.
 *
 * @see https://github.com/gunnarmorling/1brc
 * @see https://www.ojalgo.org/2024/02/1brc-using-ojalgo/
 */
public class OneBRC {

    /**
     * There will be one instance of this class per station (city). It is used to aggregate the temperature
     * measurements for that station. Most 1BRC submissions have a similar class. The
     * {@link DoubleSummaryStatistics} could have been used for this, but it has some overhead due to handling
     * of infinities and NaNs not needed here.
     */
    static final class Aggregator {

        static double round(final double value) {
            return Math.round(value * 10.0) / 10.0;
        }

        int count = 0;
        double max = Double.NEGATIVE_INFINITY;
        double min = Double.POSITIVE_INFINITY;
        double sum = 0.0;

        @Override
        public String toString() {
            return min + "/" + Aggregator.round(sum / count) + "/" + max;
        }

        void merge(final Aggregator other) {
            if (other.min < min) {
                min = other.min;
            }
            if (other.max > max) {
                max = other.max;
            }
            sum += other.sum;
            count += other.count;
        }

        void put(final double value) {
            if (value < min) {
                min = value;
            }
            if (value > max) {
                max = value;
            }
            sum += value;
            count++;
        }

    }

    /**
     * A file segment processor. This class implements much of the actual processing specific for this use
     * case. Since it implements the TwoStepMapper interface there is standard functionality implemented in
     * the ProcessingService class we can use. More precisely since it implements the
     * TwoStepMapper.Combineable sub-interface it can be used with the
     * ProcessingService.reduceCombineable(...) method, and we'll make use of that.
     */
    static final class Processor implements TwoStepMapper.Combineable<SegmentedFile.Segment, SortedMap<String, Aggregator>, Processor> {

        /**
         * The standard Java Double.parseDouble(...) method is not used since it is too slow. This method only
         * handles precisely the format used in the 1BRC data files, and is therefore much faster.
         */
        private static double parseDouble(final String sequence, final int first, final int limit) {

            int unscaled = 0;
            boolean negative = false;

            for (int i = first; i < limit; i++) {

                char digit = sequence.charAt(i);

                switch (digit) {
                    case '-':
                        negative = true;
                        break;
                    case '.':
                        break;
                    default:
                        unscaled = 10 * unscaled + digit - '0';
                        break;
                }
            }

            if (negative) {
                return -unscaled / 10D;
            } else {
                return unscaled / 10D;
            }
        }

        /**
         * The actual temperature measurements. The key is the station (city) name, and the value is the
         * Aggregator instance for that station.
         */
        private final Map<String, Aggregator> myAggregates = new HashMap<>(512);
        /**
         * The SegmentedFile instance this Processor is processing data from.
         */
        private final SegmentedFile mySegmentedFile;

        Processor(final SegmentedFile segmentedFile) {
            super();
            mySegmentedFile = segmentedFile;
        }

        /**
         * Combine the internal state from another Processor instance into this one.
         */
        @Override
        public void combine(final Processor other) {
            for (Map.Entry<String, Aggregator> entry : other.getEntries()) {
                myAggregates.computeIfAbsent(entry.getKey(), k -> new Aggregator()).merge(entry.getValue());
            }
        }

        /**
         * Consume the data from one file segment – process all the lines in that file segment.
         */
        @Override
        public void consume(final Segment segment) {

            try (TextLineReader reader = mySegmentedFile.newTextLineReader(segment)) {

                reader.forEach(this::doOneLine);

            } catch (IOException cause) {
                throw new UncheckedIOException(cause);
            }
        }

        /**
         * Get the final sorted results
         */
        @Override
        public SortedMap<String, Aggregator> getResults() {
            return new TreeMap<>(myAggregates);
        }

        /**
         * Reset the internal state of this instance (to enable re-use).
         */
        @Override
        public void reset() {
            myAggregates.clear();
        }

        /**
         * Parse one line of data, and add the temperature measurement to the correct station aggregator.
         */
        private void doOneLine(final String line) {

            int split = line.indexOf(";");

            String station = line.substring(0, split);
            double temperature = Processor.parseDouble(line, split + 1, line.length());

            myAggregates.computeIfAbsent(station, key -> new Aggregator()).put(temperature);
        }

        Set<Entry<String, OneBRC.Aggregator>> getEntries() {
            return myAggregates.entrySet();
        }

    }

    static final File FILE = new File("/Users/apete/Developer/data/1BRC/measurements.txt");

    /**
     * A ProcessingService is a thin utility wrapper around an ExecutorService. It simplifies some processing.
     * In particular it makes use of a TwoStepMapper to process a collection of work items. It's somewhat like
     * a Collector (used with streams) but all in one interface.
     */
    static final ProcessingService PROCSERV = ProcessingService.INSTANCE;

    public static void main(final String[] args) throws IOException {

        BasicLogger.debug();
        BasicLogger.debug(OneBRC.class);
        BasicLogger.debug(OjAlgoUtils.getTitle());
        BasicLogger.debug(OjAlgoUtils.getDate());
        BasicLogger.debug();

        SortedMap<String, OneBRC.Aggregator> results = null;

        /*
         * First we'll execute a re-implementation of the 1BRC baseline. The code is more or less the same as
         * the original, but it's using the Aggregator built for the ojAlgo version of the 1BRC as well as
         * KeyedPrimitive and EntryPair that are part of the ojAlgo library.
         */

        Stopwatch stopwatch = new Stopwatch();

        Collector<KeyedPrimitive<String>, ?, Map<String, OneBRC.Aggregator>> collector = Collectors.groupingBy(KeyedPrimitive::getKey,
                Collector.of(Aggregator::new, (aggr, pair) -> {
                    aggr.put(pair.doubleValue());
                }, (aggr1, aggr2) -> {
                    aggr1.merge(aggr2);
                    return aggr1;
                }));

        BasicLogger.debug();
        stopwatch.reset();

        results = new TreeMap<>(Files.lines(FILE.toPath()).map(OneBRC::parseLine).collect(collector));
        BasicLogger.debug(results);

        BasicLogger.debug("Baseline: {}", stopwatch.stop(CalendarDateUnit.SECOND));

        /*
         * Baseline parallelised – exactly the same code just using parallel streams instead.
         */

        results = null;
        BasicLogger.debug();
        stopwatch.reset();

        results = new TreeMap<>(Files.lines(FILE.toPath()).parallel().map(OneBRC::parseLine).collect(collector));
        BasicLogger.debug(results);

        BasicLogger.debug("Parallelised: {}", stopwatch.stop(CalendarDateUnit.SECOND));

        /*
         * Now the ojAlgo way.
         */

        results = null;
        BasicLogger.debug();
        stopwatch.reset();

        try (SegmentedFile segmented = SegmentedFile.of(FILE)) {
            results = PROCSERV.reduceCombineable(segmented.segments(), () -> new Processor(segmented));
            BasicLogger.debug(results);
        }

        /*
         * The most important difference is that the ojAlgo version uses SegmentedFile and a ProcessingService
         * rather than Java's standard Files.lines(...) and parallel streams. The ojAlgo version is also
         * parallelised, but it's done in a more controlled way. The ojAlgo version is also more memory
         * efficient and more scalable.
         */

        BasicLogger.debug("ojAlgo: {}", stopwatch.stop(CalendarDateUnit.SECOND));

    }

    /**
     * Used to re-implement the 1BRC baseline.
     */
    static KeyedPrimitive<String> parseLine(final String line) {
        String[] parts = line.split(";");
        return EntryPair.of(parts[0], Double.parseDouble(parts[1]));
    }

}

Console Output

Running the above program gives the following output.

class OneBRC
ojAlgo
2024-02-04


{Abha=-31.3/18.0/67.4, Abidjan=-26.9/26.0/75.5, Abéché=-23.4/29.4/81.5, Accra=-24.7/26.4/78.4, Addis Ababa=-30.9/16.0/65.5, Adelaide=-33.8/17.3/65.0, Aden=-22.6/29.1/78.1, Ahvaz=-22.1/25.4/75.1, Albuquerque=-39.2/14.0/61.5, Alexandra=-40.0/11.0/60.9, Alexandria=-27.9/20.0/69.2, Algiers=-33.0/18.2/70.9, Alice Springs=-27.1/21.0/70.5, Almaty=-37.9/10.0/58.3, Amsterdam=-38.6/10.2/60.7, Anadyr=-60.7/-6.9/42.8, Anchorage=-45.8/2.8/50.6, Andorra la Vella=-40.0/9.8/57.4, Ankara=-36.8/12.0/62.5, Antananarivo=-30.4/17.9/68.4, Antsiranana=-27.0/25.2/75.8, Arkhangelsk=-52.3/1.3/50.5, Ashgabat=-35.3/17.1/67.8, Asmara=-35.3/15.6/64.2, Assab=-27.5/30.5/81.6, Astana=-47.5/3.5/53.3, Athens=-32.2/19.2/67.5, Atlanta=-33.2/17.0/66.1, Auckland=-37.4/15.2/63.9, Austin=-29.0/20.7/73.7, Baghdad=-30.8/22.8/70.6, Baguio=-32.7/19.5/72.4, Baku=-34.7/15.1/66.2, Baltimore=-38.2/13.1/61.2, Bamako=-23.2/27.8/76.9, Bangkok=-20.5/28.6/80.0, Bangui=-25.4/26.0/73.9, Banjul=-27.3/26.0/74.0, Barcelona=-31.5/18.2/74.2, Bata=-27.9/25.1/75.2, Batumi=-34.6/14.0/63.1, Beijing=-37.9/12.9/60.9, Beirut=-30.6/20.9/71.0, Belgrade=-42.1/12.5/63.0, Belize City=-26.1/26.7/75.4, Benghazi=-29.1/19.9/68.6, Bergen=-45.9/7.7/60.4, Berlin=-42.5/10.3/59.9, Bilbao=-42.8/14.7/66.7, Birao=-21.2/26.5/75.6, Bishkek=-38.1/11.3/61.4, Bissau=-19.7/27.0/76.6, Blantyre=-27.1/22.2/69.5, Bloemfontein=-36.3/15.6/67.2, Boise=-39.6/11.4/61.0, Bordeaux=-34.6/14.2/63.2, Bosaso=-16.4/30.0/78.1, Boston=-43.9/10.9/59.0, Bouaké=-27.5/26.0/77.2, Bratislava=-40.8/10.5/60.4, Brazzaville=-24.2/25.0/76.0, Bridgetown=-26.8/27.0/75.3, Brisbane=-30.0/21.4/71.7, Brussels=-41.9/10.5/63.0, Bucharest=-37.5/10.8/59.1, Budapest=-40.2/11.3/59.1, Bujumbura=-25.1/23.8/74.6, Bulawayo=-39.0/18.9/69.2, Burnie=-38.6/13.1/60.2, Busan=-34.8/15.0/66.2, Cabo San Lucas=-23.6/23.9/72.5, Cairns=-32.9/25.0/76.5, Cairo=-31.5/21.4/69.4, Calgary=-44.4/4.4/56.4, Canberra=-34.6/13.1/68.1, Cape Town=-34.7/16.2/70.1, Changsha=-31.8/17.4/68.4, Charlotte=-32.1/16.1/65.9, Chiang Mai=-24.5/25.8/74.8, Chicago=-40.9/9.8/60.4, Chihuahua=-30.5/18.6/66.3, Chittagong=-22.4/25.9/75.0, Chișinău=-41.1/10.2/61.7, Chongqing=-32.1/18.6/74.2, Christchurch=-38.6/12.2/63.0, City of San Marino=-37.1/11.8/61.8, Colombo=-23.2/27.4/77.1, Columbus=-37.3/11.7/64.9, Conakry=-21.9/26.4/76.5, Copenhagen=-39.5/9.1/58.3, Cotonou=-22.8/27.2/78.0, Cracow=-44.4/9.3/57.6, Da Lat=-29.4/17.9/67.8, Da Nang=-24.3/25.8/76.5, Dakar=-33.6/24.0/74.7, Dallas=-36.0/19.0/68.2, Damascus=-33.0/17.0/68.7, Dampier=-30.0/26.4/74.0, Dar es Salaam=-29.5/25.8/72.5, Darwin=-21.5/27.6/77.2, Denpasar=-22.6/23.7/73.0, Denver=-43.9/10.4/58.2, Detroit=-39.9/10.0/59.9, Dhaka=-21.8/25.9/73.5, Dikson=-65.9/-11.1/37.2, Dili=-20.8/26.6/75.4, Djibouti=-20.9/29.9/84.0, Dodoma=-27.8/22.7/73.1, Dolisie=-23.0/24.0/77.1, Douala=-19.4/26.7/76.4, Dubai=-22.4/26.9/76.4, Dublin=-40.9/9.8/66.4, Dunedin=-41.6/11.1/58.8, Durban=-36.4/20.6/69.2, Dushanbe=-34.7/14.7/63.6, Edinburgh=-37.6/9.3/60.0, Edmonton=-45.0/4.2/53.7, El Paso=-33.3/18.1/73.6, Entebbe=-31.3/21.0/71.6, Erbil=-32.3/19.5/66.1, Erzurum=-49.7/5.1/53.4, Fairbanks=-50.5/-2.3/46.3, Fianarantsoa=-32.6/17.9/71.9, Flores,  Petén=-21.3/26.4/76.2, Frankfurt=-38.1/10.6/60.9, Fresno=-29.5/17.9/68.7, Fukuoka=-33.1/17.0/68.2, Gaborone=-26.7/21.0/69.7, Gabès=-29.3/19.5/74.6, Gagnoa=-25.4/26.0/77.5, Gangtok=-34.3/15.2/64.3, Garissa=-20.6/29.3/78.3, Garoua=-20.7/28.3/78.1, George Town=-22.5/27.9/84.2, Ghanzi=-27.8/21.4/72.2, Gjoa Haven=-64.4/-14.4/32.8, Guadalajara=-29.6/20.9/72.6, Guangzhou=-25.7/22.4/70.3, Guatemala City=-29.9/20.4/71.9, Halifax=-41.7/7.5/57.0, Hamburg=-41.9/9.7/58.9, Hamilton=-37.5/13.8/63.7, Hanga Roa=-27.6/20.5/70.8, Hanoi=-29.5/23.6/72.6, Harare=-28.8/18.4/65.8, Harbin=-43.4/5.0/54.9, Hargeisa=-28.6/21.7/71.8, Hat Yai=-24.9/27.0/77.9, Havana=-23.7/25.2/77.5, Helsinki=-47.9/5.9/59.5, Heraklion=-31.1/18.9/70.9, Hiroshima=-30.5/16.3/65.2, Ho Chi Minh City=-24.3/27.4/77.9, Hobart=-35.6/12.7/63.1, Hong Kong=-23.3/23.3/76.9, Honiara=-28.3/26.5/84.3, Honolulu=-23.9/25.4/77.2, Houston=-30.3/20.8/73.3, Ifrane=-36.9/11.4/62.7, Indianapolis=-38.0/11.8/68.8, Iqaluit=-58.7/-9.3/42.5, Irkutsk=-47.7/1.0/57.0, Istanbul=-37.6/13.9/62.9, Jacksonville=-35.5/20.3/67.3, Jakarta=-26.1/26.7/75.5, Jayapura=-22.7/27.0/73.8, Jerusalem=-29.2/18.3/70.4, Johannesburg=-34.4/15.5/63.0, Jos=-27.0/22.8/74.0, Juba=-20.7/27.8/76.7, Kabul=-38.8/12.1/58.7, Kampala=-28.7/20.0/68.9, Kandi=-26.0/27.7/77.4, Kankan=-23.3/26.5/77.6, Kano=-21.9/26.4/74.1, Kansas City=-40.7/12.5/65.2, Karachi=-23.1/26.0/72.6, Karonga=-24.2/24.4/72.9, Kathmandu=-36.0/18.3/69.0, Khartoum=-21.8/29.9/80.3, Kingston=-19.2/27.4/78.8, Kinshasa=-23.8/25.3/75.6, Kolkata=-24.4/26.7/78.5, Kuala Lumpur=-22.0/27.3/77.7, Kumasi=-25.2/26.0/73.4, Kunming=-34.8/15.7/67.0, Kuopio=-50.0/3.4/49.3, Kuwait City=-26.8/25.7/77.8, Kyiv=-38.9/8.4/56.9, Kyoto=-36.9/15.8/66.7, La Ceiba=-23.5/26.2/78.0, La Paz=-23.3/23.7/75.4, Lagos=-22.8/26.8/77.0, Lahore=-28.1/24.3/71.7, Lake Havasu City=-28.5/23.7/72.4, Lake Tekapo=-39.0/8.7/65.6, Las Palmas de Gran Canaria=-28.8/21.2/73.0, Las Vegas=-29.9/20.3/69.9, Launceston=-36.8/13.1/62.7, Lhasa=-43.6/7.6/57.9, Libreville=-23.4/25.9/74.4, Lisbon=-35.5/17.5/65.8, Livingstone=-26.0/21.8/70.5, Ljubljana=-38.9/10.9/62.4, Lodwar=-18.9/29.3/78.3, Lomé=-22.2/26.9/76.0, London=-43.1/11.3/61.6, Los Angeles=-29.2/18.6/74.2, Louisville=-35.6/13.9/64.0, Luanda=-22.5/25.8/73.0, Lubumbashi=-28.8/20.8/70.0, Lusaka=-28.0/19.9/67.3, Luxembourg City=-43.2/9.3/62.4, Lviv=-41.3/7.8/55.1, Lyon=-37.3/12.5/59.9, Madrid=-34.2/15.0/63.1, Mahajanga=-29.1/26.3/75.4, Makassar=-27.0/26.7/75.2, Makurdi=-25.1/26.0/72.7, Malabo=-21.0/26.3/78.0, Malé=-22.6/28.0/78.5, Managua=-24.6/27.3/78.5, Manama=-21.0/26.5/79.4, Mandalay=-24.3/28.0/75.9, Mango=-20.6/28.1/75.6, Manila=-26.1/28.4/77.5, Maputo=-25.1/22.8/70.8, Marrakesh=-31.5/19.6/69.2, Marseille=-33.7/15.8/66.1, Maun=-28.9/22.4/69.8, Medan=-23.0/26.5/79.2, Mek'ele=-28.4/22.7/71.5, Melbourne=-34.1/15.1/65.7, Memphis=-38.9/17.2/68.9, Mexicali=-26.3/23.1/72.1, Mexico City=-29.3/17.5/68.0, Miami=-22.4/24.9/78.8, Milan=-36.0/13.0/68.5, Milwaukee=-40.3/8.9/60.8, Minneapolis=-40.9/7.8/58.0, Minsk=-42.2/6.7/55.8, Mogadishu=-21.7/27.1/79.5, Mombasa=-22.5/26.3/76.5, Monaco=-35.1/16.4/63.7, Moncton=-40.7/6.1/54.4, Monterrey=-31.2/22.3/70.8, Montreal=-43.8/6.8/57.3, Moscow=-44.5/5.8/52.8, Mumbai=-23.4/27.1/78.5, Murmansk=-49.3/0.6/51.3, Muscat=-20.1/28.0/77.8, Mzuzu=-33.3/17.7/66.7, N'Djamena=-19.6/28.3/79.4, Naha=-24.2/23.1/75.7, Nairobi=-32.9/17.8/66.1, Nakhon Ratchasima=-20.4/27.3/81.4, Napier=-36.2/14.6/64.8, Napoli=-35.2/15.9/65.3, Nashville=-35.5/15.4/63.4, Nassau=-25.0/24.6/76.8, Ndola=-31.1/20.3/73.0, New Delhi=-25.1/25.0/73.2, New Orleans=-26.8/20.7/72.9, New York City=-35.7/12.9/66.4, Ngaoundéré=-28.7/22.0/68.7, Niamey=-21.9/29.3/79.8, Nicosia=-29.2/19.7/69.8, Niigata=-36.6/13.9/63.8, Nouadhibou=-27.7/21.3/69.7, Nouakchott=-29.0/25.7/76.4, Novosibirsk=-45.8/1.7/48.5, Nuuk=-55.4/-1.4/51.2, Odesa=-40.9/10.7/61.1, Odienné=-24.1/26.0/74.3, Oklahoma City=-30.8/15.9/67.0, Omaha=-37.8/10.6/60.3, Oranjestad=-21.0/28.1/80.5, Oslo=-40.9/5.7/54.4, Ottawa=-40.0/6.6/55.3, Ouagadougou=-23.4/28.3/79.2, Ouahigouya=-21.8/28.6/78.8, Ouarzazate=-31.4/18.9/67.1, Oulu=-52.5/2.7/52.1, Palembang=-19.9/27.3/76.9, Palermo=-31.4/18.5/72.2, Palm Springs=-27.0/24.5/73.3, Palmerston North=-37.4/13.2/66.5, Panama City=-26.9/28.0/76.0, Parakou=-21.2/26.8/76.0, Paris=-35.9/12.3/64.8, Perth=-32.0/18.7/64.9, Petropavlovsk-Kamchatsky=-48.0/1.9/52.1, Philadelphia=-37.0/13.2/65.1, Phnom Penh=-19.9/28.3/77.7, Phoenix=-25.9/23.9/70.3, Pittsburgh=-42.5/10.8/58.8, Podgorica=-32.6/15.3/64.7, Pointe-Noire=-23.4/26.1/82.4, Pontianak=-21.7/27.7/86.7, Port Moresby=-22.3/26.9/78.2, Port Sudan=-21.1/28.4/76.4, Port Vila=-23.0/24.3/74.9, Port-Gentil=-21.5/26.0/78.7, Portland (OR)=-35.3/12.4/63.5, Porto=-31.5/15.7/62.1, Prague=-47.7/8.4/58.0, Praia=-26.3/24.4/74.2, Pretoria=-36.2/18.2/66.2, Pyongyang=-39.2/10.8/63.3, Rabat=-32.0/17.2/64.7, Rangpur=-27.6/24.4/70.1, Reggane=-19.9/28.3/77.9, Reykjavík=-46.9/4.3/52.9, Riga=-44.9/6.2/56.0, Riyadh=-23.4/26.0/78.7, Rome=-34.9/15.2/64.0, Roseau=-23.0/26.2/76.7, Rostov-on-Don=-45.2/9.9/58.9, Sacramento=-34.7/16.3/68.6, Saint Petersburg=-42.6/5.8/53.8, Saint-Pierre=-44.8/5.7/56.7, Salt Lake City=-36.9/11.6/60.0, San Antonio=-27.8/20.8/69.1, San Diego=-33.1/17.8/67.1, San Francisco=-40.8/14.6/63.6, San Jose=-30.7/16.4/67.7, San José=-26.5/22.6/75.2, San Juan=-23.6/27.2/78.0, San Salvador=-32.6/23.1/74.4, Sana'a=-28.7/20.0/69.2, Santo Domingo=-23.6/25.9/76.7, Sapporo=-42.8/8.9/60.3, Sarajevo=-39.5/10.1/60.5, Saskatoon=-46.8/3.3/52.2, Seattle=-40.8/11.3/61.4, Seoul=-35.3/12.5/61.7, Seville=-31.2/19.2/70.4, Shanghai=-32.9/16.7/67.6, Singapore=-22.7/27.0/77.4, Skopje=-37.3/12.4/60.6, Sochi=-31.5/14.2/65.1, Sofia=-45.0/10.6/61.8, Sokoto=-20.1/28.0/76.9, Split=-35.7/16.1/66.0, St. John's=-45.4/5.0/50.8, St. Louis=-37.6/13.9/66.7, Stockholm=-47.1/6.6/55.5, Surabaya=-28.4/27.1/76.0, Suva=-29.1/25.6/74.1, Suwałki=-43.6/7.2/55.0, Sydney=-31.3/17.7/69.2, Ségou=-23.4/28.0/74.4, Tabora=-28.2/23.0/71.5, Tabriz=-38.1/12.6/68.4, Taipei=-28.8/23.0/70.1, Tallinn=-45.6/6.4/52.7, Tamale=-20.3/27.9/76.5, Tamanrasset=-27.1/21.7/69.5, Tampa=-29.8/22.9/71.5, Tashkent=-34.4/14.8/63.9, Tauranga=-34.9/14.8/64.5, Tbilisi=-39.1/12.9/61.9, Tegucigalpa=-34.3/21.7/69.5, Tehran=-32.2/17.0/71.3, Tel Aviv=-29.8/20.0/69.4, Thessaloniki=-33.2/16.0/68.5, Thiès=-27.0/24.0/76.8, Tijuana=-36.6/17.8/66.7, Timbuktu=-20.4/28.0/80.1, Tirana=-36.3/15.2/64.3, Toamasina=-25.5/23.4/76.7, Tokyo=-40.6/15.4/66.8, Toliara=-25.2/24.1/73.2, Toluca=-42.8/12.4/62.4, Toronto=-44.8/9.4/58.1, Tripoli=-34.6/20.0/75.1, Tromsø=-45.7/2.9/53.5, Tucson=-30.1/20.9/70.5, Tunis=-31.5/18.4/68.0, Ulaanbaatar=-47.8/-0.4/49.7, Upington=-30.1/20.4/73.3, Vaduz=-38.4/10.1/58.4, Valencia=-29.5/18.3/73.5, Valletta=-31.6/18.8/70.9, Vancouver=-38.0/10.4/62.7, Veracruz=-26.8/25.4/78.0, Vienna=-39.7/10.4/62.2, Vientiane=-26.9/25.9/78.2, Villahermosa=-22.0/27.1/74.1, Vilnius=-44.1/6.0/55.0, Virginia Beach=-34.0/15.8/67.0, Vladivostok=-45.1/4.9/56.4, Warsaw=-40.5/8.5/56.3, Washington, D.C.=-33.1/14.6/64.4, Wau=-24.6/27.8/77.5, Wellington=-34.1/12.9/65.5, Whitehorse=-52.5/-0.1/47.5, Wichita=-39.0/13.9/64.6, Willemstad=-22.2/28.0/77.7, Winnipeg=-47.1/3.0/50.6, Wrocław=-42.4/9.6/59.3, Xi'an=-35.8/14.1/62.0, Yakutsk=-59.9/-8.8/41.9, Yangon=-27.6/27.5/76.1, Yaoundé=-28.6/23.8/72.9, Yellowknife=-55.7/-4.3/49.2, Yerevan=-37.2/12.4/67.7, Yinchuan=-39.4/9.0/62.1, Zagreb=-38.9/10.7/62.2, Zanzibar City=-24.6/26.0/78.6, Zürich=-44.3/9.3/59.4, Ürümqi=-43.3/7.4/59.1, İzmir=-30.7/17.9/68.5}
Baseline: 165.436960959s

{Abha=-31.3/18.0/67.4, Abidjan=-26.9/26.0/75.5, Abéché=-23.4/29.4/81.5, Accra=-24.7/26.4/78.4, Addis Ababa=-30.9/16.0/65.5, Adelaide=-33.8/17.3/65.0, Aden=-22.6/29.1/78.1, Ahvaz=-22.1/25.4/75.1, Albuquerque=-39.2/14.0/61.5, Alexandra=-40.0/11.0/60.9, Alexandria=-27.9/20.0/69.2, Algiers=-33.0/18.2/70.9, Alice Springs=-27.1/21.0/70.5, Almaty=-37.9/10.0/58.3, Amsterdam=-38.6/10.2/60.7, Anadyr=-60.7/-6.9/42.8, Anchorage=-45.8/2.8/50.6, Andorra la Vella=-40.0/9.8/57.4, Ankara=-36.8/12.0/62.5, Antananarivo=-30.4/17.9/68.4, Antsiranana=-27.0/25.2/75.8, Arkhangelsk=-52.3/1.3/50.5, Ashgabat=-35.3/17.1/67.8, Asmara=-35.3/15.6/64.2, Assab=-27.5/30.5/81.6, Astana=-47.5/3.5/53.3, Athens=-32.2/19.2/67.5, Atlanta=-33.2/17.0/66.1, Auckland=-37.4/15.2/63.9, Austin=-29.0/20.7/73.7, Baghdad=-30.8/22.8/70.6, Baguio=-32.7/19.5/72.4, Baku=-34.7/15.1/66.2, Baltimore=-38.2/13.1/61.2, Bamako=-23.2/27.8/76.9, Bangkok=-20.5/28.6/80.0, Bangui=-25.4/26.0/73.9, Banjul=-27.3/26.0/74.0, Barcelona=-31.5/18.2/74.2, Bata=-27.9/25.1/75.2, Batumi=-34.6/14.0/63.1, Beijing=-37.9/12.9/60.9, Beirut=-30.6/20.9/71.0, Belgrade=-42.1/12.5/63.0, Belize City=-26.1/26.7/75.4, Benghazi=-29.1/19.9/68.6, Bergen=-45.9/7.7/60.4, Berlin=-42.5/10.3/59.9, Bilbao=-42.8/14.7/66.7, Birao=-21.2/26.5/75.6, Bishkek=-38.1/11.3/61.4, Bissau=-19.7/27.0/76.6, Blantyre=-27.1/22.2/69.5, Bloemfontein=-36.3/15.6/67.2, Boise=-39.6/11.4/61.0, Bordeaux=-34.6/14.2/63.2, Bosaso=-16.4/30.0/78.1, Boston=-43.9/10.9/59.0, Bouaké=-27.5/26.0/77.2, Bratislava=-40.8/10.5/60.4, Brazzaville=-24.2/25.0/76.0, Bridgetown=-26.8/27.0/75.3, Brisbane=-30.0/21.4/71.7, Brussels=-41.9/10.5/63.0, Bucharest=-37.5/10.8/59.1, Budapest=-40.2/11.3/59.1, Bujumbura=-25.1/23.8/74.6, Bulawayo=-39.0/18.9/69.2, Burnie=-38.6/13.1/60.2, Busan=-34.8/15.0/66.2, Cabo San Lucas=-23.6/23.9/72.5, Cairns=-32.9/25.0/76.5, Cairo=-31.5/21.4/69.4, Calgary=-44.4/4.4/56.4, Canberra=-34.6/13.1/68.1, Cape Town=-34.7/16.2/70.1, Changsha=-31.8/17.4/68.4, Charlotte=-32.1/16.1/65.9, Chiang Mai=-24.5/25.8/74.8, Chicago=-40.9/9.8/60.4, Chihuahua=-30.5/18.6/66.3, Chittagong=-22.4/25.9/75.0, Chișinău=-41.1/10.2/61.7, Chongqing=-32.1/18.6/74.2, Christchurch=-38.6/12.2/63.0, City of San Marino=-37.1/11.8/61.8, Colombo=-23.2/27.4/77.1, Columbus=-37.3/11.7/64.9, Conakry=-21.9/26.4/76.5, Copenhagen=-39.5/9.1/58.3, Cotonou=-22.8/27.2/78.0, Cracow=-44.4/9.3/57.6, Da Lat=-29.4/17.9/67.8, Da Nang=-24.3/25.8/76.5, Dakar=-33.6/24.0/74.7, Dallas=-36.0/19.0/68.2, Damascus=-33.0/17.0/68.7, Dampier=-30.0/26.4/74.0, Dar es Salaam=-29.5/25.8/72.5, Darwin=-21.5/27.6/77.2, Denpasar=-22.6/23.7/73.0, Denver=-43.9/10.4/58.2, Detroit=-39.9/10.0/59.9, Dhaka=-21.8/25.9/73.5, Dikson=-65.9/-11.1/37.2, Dili=-20.8/26.6/75.4, Djibouti=-20.9/29.9/84.0, Dodoma=-27.8/22.7/73.1, Dolisie=-23.0/24.0/77.1, Douala=-19.4/26.7/76.4, Dubai=-22.4/26.9/76.4, Dublin=-40.9/9.8/66.4, Dunedin=-41.6/11.1/58.8, Durban=-36.4/20.6/69.2, Dushanbe=-34.7/14.7/63.6, Edinburgh=-37.6/9.3/60.0, Edmonton=-45.0/4.2/53.7, El Paso=-33.3/18.1/73.6, Entebbe=-31.3/21.0/71.6, Erbil=-32.3/19.5/66.1, Erzurum=-49.7/5.1/53.4, Fairbanks=-50.5/-2.3/46.3, Fianarantsoa=-32.6/17.9/71.9, Flores,  Petén=-21.3/26.4/76.2, Frankfurt=-38.1/10.6/60.9, Fresno=-29.5/17.9/68.7, Fukuoka=-33.1/17.0/68.2, Gaborone=-26.7/21.0/69.7, Gabès=-29.3/19.5/74.6, Gagnoa=-25.4/26.0/77.5, Gangtok=-34.3/15.2/64.3, Garissa=-20.6/29.3/78.3, Garoua=-20.7/28.3/78.1, George Town=-22.5/27.9/84.2, Ghanzi=-27.8/21.4/72.2, Gjoa Haven=-64.4/-14.4/32.8, Guadalajara=-29.6/20.9/72.6, Guangzhou=-25.7/22.4/70.3, Guatemala City=-29.9/20.4/71.9, Halifax=-41.7/7.5/57.0, Hamburg=-41.9/9.7/58.9, Hamilton=-37.5/13.8/63.7, Hanga Roa=-27.6/20.5/70.8, Hanoi=-29.5/23.6/72.6, Harare=-28.8/18.4/65.8, Harbin=-43.4/5.0/54.9, Hargeisa=-28.6/21.7/71.8, Hat Yai=-24.9/27.0/77.9, Havana=-23.7/25.2/77.5, Helsinki=-47.9/5.9/59.5, Heraklion=-31.1/18.9/70.9, Hiroshima=-30.5/16.3/65.2, Ho Chi Minh City=-24.3/27.4/77.9, Hobart=-35.6/12.7/63.1, Hong Kong=-23.3/23.3/76.9, Honiara=-28.3/26.5/84.3, Honolulu=-23.9/25.4/77.2, Houston=-30.3/20.8/73.3, Ifrane=-36.9/11.4/62.7, Indianapolis=-38.0/11.8/68.8, Iqaluit=-58.7/-9.3/42.5, Irkutsk=-47.7/1.0/57.0, Istanbul=-37.6/13.9/62.9, Jacksonville=-35.5/20.3/67.3, Jakarta=-26.1/26.7/75.5, Jayapura=-22.7/27.0/73.8, Jerusalem=-29.2/18.3/70.4, Johannesburg=-34.4/15.5/63.0, Jos=-27.0/22.8/74.0, Juba=-20.7/27.8/76.7, Kabul=-38.8/12.1/58.7, Kampala=-28.7/20.0/68.9, Kandi=-26.0/27.7/77.4, Kankan=-23.3/26.5/77.6, Kano=-21.9/26.4/74.1, Kansas City=-40.7/12.5/65.2, Karachi=-23.1/26.0/72.6, Karonga=-24.2/24.4/72.9, Kathmandu=-36.0/18.3/69.0, Khartoum=-21.8/29.9/80.3, Kingston=-19.2/27.4/78.8, Kinshasa=-23.8/25.3/75.6, Kolkata=-24.4/26.7/78.5, Kuala Lumpur=-22.0/27.3/77.7, Kumasi=-25.2/26.0/73.4, Kunming=-34.8/15.7/67.0, Kuopio=-50.0/3.4/49.3, Kuwait City=-26.8/25.7/77.8, Kyiv=-38.9/8.4/56.9, Kyoto=-36.9/15.8/66.7, La Ceiba=-23.5/26.2/78.0, La Paz=-23.3/23.7/75.4, Lagos=-22.8/26.8/77.0, Lahore=-28.1/24.3/71.7, Lake Havasu City=-28.5/23.7/72.4, Lake Tekapo=-39.0/8.7/65.6, Las Palmas de Gran Canaria=-28.8/21.2/73.0, Las Vegas=-29.9/20.3/69.9, Launceston=-36.8/13.1/62.7, Lhasa=-43.6/7.6/57.9, Libreville=-23.4/25.9/74.4, Lisbon=-35.5/17.5/65.8, Livingstone=-26.0/21.8/70.5, Ljubljana=-38.9/10.9/62.4, Lodwar=-18.9/29.3/78.3, Lomé=-22.2/26.9/76.0, London=-43.1/11.3/61.6, Los Angeles=-29.2/18.6/74.2, Louisville=-35.6/13.9/64.0, Luanda=-22.5/25.8/73.0, Lubumbashi=-28.8/20.8/70.0, Lusaka=-28.0/19.9/67.3, Luxembourg City=-43.2/9.3/62.4, Lviv=-41.3/7.8/55.1, Lyon=-37.3/12.5/59.9, Madrid=-34.2/15.0/63.1, Mahajanga=-29.1/26.3/75.4, Makassar=-27.0/26.7/75.2, Makurdi=-25.1/26.0/72.7, Malabo=-21.0/26.3/78.0, Malé=-22.6/28.0/78.5, Managua=-24.6/27.3/78.5, Manama=-21.0/26.5/79.4, Mandalay=-24.3/28.0/75.9, Mango=-20.6/28.1/75.6, Manila=-26.1/28.4/77.5, Maputo=-25.1/22.8/70.8, Marrakesh=-31.5/19.6/69.2, Marseille=-33.7/15.8/66.1, Maun=-28.9/22.4/69.8, Medan=-23.0/26.5/79.2, Mek'ele=-28.4/22.7/71.5, Melbourne=-34.1/15.1/65.7, Memphis=-38.9/17.2/68.9, Mexicali=-26.3/23.1/72.1, Mexico City=-29.3/17.5/68.0, Miami=-22.4/24.9/78.8, Milan=-36.0/13.0/68.5, Milwaukee=-40.3/8.9/60.8, Minneapolis=-40.9/7.8/58.0, Minsk=-42.2/6.7/55.8, Mogadishu=-21.7/27.1/79.5, Mombasa=-22.5/26.3/76.5, Monaco=-35.1/16.4/63.7, Moncton=-40.7/6.1/54.4, Monterrey=-31.2/22.3/70.8, Montreal=-43.8/6.8/57.3, Moscow=-44.5/5.8/52.8, Mumbai=-23.4/27.1/78.5, Murmansk=-49.3/0.6/51.3, Muscat=-20.1/28.0/77.8, Mzuzu=-33.3/17.7/66.7, N'Djamena=-19.6/28.3/79.4, Naha=-24.2/23.1/75.7, Nairobi=-32.9/17.8/66.1, Nakhon Ratchasima=-20.4/27.3/81.4, Napier=-36.2/14.6/64.8, Napoli=-35.2/15.9/65.3, Nashville=-35.5/15.4/63.4, Nassau=-25.0/24.6/76.8, Ndola=-31.1/20.3/73.0, New Delhi=-25.1/25.0/73.2, New Orleans=-26.8/20.7/72.9, New York City=-35.7/12.9/66.4, Ngaoundéré=-28.7/22.0/68.7, Niamey=-21.9/29.3/79.8, Nicosia=-29.2/19.7/69.8, Niigata=-36.6/13.9/63.8, Nouadhibou=-27.7/21.3/69.7, Nouakchott=-29.0/25.7/76.4, Novosibirsk=-45.8/1.7/48.5, Nuuk=-55.4/-1.4/51.2, Odesa=-40.9/10.7/61.1, Odienné=-24.1/26.0/74.3, Oklahoma City=-30.8/15.9/67.0, Omaha=-37.8/10.6/60.3, Oranjestad=-21.0/28.1/80.5, Oslo=-40.9/5.7/54.4, Ottawa=-40.0/6.6/55.3, Ouagadougou=-23.4/28.3/79.2, Ouahigouya=-21.8/28.6/78.8, Ouarzazate=-31.4/18.9/67.1, Oulu=-52.5/2.7/52.1, Palembang=-19.9/27.3/76.9, Palermo=-31.4/18.5/72.2, Palm Springs=-27.0/24.5/73.3, Palmerston North=-37.4/13.2/66.5, Panama City=-26.9/28.0/76.0, Parakou=-21.2/26.8/76.0, Paris=-35.9/12.3/64.8, Perth=-32.0/18.7/64.9, Petropavlovsk-Kamchatsky=-48.0/1.9/52.1, Philadelphia=-37.0/13.2/65.1, Phnom Penh=-19.9/28.3/77.7, Phoenix=-25.9/23.9/70.3, Pittsburgh=-42.5/10.8/58.8, Podgorica=-32.6/15.3/64.7, Pointe-Noire=-23.4/26.1/82.4, Pontianak=-21.7/27.7/86.7, Port Moresby=-22.3/26.9/78.2, Port Sudan=-21.1/28.4/76.4, Port Vila=-23.0/24.3/74.9, Port-Gentil=-21.5/26.0/78.7, Portland (OR)=-35.3/12.4/63.5, Porto=-31.5/15.7/62.1, Prague=-47.7/8.4/58.0, Praia=-26.3/24.4/74.2, Pretoria=-36.2/18.2/66.2, Pyongyang=-39.2/10.8/63.3, Rabat=-32.0/17.2/64.7, Rangpur=-27.6/24.4/70.1, Reggane=-19.9/28.3/77.9, Reykjavík=-46.9/4.3/52.9, Riga=-44.9/6.2/56.0, Riyadh=-23.4/26.0/78.7, Rome=-34.9/15.2/64.0, Roseau=-23.0/26.2/76.7, Rostov-on-Don=-45.2/9.9/58.9, Sacramento=-34.7/16.3/68.6, Saint Petersburg=-42.6/5.8/53.8, Saint-Pierre=-44.8/5.7/56.7, Salt Lake City=-36.9/11.6/60.0, San Antonio=-27.8/20.8/69.1, San Diego=-33.1/17.8/67.1, San Francisco=-40.8/14.6/63.6, San Jose=-30.7/16.4/67.7, San José=-26.5/22.6/75.2, San Juan=-23.6/27.2/78.0, San Salvador=-32.6/23.1/74.4, Sana'a=-28.7/20.0/69.2, Santo Domingo=-23.6/25.9/76.7, Sapporo=-42.8/8.9/60.3, Sarajevo=-39.5/10.1/60.5, Saskatoon=-46.8/3.3/52.2, Seattle=-40.8/11.3/61.4, Seoul=-35.3/12.5/61.7, Seville=-31.2/19.2/70.4, Shanghai=-32.9/16.7/67.6, Singapore=-22.7/27.0/77.4, Skopje=-37.3/12.4/60.6, Sochi=-31.5/14.2/65.1, Sofia=-45.0/10.6/61.8, Sokoto=-20.1/28.0/76.9, Split=-35.7/16.1/66.0, St. John's=-45.4/5.0/50.8, St. Louis=-37.6/13.9/66.7, Stockholm=-47.1/6.6/55.5, Surabaya=-28.4/27.1/76.0, Suva=-29.1/25.6/74.1, Suwałki=-43.6/7.2/55.0, Sydney=-31.3/17.7/69.2, Ségou=-23.4/28.0/74.4, Tabora=-28.2/23.0/71.5, Tabriz=-38.1/12.6/68.4, Taipei=-28.8/23.0/70.1, Tallinn=-45.6/6.4/52.7, Tamale=-20.3/27.9/76.5, Tamanrasset=-27.1/21.7/69.5, Tampa=-29.8/22.9/71.5, Tashkent=-34.4/14.8/63.9, Tauranga=-34.9/14.8/64.5, Tbilisi=-39.1/12.9/61.9, Tegucigalpa=-34.3/21.7/69.5, Tehran=-32.2/17.0/71.3, Tel Aviv=-29.8/20.0/69.4, Thessaloniki=-33.2/16.0/68.5, Thiès=-27.0/24.0/76.8, Tijuana=-36.6/17.8/66.7, Timbuktu=-20.4/28.0/80.1, Tirana=-36.3/15.2/64.3, Toamasina=-25.5/23.4/76.7, Tokyo=-40.6/15.4/66.8, Toliara=-25.2/24.1/73.2, Toluca=-42.8/12.4/62.4, Toronto=-44.8/9.4/58.1, Tripoli=-34.6/20.0/75.1, Tromsø=-45.7/2.9/53.5, Tucson=-30.1/20.9/70.5, Tunis=-31.5/18.4/68.0, Ulaanbaatar=-47.8/-0.4/49.7, Upington=-30.1/20.4/73.3, Vaduz=-38.4/10.1/58.4, Valencia=-29.5/18.3/73.5, Valletta=-31.6/18.8/70.9, Vancouver=-38.0/10.4/62.7, Veracruz=-26.8/25.4/78.0, Vienna=-39.7/10.4/62.2, Vientiane=-26.9/25.9/78.2, Villahermosa=-22.0/27.1/74.1, Vilnius=-44.1/6.0/55.0, Virginia Beach=-34.0/15.8/67.0, Vladivostok=-45.1/4.9/56.4, Warsaw=-40.5/8.5/56.3, Washington, D.C.=-33.1/14.6/64.4, Wau=-24.6/27.8/77.5, Wellington=-34.1/12.9/65.5, Whitehorse=-52.5/-0.1/47.5, Wichita=-39.0/13.9/64.6, Willemstad=-22.2/28.0/77.7, Winnipeg=-47.1/3.0/50.6, Wrocław=-42.4/9.6/59.3, Xi'an=-35.8/14.1/62.0, Yakutsk=-59.9/-8.8/41.9, Yangon=-27.6/27.5/76.1, Yaoundé=-28.6/23.8/72.9, Yellowknife=-55.7/-4.3/49.2, Yerevan=-37.2/12.4/67.7, Yinchuan=-39.4/9.0/62.1, Zagreb=-38.9/10.7/62.2, Zanzibar City=-24.6/26.0/78.6, Zürich=-44.3/9.3/59.4, Ürümqi=-43.3/7.4/59.1, İzmir=-30.7/17.9/68.5}
Parallelised: 56.377148167s

{Abha=-31.3/18.0/67.4, Abidjan=-26.9/26.0/75.5, Abéché=-23.4/29.4/81.5, Accra=-24.7/26.4/78.4, Addis Ababa=-30.9/16.0/65.5, Adelaide=-33.8/17.3/65.0, Aden=-22.6/29.1/78.1, Ahvaz=-22.1/25.4/75.1, Albuquerque=-39.2/14.0/61.5, Alexandra=-40.0/11.0/60.9, Alexandria=-27.9/20.0/69.2, Algiers=-33.0/18.2/70.9, Alice Springs=-27.1/21.0/70.5, Almaty=-37.9/10.0/58.3, Amsterdam=-38.6/10.2/60.7, Anadyr=-60.7/-6.9/42.8, Anchorage=-45.8/2.8/50.6, Andorra la Vella=-40.0/9.8/57.4, Ankara=-36.8/12.0/62.5, Antananarivo=-30.4/17.9/68.4, Antsiranana=-27.0/25.2/75.8, Arkhangelsk=-52.3/1.3/50.5, Ashgabat=-35.3/17.1/67.8, Asmara=-35.3/15.6/64.2, Assab=-27.5/30.5/81.6, Astana=-47.5/3.5/53.3, Athens=-32.2/19.2/67.5, Atlanta=-33.2/17.0/66.1, Auckland=-37.4/15.2/63.9, Austin=-29.0/20.7/73.7, Baghdad=-30.8/22.8/70.6, Baguio=-32.7/19.5/72.4, Baku=-34.7/15.1/66.2, Baltimore=-38.2/13.1/61.2, Bamako=-23.2/27.8/76.9, Bangkok=-20.5/28.6/80.0, Bangui=-25.4/26.0/73.9, Banjul=-27.3/26.0/74.0, Barcelona=-31.5/18.2/74.2, Bata=-27.9/25.1/75.2, Batumi=-34.6/14.0/63.1, Beijing=-37.9/12.9/60.9, Beirut=-30.6/20.9/71.0, Belgrade=-42.1/12.5/63.0, Belize City=-26.1/26.7/75.4, Benghazi=-29.1/19.9/68.6, Bergen=-45.9/7.7/60.4, Berlin=-42.5/10.3/59.9, Bilbao=-42.8/14.7/66.7, Birao=-21.2/26.5/75.6, Bishkek=-38.1/11.3/61.4, Bissau=-19.7/27.0/76.6, Blantyre=-27.1/22.2/69.5, Bloemfontein=-36.3/15.6/67.2, Boise=-39.6/11.4/61.0, Bordeaux=-34.6/14.2/63.2, Bosaso=-16.4/30.0/78.1, Boston=-43.9/10.9/59.0, Bouaké=-27.5/26.0/77.2, Bratislava=-40.8/10.5/60.4, Brazzaville=-24.2/25.0/76.0, Bridgetown=-26.8/27.0/75.3, Brisbane=-30.0/21.4/71.7, Brussels=-41.9/10.5/63.0, Bucharest=-37.5/10.8/59.1, Budapest=-40.2/11.3/59.1, Bujumbura=-25.1/23.8/74.6, Bulawayo=-39.0/18.9/69.2, Burnie=-38.6/13.1/60.2, Busan=-34.8/15.0/66.2, Cabo San Lucas=-23.6/23.9/72.5, Cairns=-32.9/25.0/76.5, Cairo=-31.5/21.4/69.4, Calgary=-44.4/4.4/56.4, Canberra=-34.6/13.1/68.1, Cape Town=-34.7/16.2/70.1, Changsha=-31.8/17.4/68.4, Charlotte=-32.1/16.1/65.9, Chiang Mai=-24.5/25.8/74.8, Chicago=-40.9/9.8/60.4, Chihuahua=-30.5/18.6/66.3, Chittagong=-22.4/25.9/75.0, Chișinău=-41.1/10.2/61.7, Chongqing=-32.1/18.6/74.2, Christchurch=-38.6/12.2/63.0, City of San Marino=-37.1/11.8/61.8, Colombo=-23.2/27.4/77.1, Columbus=-37.3/11.7/64.9, Conakry=-21.9/26.4/76.5, Copenhagen=-39.5/9.1/58.3, Cotonou=-22.8/27.2/78.0, Cracow=-44.4/9.3/57.6, Da Lat=-29.4/17.9/67.8, Da Nang=-24.3/25.8/76.5, Dakar=-33.6/24.0/74.7, Dallas=-36.0/19.0/68.2, Damascus=-33.0/17.0/68.7, Dampier=-30.0/26.4/74.0, Dar es Salaam=-29.5/25.8/72.5, Darwin=-21.5/27.6/77.2, Denpasar=-22.6/23.7/73.0, Denver=-43.9/10.4/58.2, Detroit=-39.9/10.0/59.9, Dhaka=-21.8/25.9/73.5, Dikson=-65.9/-11.1/37.2, Dili=-20.8/26.6/75.4, Djibouti=-20.9/29.9/84.0, Dodoma=-27.8/22.7/73.1, Dolisie=-23.0/24.0/77.1, Douala=-19.4/26.7/76.4, Dubai=-22.4/26.9/76.4, Dublin=-40.9/9.8/66.4, Dunedin=-41.6/11.1/58.8, Durban=-36.4/20.6/69.2, Dushanbe=-34.7/14.7/63.6, Edinburgh=-37.6/9.3/60.0, Edmonton=-45.0/4.2/53.7, El Paso=-33.3/18.1/73.6, Entebbe=-31.3/21.0/71.6, Erbil=-32.3/19.5/66.1, Erzurum=-49.7/5.1/53.4, Fairbanks=-50.5/-2.3/46.3, Fianarantsoa=-32.6/17.9/71.9, Flores,  Petén=-21.3/26.4/76.2, Frankfurt=-38.1/10.6/60.9, Fresno=-29.5/17.9/68.7, Fukuoka=-33.1/17.0/68.2, Gaborone=-26.7/21.0/69.7, Gabès=-29.3/19.5/74.6, Gagnoa=-25.4/26.0/77.5, Gangtok=-34.3/15.2/64.3, Garissa=-20.6/29.3/78.3, Garoua=-20.7/28.3/78.1, George Town=-22.5/27.9/84.2, Ghanzi=-27.8/21.4/72.2, Gjoa Haven=-64.4/-14.4/32.8, Guadalajara=-29.6/20.9/72.6, Guangzhou=-25.7/22.4/70.3, Guatemala City=-29.9/20.4/71.9, Halifax=-41.7/7.5/57.0, Hamburg=-41.9/9.7/58.9, Hamilton=-37.5/13.8/63.7, Hanga Roa=-27.6/20.5/70.8, Hanoi=-29.5/23.6/72.6, Harare=-28.8/18.4/65.8, Harbin=-43.4/5.0/54.9, Hargeisa=-28.6/21.7/71.8, Hat Yai=-24.9/27.0/77.9, Havana=-23.7/25.2/77.5, Helsinki=-47.9/5.9/59.5, Heraklion=-31.1/18.9/70.9, Hiroshima=-30.5/16.3/65.2, Ho Chi Minh City=-24.3/27.4/77.9, Hobart=-35.6/12.7/63.1, Hong Kong=-23.3/23.3/76.9, Honiara=-28.3/26.5/84.3, Honolulu=-23.9/25.4/77.2, Houston=-30.3/20.8/73.3, Ifrane=-36.9/11.4/62.7, Indianapolis=-38.0/11.8/68.8, Iqaluit=-58.7/-9.3/42.5, Irkutsk=-47.7/1.0/57.0, Istanbul=-37.6/13.9/62.9, Jacksonville=-35.5/20.3/67.3, Jakarta=-26.1/26.7/75.5, Jayapura=-22.7/27.0/73.8, Jerusalem=-29.2/18.3/70.4, Johannesburg=-34.4/15.5/63.0, Jos=-27.0/22.8/74.0, Juba=-20.7/27.8/76.7, Kabul=-38.8/12.1/58.7, Kampala=-28.7/20.0/68.9, Kandi=-26.0/27.7/77.4, Kankan=-23.3/26.5/77.6, Kano=-21.9/26.4/74.1, Kansas City=-40.7/12.5/65.2, Karachi=-23.1/26.0/72.6, Karonga=-24.2/24.4/72.9, Kathmandu=-36.0/18.3/69.0, Khartoum=-21.8/29.9/80.3, Kingston=-19.2/27.4/78.8, Kinshasa=-23.8/25.3/75.6, Kolkata=-24.4/26.7/78.5, Kuala Lumpur=-22.0/27.3/77.7, Kumasi=-25.2/26.0/73.4, Kunming=-34.8/15.7/67.0, Kuopio=-50.0/3.4/49.3, Kuwait City=-26.8/25.7/77.8, Kyiv=-38.9/8.4/56.9, Kyoto=-36.9/15.8/66.7, La Ceiba=-23.5/26.2/78.0, La Paz=-23.3/23.7/75.4, Lagos=-22.8/26.8/77.0, Lahore=-28.1/24.3/71.7, Lake Havasu City=-28.5/23.7/72.4, Lake Tekapo=-39.0/8.7/65.6, Las Palmas de Gran Canaria=-28.8/21.2/73.0, Las Vegas=-29.9/20.3/69.9, Launceston=-36.8/13.1/62.7, Lhasa=-43.6/7.6/57.9, Libreville=-23.4/25.9/74.4, Lisbon=-35.5/17.5/65.8, Livingstone=-26.0/21.8/70.5, Ljubljana=-38.9/10.9/62.4, Lodwar=-18.9/29.3/78.3, Lomé=-22.2/26.9/76.0, London=-43.1/11.3/61.6, Los Angeles=-29.2/18.6/74.2, Louisville=-35.6/13.9/64.0, Luanda=-22.5/25.8/73.0, Lubumbashi=-28.8/20.8/70.0, Lusaka=-28.0/19.9/67.3, Luxembourg City=-43.2/9.3/62.4, Lviv=-41.3/7.8/55.1, Lyon=-37.3/12.5/59.9, Madrid=-34.2/15.0/63.1, Mahajanga=-29.1/26.3/75.4, Makassar=-27.0/26.7/75.2, Makurdi=-25.1/26.0/72.7, Malabo=-21.0/26.3/78.0, Malé=-22.6/28.0/78.5, Managua=-24.6/27.3/78.5, Manama=-21.0/26.5/79.4, Mandalay=-24.3/28.0/75.9, Mango=-20.6/28.1/75.6, Manila=-26.1/28.4/77.5, Maputo=-25.1/22.8/70.8, Marrakesh=-31.5/19.6/69.2, Marseille=-33.7/15.8/66.1, Maun=-28.9/22.4/69.8, Medan=-23.0/26.5/79.2, Mek'ele=-28.4/22.7/71.5, Melbourne=-34.1/15.1/65.7, Memphis=-38.9/17.2/68.9, Mexicali=-26.3/23.1/72.1, Mexico City=-29.3/17.5/68.0, Miami=-22.4/24.9/78.8, Milan=-36.0/13.0/68.5, Milwaukee=-40.3/8.9/60.8, Minneapolis=-40.9/7.8/58.0, Minsk=-42.2/6.7/55.8, Mogadishu=-21.7/27.1/79.5, Mombasa=-22.5/26.3/76.5, Monaco=-35.1/16.4/63.7, Moncton=-40.7/6.1/54.4, Monterrey=-31.2/22.3/70.8, Montreal=-43.8/6.8/57.3, Moscow=-44.5/5.8/52.8, Mumbai=-23.4/27.1/78.5, Murmansk=-49.3/0.6/51.3, Muscat=-20.1/28.0/77.8, Mzuzu=-33.3/17.7/66.7, N'Djamena=-19.6/28.3/79.4, Naha=-24.2/23.1/75.7, Nairobi=-32.9/17.8/66.1, Nakhon Ratchasima=-20.4/27.3/81.4, Napier=-36.2/14.6/64.8, Napoli=-35.2/15.9/65.3, Nashville=-35.5/15.4/63.4, Nassau=-25.0/24.6/76.8, Ndola=-31.1/20.3/73.0, New Delhi=-25.1/25.0/73.2, New Orleans=-26.8/20.7/72.9, New York City=-35.7/12.9/66.4, Ngaoundéré=-28.7/22.0/68.7, Niamey=-21.9/29.3/79.8, Nicosia=-29.2/19.7/69.8, Niigata=-36.6/13.9/63.8, Nouadhibou=-27.7/21.3/69.7, Nouakchott=-29.0/25.7/76.4, Novosibirsk=-45.8/1.7/48.5, Nuuk=-55.4/-1.4/51.2, Odesa=-40.9/10.7/61.1, Odienné=-24.1/26.0/74.3, Oklahoma City=-30.8/15.9/67.0, Omaha=-37.8/10.6/60.3, Oranjestad=-21.0/28.1/80.5, Oslo=-40.9/5.7/54.4, Ottawa=-40.0/6.6/55.3, Ouagadougou=-23.4/28.3/79.2, Ouahigouya=-21.8/28.6/78.8, Ouarzazate=-31.4/18.9/67.1, Oulu=-52.5/2.7/52.1, Palembang=-19.9/27.3/76.9, Palermo=-31.4/18.5/72.2, Palm Springs=-27.0/24.5/73.3, Palmerston North=-37.4/13.2/66.5, Panama City=-26.9/28.0/76.0, Parakou=-21.2/26.8/76.0, Paris=-35.9/12.3/64.8, Perth=-32.0/18.7/64.9, Petropavlovsk-Kamchatsky=-48.0/1.9/52.1, Philadelphia=-37.0/13.2/65.1, Phnom Penh=-19.9/28.3/77.7, Phoenix=-25.9/23.9/70.3, Pittsburgh=-42.5/10.8/58.8, Podgorica=-32.6/15.3/64.7, Pointe-Noire=-23.4/26.1/82.4, Pontianak=-21.7/27.7/86.7, Port Moresby=-22.3/26.9/78.2, Port Sudan=-21.1/28.4/76.4, Port Vila=-23.0/24.3/74.9, Port-Gentil=-21.5/26.0/78.7, Portland (OR)=-35.3/12.4/63.5, Porto=-31.5/15.7/62.1, Prague=-47.7/8.4/58.0, Praia=-26.3/24.4/74.2, Pretoria=-36.2/18.2/66.2, Pyongyang=-39.2/10.8/63.3, Rabat=-32.0/17.2/64.7, Rangpur=-27.6/24.4/70.1, Reggane=-19.9/28.3/77.9, Reykjavík=-46.9/4.3/52.9, Riga=-44.9/6.2/56.0, Riyadh=-23.4/26.0/78.7, Rome=-34.9/15.2/64.0, Roseau=-23.0/26.2/76.7, Rostov-on-Don=-45.2/9.9/58.9, Sacramento=-34.7/16.3/68.6, Saint Petersburg=-42.6/5.8/53.8, Saint-Pierre=-44.8/5.7/56.7, Salt Lake City=-36.9/11.6/60.0, San Antonio=-27.8/20.8/69.1, San Diego=-33.1/17.8/67.1, San Francisco=-40.8/14.6/63.6, San Jose=-30.7/16.4/67.7, San José=-26.5/22.6/75.2, San Juan=-23.6/27.2/78.0, San Salvador=-32.6/23.1/74.4, Sana'a=-28.7/20.0/69.2, Santo Domingo=-23.6/25.9/76.7, Sapporo=-42.8/8.9/60.3, Sarajevo=-39.5/10.1/60.5, Saskatoon=-46.8/3.3/52.2, Seattle=-40.8/11.3/61.4, Seoul=-35.3/12.5/61.7, Seville=-31.2/19.2/70.4, Shanghai=-32.9/16.7/67.6, Singapore=-22.7/27.0/77.4, Skopje=-37.3/12.4/60.6, Sochi=-31.5/14.2/65.1, Sofia=-45.0/10.6/61.8, Sokoto=-20.1/28.0/76.9, Split=-35.7/16.1/66.0, St. John's=-45.4/5.0/50.8, St. Louis=-37.6/13.9/66.7, Stockholm=-47.1/6.6/55.5, Surabaya=-28.4/27.1/76.0, Suva=-29.1/25.6/74.1, Suwałki=-43.6/7.2/55.0, Sydney=-31.3/17.7/69.2, Ségou=-23.4/28.0/74.4, Tabora=-28.2/23.0/71.5, Tabriz=-38.1/12.6/68.4, Taipei=-28.8/23.0/70.1, Tallinn=-45.6/6.4/52.7, Tamale=-20.3/27.9/76.5, Tamanrasset=-27.1/21.7/69.5, Tampa=-29.8/22.9/71.5, Tashkent=-34.4/14.8/63.9, Tauranga=-34.9/14.8/64.5, Tbilisi=-39.1/12.9/61.9, Tegucigalpa=-34.3/21.7/69.5, Tehran=-32.2/17.0/71.3, Tel Aviv=-29.8/20.0/69.4, Thessaloniki=-33.2/16.0/68.5, Thiès=-27.0/24.0/76.8, Tijuana=-36.6/17.8/66.7, Timbuktu=-20.4/28.0/80.1, Tirana=-36.3/15.2/64.3, Toamasina=-25.5/23.4/76.7, Tokyo=-40.6/15.4/66.8, Toliara=-25.2/24.1/73.2, Toluca=-42.8/12.4/62.4, Toronto=-44.8/9.4/58.1, Tripoli=-34.6/20.0/75.1, Tromsø=-45.7/2.9/53.5, Tucson=-30.1/20.9/70.5, Tunis=-31.5/18.4/68.0, Ulaanbaatar=-47.8/-0.4/49.7, Upington=-30.1/20.4/73.3, Vaduz=-38.4/10.1/58.4, Valencia=-29.5/18.3/73.5, Valletta=-31.6/18.8/70.9, Vancouver=-38.0/10.4/62.7, Veracruz=-26.8/25.4/78.0, Vienna=-39.7/10.4/62.2, Vientiane=-26.9/25.9/78.2, Villahermosa=-22.0/27.1/74.1, Vilnius=-44.1/6.0/55.0, Virginia Beach=-34.0/15.8/67.0, Vladivostok=-45.1/4.9/56.4, Warsaw=-40.5/8.5/56.3, Washington, D.C.=-33.1/14.6/64.4, Wau=-24.6/27.8/77.5, Wellington=-34.1/12.9/65.5, Whitehorse=-52.5/-0.1/47.5, Wichita=-39.0/13.9/64.6, Willemstad=-22.2/28.0/77.7, Winnipeg=-47.1/3.0/50.6, Wrocław=-42.4/9.6/59.3, Xi'an=-35.8/14.1/62.0, Yakutsk=-59.9/-8.8/41.9, Yangon=-27.6/27.5/76.1, Yaoundé=-28.6/23.8/72.9, Yellowknife=-55.7/-4.3/49.2, Yerevan=-37.2/12.4/67.7, Yinchuan=-39.4/9.0/62.1, Zagreb=-38.9/10.7/62.2, Zanzibar City=-24.6/26.0/78.6, Zürich=-44.3/9.3/59.4, Ürümqi=-43.3/7.4/59.1, İzmir=-30.7/17.9/68.5}
ojAlgo: 16.335035291s

Interpretation

Just making the baseline’s stream parallel made things 3 times faster, but that’s on an 8-core machine.

The ojAlgo-based version is 10 times faster (using 8-cores). Apart from more efficient parallelism the ojAlgo-based version also uses a custom function to parse a portion of a String to a double.

So we, easily, made it 10 times faster. The 1BRC demonstrated that it is possible to make it 100 times faster, but then you have to write very different code.

However impressive the results of the challenge are, one should remember that it is an extremely simplified/specialised case. With a few minor modifications to the challenge, it would be a very different task, and it would not be possible to get such fast execution times. What if:

The data file contained more/other data than what we needed?
We needed to support varying formats of the temperature measurements (varying number of decimals, scientific format…)?
Perhaps a few errors (bad data) in the file?
The statistics were required to contain the median or similar?
1 billion rows and up to 10k stations/cities, but in fact there was only 413 stations used in data set used to benchmark. What if there were many millions of stations?
Then perhaps, the final stage was to perform some further calculations based on the statistics…

Also, this performance challenge was not using JMH to benchmark/compare the different implementations. It was executed as a one-shot bursts. That, I assume, favours GraalVM native binary.