The 'constraint=false'sometimes' allows the clusters to get out of order, even when doing so, causes longer edges. I wish to both have all subgraph clusters line up 'and' keep the order of the subgraph clusters intact. (which in my case, since I alway will only connect the edge to an node neighboring cluster, will result in edge that don't cross over an intervening subgraph. Sometimes it works as expected, but in the example I am posting, you can see the '2nd' subgraph for some reason shows up in the third position (which causes the links to go farther than they need to.)
Is there a way to achieve both the lining up of all the tops of the subgraphs 'and' maintaining a specific order of subgraphs left to right?
I have read many posts, and have tried many of the things suggested, but I can't seem to find a combination that works. When constraint=true, the 'order' seems to be correct, but the alignment is wrong. When constraint=false... The alignment is correct and 'sometimes' the order is correct, but other like the example posted, the order is invalid.
digraph G {
ranksep=.05;
splines=line;
subgraph cluster_1 {
label="1";
choice0_0[label="1"];
choice0_1[label="2"];
choice0_2[label="3"];
choice0_0 -> choice0_1 -> choice0_2 [style="invis"];
}
subgraph cluster_2 {
label="2";
choice1_0[label="1"];
choice1_1[label="2"];
choice1_2[label="3"];
choice1_0 -> choice1_1 -> choice1_2 [style="invis"];
}
subgraph cluster_3 {
label="3";
choice2_0[label="1"];
choice2_1[label="2"];
choice2_2[label="3"];
choice2_0 -> choice2_1 -> choice2_2 [style="invis"];
}
edge[constraint=false];
choice0_2 -> choice1_1;
choice1_1 -> choice2_2;
}
dot -Tps x.gv -o x.ps
(where x.gv contains the code pasted above)
No errors are displayed when this is run, but this example the order of the 2nd and 3rd subgraph is swapped.
Related
I have a directed graph where the color of the edges matters:
Current Diagram
digraph {
splines=ortho
node [shape=box];
1 -> 4 [color="#51dbf4"];
4 -> 7 [color="#51dbf4"];
7 -> 1 [color="#ac043e"];
7 -> 1 [color="#51dbf4"];
1 -> 7 [color="#ac043e"];
}
I want to combine the maroon colored arrows to make the graph more clear.
Desired Diagram
digraph {
splines=ortho
node [shape=box];
1 -> 4 [color="#51dbf4"];
4 -> 7 [color="#51dbf4"];
7 -> 1 [color="#ac043e" dir=both];
7 -> 1 [color="#51dbf4"];
}
However, this requires me to manually change each arrow that needs to be combined into a double-headed arrow. I wanted to merge these automatically. I tried using concentrate=true to make the arrows merge, but that kind of destroys the meaning of the graph:
Incorrect Diagram
digraph {
splines=ortho
concentrate=true
node [shape=box];
1 -> 4 [color="#51dbf4"];
4 -> 7 [color="#51dbf4"];
7 -> 1 [color="#ac043e"];
7 -> 1 [color="#51dbf4"];
1 -> 7 [color="#ac043e"];
}
Graphviz insists on merging the arrows regardless of their color, which is not correct in this case because it kind of just obliterates most of the edges.
Question
For my use case, I have a large, code-generated graph with tons of edges and I don't want to manually change so many edges to be double-ended. Is there a way to specify to graphviz that I only want to merge edges of the same color? Like maybe I could tag each edge with a group ID and then it would only merge edges that have the same ID? Any ideas are appreciated.
There may be an easier way, but this gvpr (http://www.graphviz.org/pdf/gvpr.1.pdf) program does what you want.
For each edge, it checks if a "reverse" edge exists, and if so checks if both have the same color.
If so, set dir=both & delete the "reverse" edge.
E{
edge_t N2;
N2=isEdge($.head, $.tail,"");
if (N2!=NULL && N2.color==$.color){
print("// bingo : ", $.name, " <--> ", N2.name);
$.dir="both";
delete($G, N2);
}
}
And a (Linux) command line of
gvpr -c -f single2double.gvpr myfile.gv | dot -Tpng >o.png
Giving:
In the graph below, how do I move the ClassB subgraph to the right of ClassA aligned at the top? I.e. I want to increase the rank of the nodes in ClassB to 3.
I guess it might be possible using invisible dummy nodes, but I can't figure it out. Also I'm hoping there's a less "ad hoc" solution.
digraph G {
graph [rankdir=LR];
0 -> 1 -> 2 -> 3;
subgraph cluster_SEM_SAD_analysis {
graph [label="main"];
main [label="main"];
}
subgraph cluster_ClassA {
graph [label="ClassA"];
ClassA__method1 [label="method1"];
ClassA__method2 [label="method2"];
}
subgraph cluster_ClassB {
graph [label="ClassB"];
ClassB__method1 [label="method1"];
ClassB__method2 [label="method2"];
}
main -> ClassA__method1;
ClassA__method1 -> ClassB__method1;
ClassA__method1 -> ClassA__method2;
ClassA__method1 -> ClassB__method2
}
You need to tell graphviz that you want the nodes in the Class B cluster on the level below method2 of Class 1. You achieve that by introducing an invisble edge between them. This is not "ad hoc", but inherent graphviz logic.
Add, as a last line of your code
ClassA__method2 -> ClassB__method1[ style = invis, weight = 100 ];
and you get
which is probably what you want. Aligning the third cluster at the top is achieved by the weight = 100 element.
I have the following (simplified) graph which is generated by the following .dot:
digraph Configurations {
subgraph cluster_1 {
s_0_0 [shape=circle,style=filled,fixedsize=true,width=0.5,label="0",fillcolor=yellowgreen]
s_0_1 [shape=circle,style=filled,fixedsize=true,width=0.5,label="1",fillcolor=yellowgreen]
}
subgraph cluster_2 {
s_1_0 [shape=circle,style=filled,fixedsize=true,width=0.5,label="0",fillcolor=yellowgreen]
s_1_1 [shape=circle,style=filled,fixedsize=true,width=0.5,label="1",fillcolor=white]
}
subgraph cluster_3 {
s_2_0 [shape=circle,style=filled,fixedsize=true,width=0.5,label="0",fillcolor=white]
s_2_1 [shape=circle,style=filled,fixedsize=true,width=0.5,label="1",fillcolor=yellowgreen]
}
subgraph cluster_4 {
s_3_0 [shape=circle,style=filled,fixedsize=true,width=0.5,label="0",fillcolor=white]
s_3_1 [shape=circle,style=filled,fixedsize=true,width=0.5,label="1",fillcolor=white]
}
s_0_1 -> s_1_1
s_0_0 -> s_2_0
s_2_1 -> s_3_1
s_1_0 -> s_3_0
}
I would like to be able to be able to enforce ordering inside the subgraphs so that the nodes of each subgraph are displayed in ascending order (each cluster should have nodes placed (0, 1), never (1, 0)). As I understand it, rankdir, which was my first attempt, is not supported in subgraphs, so what is a proper way to do this? I am looking for a solution which gives me a reasonably similar layout (which would then include more intersecting arrows) and is scalable, since the real graphs will be huge.
Turns out this could be solved by adding invisible edges inside and forcing same rank inside the graphs, like so:
subgraph cluster_1 {
{rank=same; s_0_0 s_0_1}
s_0_0 -> s_0_1 [style=invis]
s_0_0 [shape=circle,style=filled,fixedsize=true,width=0.5,label="0",fillcolor=yellowgreen]
s_0_1 [shape=circle,style=filled,fixedsize=true,width=0.5,label="1",fillcolor=yellowgreen]
}
If there are more nodes than 2 nodes, we need to change the solution.
subgraph cluster1 {
{
HL_1_n HL_1_1 HL_1_2 HL_1_3 HL_1_m
}
HL_1_1 [label="Hidden Layer 1 Node 1" color=3]
HL_1_2 [label="Hidden Layer 1 Node 2" color=3]
HL_1_3 [label="Hidden Layer 1 Node 3" color=3]
HL_1_m [label="Hidden Layer 1 Node ..." color=3]
HL_1_n [label="Hidden Layer 1 Node H_1" color=3]
label = "Hidden Layer"
}
It seems the order is determined, so we just need to change nodes' positions to fit the output. The solution does not use edge constraints and rank.
I would like these two nodes to appear on the same level:
digraph G {
subgraph cluster1 {
label="Local Datacenter";
router1;
host1;
}
subgraph cluster2 {
label="Remote Datacenter";
router2;
host2;
}
router1 -> router2;
router2 -> host2;
router1 -> host1;
}
I have tried using rank=same and rank=min, but they aren't giving me what I need.
Interestingly, if I set rankdir=LR and comment out the two router-to-host edges, it gives me exactly the look I want - but I would like to leave the edges intact.
You may use the newrank graph attribute (added in GraphViz 2.30) to activate the new ranking algorithm which allows defining rank=same for nodes which belong to clusters.
Add the following line at the top:
newrank=true;
Add the following line after the cluster definitions:
{ rank=same; router1; router2; }
Here's the resulting graph:
You may simply modify the edge between the routers:
router1 -> router2[constraint=false];
constraint indicates whether the edge should be used in the ranking of the nodes.
Rank attribute on edge has five values "same", "min", "source", "max", "sink".
Except "same", I have no idea when to use other values.
min
\begin{dotpic}
rankdir=LR;
size="7,5";
node[shape=circle];
C->A;
{rank=min;A;B}
B->D
A->B;
\end{dotpic}
max
\begin{dotpic}
rankdir=LR;
size="7,5";
node[shape=circle];
C->A;
{rank=max;A;B}
B->D
A->B;
\end{dotpic}
source
\begin{dotpic}
rankdir=LR;
size="7,5";
node[shape=circle];
C->A;
{rank=source;A;B}
B->D
A->B;
\end{dotpic}
sink
\begin{dotpic}
rankdir=LR;
size="7,5";
node[shape=circle];
C->A;
{rank=sink;A;B}
B->D
A->B;
\end{dotpic}
With test on my vim environment, I can realize there is some difference btw these values.
But don't know exactly what they are for.
Leaving the rank empty or using rank=same are used far more often. These other four are usually only used in special circumstances.
When used alone, min and source have the same function: putting all those nodes on the minimum rank (the top row of a TB graph). The difference between them is that min will allow other subgraphs in the minimum rank. Source will not. Source only allows other subgraphs of min or source to be on the minimum rank.
Consider the following graph snippet:
{ rank=source; a -> b; }
{ rank=same; c -> d; }
You will end up with 2 rows. a -> b will be above c -> d.
If you change source to min, you will only get one row. a -> b will be to left of c -> d, all in the min rank.
{ rank=min; a -> b; }
{ rank=same; c -> d; }
Max and sink are the equivalents for the bottom of the graph.