Zephyr utils

[mahdiehmalekian]

coordinate_systems.py : Contains namedtuples for Zephyr and Cartesian coordinates and the conversion functions between the two
plane_shift.py : Contains the class for displacement of nodes in the Cartesian plane.
node_edge.py: Contains the class for edge, edge of a Zephyr graph (which checks whether the edge exists in a perfect yield Zephyr graph), and the node of a Zephyr graph
qfloor.py: Contains the class for working with a tile (subset of nodes) in quotient Zephyr. Also contains the class for putting the tiles together in a number of rows and columns
survey.py: Contains the class for taking a survey of a Zephyr graph compared to a perfect-yield Zephyr graph on the same grid and tile size
The test suite contains the tests for these modules.

[thisac]

Thanks for the hard work @mahdiehmalekian. Had a first pass through node_edge. Will come back to it again, and the other files, in a future review soon.

[thisac]

Had another review round. Haven't checked the tests yet (will do that next).

A couple of overall comments and suggestions:

• qfloor.py contains a couple of methods without or with incomplete docstrings.
• Code in docstrings should have double back-ticks (``), and wherever possible, it's nice (but not mandatory) to have cross-references to classes and methods, etc. See here.
• A couple of places I'd recommend adding a new line after returns and around for-loop-blocks, try-excepts, after raises and after returns, to make it a bit more legible.

[boothby]

Thank you for this contribution! Let's meet up and chat about what parts of this can be generalized. We still have Advantage systems in productions and it would be nice to see if we can extend this to work with Pegasus graphs. And even if not, the Chimera structures underlying both Pegasus and Zephyr can be leveraged to support Pegasus if at lesser embedding efficiencies.

I wouldn't burden this PR with such a high bar, but I think that it would be worth thinking through what the user interface would look like (e.g. is minorminer.utils.zephyr the right namespace?) to make sure that we can cleanly support other architectures.

[mahdiehmalekian]

@boothby Most of the tools in this PR are quite specific to the zephyr architecture, although similar tools can definitely be developed for future architectures and/or previous ones. Happy to chat about this and also the user interface. Let's have @thisac also in the loop.

[mahdiehmalekian]

@randomir is this ready to be merged?

[randomir]

@randomir is this ready to be merged?

Hey @mahdiehmalekian, let me do a quick review first please (I didn't want to comment it while you were away). Also, we need to fix tests before we can merge. I can have a look why tests are failing (unless you already know why).

[mahdiehmalekian]

@randomir Thank you.
Re. test failing, I believe @thisac said it has to do with dwave.system.DWaveSampler or dwave.cloud.Client being used in the test suite and that he'd look into how to work around it. I couldn't solve it myself. Would appreciate if you can help with it.

[boothby]

I'd like to have that conversation about how we arrange topology-targeting tools within the package before merging, because maintaining backwards-compatibility turns into a maintenance chore we can otherwise avoid. For an immediate example, PlaneShift is not specific to the Zephyr topology, and we'd not want to duplicate that for a Chimera- or Pegasus-specific toolset. Leaving that in the zephyr namespace would push undue burden of refactoring and deprecating onto future developers.

[boothby]

@mahdiehmalekian it looks to me like the only place that you're using the cloud client is to load up some zephyr graphs with defects. My standard practice for this is to (a) generate a list of defects randomly during the testing process, or (b) collect a list from a real-world example, and hard-code that list into the test.