Cryptic dot error message for graph with big (sub)clusters - graphviz

Question

I've written a little tool dumping (in dot format) the dependency graph of a project where all the files living in the same directory are gathered in a cluster. When I try to generate a pdf containing the corresponding graph, dot starts to cry:
The command dot -Tpdf trimmedgraph.dot -o graph.pdf produces the cryptic error message Error: install_in_rank clusterReals virtual rank 21 i = 0 an = 0 which does not yield any result on google.
I've tried to edit trimmedgraph.dot manually: turning the subgraph clusterReals into Reals yields a file that can be compiled but all the content of my Reals/ directory is obviously not gathered anymore.
Is there a way to generate only dot-valid files (I was planning to send my patch upstream eventually but if I cannot guarantee that everything will be okay...)?
I've put the two versions of trimmedgraph.dot online but they are rather big and given that I have no idea where the problem is, I cannot really come up with a minimal file recreating the problem.

Answer 1

I think (but couldn't find any documentation about this) cluster names have to be unique within the entire dot file. In your file however, there are two subgraphs called clusterReals.
The solution is to make sure all cluster names are unique - since the name doesn't appear anywhere in the output, you may just use numbers when generating dot files.
A quick test shows that strange things happen when reusing the same cluster name:
digraph dependencies {
subgraph cluster0 {
label="First cluster 0";
Node1;
subgraph cluster0 {
label="Second cluster 0";
Node2;
}
}
subgraph cluster0 {
label="Third cluster 0";
Node3;
}
subgraph cluster1 {
label="Cluster 1";
Node4;
subgraph cluster0 {
label="Fourth cluster 0";
Node5;
}
}
}
All the cluster0 seem to be merged together (nodes, label), unless it is not possible because they're included by other clusters. At least that's what it looks like... Since the consequences are unpredictable (error in your case), I'd try to always use unique cluster names.