Split DWave solver to remove the python dependency.

[joaquimg]

No description provided.

[pedromxavier]

As pointed in #7, there is still one problem with Python dependencies. On the other hand, python integration is very useful for many other annealing interfaces. Most cloud services, such as Braket, have greater support there.

Keeping it here (if working) seems reasonable to me.

[joaquimg]

I think it is still better to split, because there is pure julia code for annealers, and it will be a pain for an annealer developer to depend on python which is extremely heavy weight.

[joaquimg]

example: https://github.com/lanl-ansi/QuantumAnnealing.jl

we want this thing as a solver in the near future. and we don't want users to depend on python if they don't need to.

[bernalde]

This would require a rewrite of Simulated Annealing in Julia, right? Currently the code in Julia only corresponds to "trivial" solvers (random, all ones)

[joaquimg]

The idea is to keep Anneal, minimal. Only with trivial solvers.
The we can plug any other annealer without requiring python.
For instance the one above from lanl.
Other thing we could plug is a BRKGA based julia https://docs.juliahub.com/BrkgaMpIpr/7F6Ol/1.0.1/
Even gurobi (not smartest solver for this but can show use some global optimum for small problems)

[pedromxavier]

BRKGA and the LANL projects seem very interesting! Gurobi and CPLEX performance is very similar (and not very exciting) when the NONCONVEX flag is enabled.

I see your point, @joaquimg. Still, Python wrappers are the via regia when reaching remote quantum hosts and c/c++ libraries such as our current simulation. There is no significant overhead since there is usually just a thin layer for requests or c wrapping. We are definetely not going to use a python-powered solver.

[pedromxavier]

@joaquimg, as pointed out in #7, the Python integration seems stable and our CI runs are pretty happy. Still, the precompilation process is very heavy for such a simple package and I think it is a good moment to plan D-Wave's API splitting, using Anneal to provide the basic MOI interface connection.

Basically, it is necessary to cover both QA and SA parameters. By now, we just cover the most important ones for SA.

@bernalde, do you think it is a good idea to reach somebody at D-Wave to help us in this task?

[bernalde]

I think it would never hurt to ask. I will bring it up to some contacts soon but the easiest way is to raise an issue at https://github.com/dwavesystems/dimod and see where we end up from there.

[pedromxavier]

DWaveNeal.jl now lies on the registry pipeline (should be available by monday morning) and Anneal.jl v0.2.0 (already registered) has no Python dependencies at all 🥳