Infeasible nodes and edges are allowed in chimera_graph creation via node_list and edge_list arguments, in conflict with documentation

[jackraymond]

Description
graph =dwave_networkx.chimera_graph(1,1,4,node_list=[8])
According to the docstrings node 8 should not be created, but it is. A similar issue exists in edge_list.
I will correct this with a pull request shortly, and check zephyr and pegasus graph classes for similar problems.

To Reproduce
graph =dwave_networkx.chimera_graph(1,1,4,node_list=[8])

Expected behavior
Consistency of documentation and action. Ideally only nodes and edges compatible with a defect free chimera graph of the proposed scale (m,n,t) are allowed.

Environment:

• OS: [Ubuntu 16.04.4 LTS]
• Python version: [e.g. 3.7.0]

Additional context
Add any other context about the problem here.

[jackraymond]

I did my best to address issues for chimera here https://github.com/jackraymond/dwave-networkx/tree/feature/to_torus , will make a pull request shortly.
My main reason for addressing this is I want to add torus generators for studying the LNLS on lattices, so that code is there as well (and I didn't want it to inherit this bug).
Happy for any input.

[jackraymond]

One of the weird edge cases is that we accept Graph types other than nx.Graph() for our generators - anybody know what to do in those cases? The two cases we need to support are directed and undirected edges I guess, but the generator doesn't seem to generate a sensible directed graph anyway, so why do we allow it?

[boothby]

Full validation of the edge list will be quite clunky, as you've noted. There are actually four graph classes (Graph, MultiGraph, DiGraph, MultiDiGraph), and checking for them all is a little tedious (see networkx.utils.decorators.not_implemented_for). The documentation, as-is, does not suggest that the edge-list will be checked. If the user is using these features, they're almost certainly taking data from a solver. Is it a real problem?

It might be better to do the torus PR separately from resolving this issue.

[jackraymond]

There are a handful routines, like pegasus.graph_to_nice that make use of the undocumented behaviour as well. Simple for zephyr and chimera, but the nice subgraph (+ coordinate scheme) are lossy by the documented definition which is problematic for transformations.

[jackraymond]

THe problem is not whether the edge_list is checked, although I think that would make sense. The problem is that the documentation indicates that out of range edges and variables will be dropped, whereas in fact they are not. The quick fix is just to change the docstrings - I'll do that to start with, since my full solution led to other dependent routines breaking in some special cases.

[jackraymond]

What if I add 'check_nodelist' and 'check_edgelist' arguments to our zephyr pegasus and chimera generators defaulting them as False? By default the current behviour is maintained. By constrast if they are True, we require that the graph class is 'Graph' and forbid out-of-spec nodes and edges from being added. This seems like a general solution to me, I have tested code ready to go.

For my own work, I am doing a lot of graph manipulation, and this type (topology) safety is quite useful.

[boothby]

Yeah, I'm okay with that.