Explain cluster ordering

I really don't understand how clustering affects ordering.

As you can see here:
[graph1] http://pastebin.com/8kgRQ7mx generates => http://g.jk.gs/tT.png

The nodes under group "u1_main" appear at the top of the image; this makes sense seeing as how they appear first in the code.

Now throw clustering into the mix and we get a few problems as you see here:
[graph2] http://pastebin.com/DN6qYLAq generates => http://g.jk.gs/tQ.png

This begs for explaination.
1. Why would cluster_u1 appear at the top of the image even though it comes after cluster_r1 in the code?
2. Why do the groups appear to be climbing in cluster_r1?
note: to keep things simple, I trimmed down the code to only what I thought was minimal to demonstrate the problem. In more complex graphs ( ie: [graph3] http://pastebin.com/xKzNN1GX => http://g.jk.gs/tU.png ), the clusters tend to climb instead of descend.
3. Why in graph2 would "User1/iss01" and "d1" straddle the u1_main branch?

Bonus question: As you can see, in order to create distinct nodes for each cluster, I need to prefix them; In order to demonstrate duplicate repos on different machines, this requires me to label all the nodes individually which is confusing and tedious. I know that one can use "ports" with tables, and "fields" with records... is there any way such devices (or something else I don't know about) can be used to isolate the groups so instead of labeling everything, I could just type (if I wanted) r1:c3->u1:c3 ?

Lastly, a tip for anyone who finds it useful (I know, way OT but), you can set global attributes to the names of attributes;
node [color=fillcolor]
0 [fillcolor="red"]

this will set 0's color & fillcolor.

The answer to 1) and 2) are

The answer to 1) and 2) are basically the same. The rankdir=LR is done by doing a rankdir=TB layout and then rotating counterclockwise by 90 degrees. In TB, earlier nodes appear on the left, and expand to the right. Rotating, this means earlly nodes appear below and nodes expand upwards.

3) is a form of bug. The crossing reduction code does handle crossings by "flat" edges well, so you end up with an edge crossing. You can avoid the actual node crossing by allowing splines=true. As a workaround, you can add

u1_c1 [label="c1" ordering=out]


Not sure I understand the bonus question. How is r1:c3->u1:c3 better than r1_c3->u1_c3?

Re: The answer to 1) and 2) are

I don't get it;

When I specify rankdir as TB, here:


earlier nodes appear on the *right* -- exactly opposite of what I expected.

Re: Bonus -
The tedious part is the labeling. I was hoping to be able to something along the lines of this:

subgraph cluster_alpha {
a -> b -> c;
subgraph cluster_beta {
a -> b -> c;

alpha:a -> beta:c;

As I understand it, that's not possible, but I'm hoping for a something in the same vein.

Recent comments