Different Results with same Graph

[Elora-V]

Different results for same graph

Is there a mean to get a determinist result for dot graph ? Because, depending on the order of information in the input, the resulting drawing can be completely different. By resulting drawing, I mean node coordinates (not the style of the drawing or the edges).

Order of subgraphs

For example (on something simple) :

digraph G {

  subgraph cluster_0 {
    style=filled;
    color=lightgrey;
    node [style=filled,color=white];
    a0 -> a1 -> a2 -> a3;
    c1;
    label = "process #1";
  }

  subgraph cluster_1 {
    node [style=filled];
    b0 -> b1 -> b2 -> b3;
    c1;
    label = "process #2";
    color=blue
  }
  start -> a0;
  start -> b0;
  a1 -> b3;
  b2 -> a3;
  a3 -> a0;
  a3 -> end;
  b3 -> end;
  c1->end;

  start [shape=Mdiamond];
  end [shape=Msquare];
}

got c1 in two clusters. C1 is draw in the first cluster it is in : cluster_0. But if the order of cluster change (cluster_1 written before cluster_2), C1 is draw in cluster_1 this time. Thus the order of cluster is important.

And even if there is no nodes in common, the order of subgraph/cluster change the resulting node layout.

Nodes declaration

Another thing that change the result, even if the nodes, edges and subgraphs are the same, is the declaration of the node. When writing a graph where nodes[] and edges[] are declared, the result isn't the same as a graph with only the declaration of edges[].

Dot with nodes and edges :

digraph G {
 graph []
R_GALOR ;R_GALK ;R_GALT ;R_UDPG4E ;R_UGLT ;R_GALU ;M_utp_c ;M_gal_c ;M_udpg_c ;M_gal1p_c ;M_g1p_c ;M_udpgal_c ;M_galt_c ;
M_utp_c -> R_GALT ;
M_utp_c -> R_GALU ;
M_gal_c -> R_GALK ;
M_gal_c -> R_GALOR ;
M_udpg_c -> R_UDPG4E ;
M_udpg_c -> R_UGLT ;
M_gal1p_c -> R_GALT ;
M_gal1p_c -> R_UGLT ;
M_g1p_c -> R_GALU ;
R_UDPG4E -> M_udpgal_c ;
R_GALT -> M_udpgal_c ;
R_UGLT -> M_udpgal_c ;
R_GALOR -> M_galt_c ;
R_GALU -> M_udpg_c ;
R_GALK -> M_gal1p_c ;
R_UGLT -> M_g1p_c ;
}

Dot with only edges (line 3 removed) :

Viz vs Dot

In Viz.js, when I use renderJSON(input: string | Graph, options?: RenderOptions) → object, the result isn't the same when I give a dot format or a Graph. But I write the same nodes, edge and subgraphs.

Dot with a set of nodes, edges and subgraphs (in blue) :

Graph with the same set of nodes, edges and subgraphs :

My question

I would like to know if there is a mean to always get the same result for a same set of nodes, edges and subgraphs, no matter the order or the way there are in the input format (but the information is the same).

[mdaines]

As far as I can tell, the output from Viz.js is consistent with the regular Graphviz program and library. That is, I get the same output when I try at least the first example using the dot command on my system. (The order of the cluster subgraphs affects the layout in the same way.)

always get the same result for a same set of nodes, edges and subgraphs

Can you say a bit more about your use case? I'm not sure this is possible without, say, sorting the input in some way.

The layout Graphviz chooses does depend on the order of the input. These graphs are the same in the sense that there are two nodes a and b with an edge between them, but they have different layout:

graph { a -- b }
graph { b -- a }

The same is true when using the Viz.js graph object feature. That just asks the Graphviz API to add nodes, edges, etc. to the graph in the order you provide.

Since this issue appears to be upstream of Viz.js, I suggest you ask about it on the Graphviz forum.

[Elora-V]

Thank you for the answer. I also sent this issue to the graphViz github because I didn't know which was the most appropriate one to post this problem.

I want to obtain the coordinates of the nodes of a metabolic graph, with metabolites and reactions as nodes, and directed edges to connect them. In my program, I create clusters for the main reaction chains, which makes better drawing. So for a set of nodes (metabolic and reaction nodes), edges and clusters/subgraphs (main chains), I'd like to get the same graph to have a more robust code that doesn't depend on the order of the nodes in the input file, or the order in which my clusters are found.