Get the same shape of graph with Networkx in Python with and without arrows

[aleksandar-devedzic]

I wrote a code that plots a network with Networkx lib in Python. My code works good, but I'm confused with one thing. I get totally different looks of the graphs when I use .Graph() and .DiGraph().

import networkx as nx
import matplotlib.pyplot as plt

# defining graph
analysis_graph = nx.Graph()
#analysis_graph = nx.DiGraph()

# defining relations
relation_list = [['A', 'B'], ['A', 'C'], ['A', 'D'], ['A', 'E'], ['C', 'F'], ['F', 'I'], ['F', 'H'], ['F', 'G'], ['F', 'J']]

# adding relations to the graph
analysis_graph.add_edges_from(relation_list)

# extracting nodes from relations
node_list = nx.nodes(analysis_graph)


# ADDING COLORS TO GRAPH

# defining colors for each node
colors = {"red": ["A", "B", "C"], "green": ["D", "E", "F"], "yellow": ["G", "H", "I", 'J']}
# Create a mapping of node -> color from `colors`:
node_color_map = {}
for color, nodes in colors.items():
    node_color_map.update(dict.fromkeys(nodes, color))
node_color_list = [node_color_map.get(node) for node in node_list]
print(node_color_map)
print(node_color_list)

# For getting node sizes
dict_of_node_sizes = dict(analysis_graph.degree) # for getting node sizes
print(dict_of_node_sizes)

# for giving same graph each time
my_pos = nx.spring_layout(analysis_graph, seed = 0) 

print(nx.info(analysis_graph))
plt.figure(figsize=(25,17))
nx.draw(analysis_graph, 
        pos = my_pos, 
        with_labels = True, 
        arrowsize=20, 
        font_size=12, 
        node_size=[(v+1) * 150 for v in dict_of_node_sizes.values()],
        node_color=node_color_list)

Is there a chance to get the same shape of the graph with and without arrows?

You can see the graph images here:
https://stackoverflow.com/questions/69314656/different-graph-with-networkx-in-python-when-arrows-are-used

[z3y50n]

One way I found that was able to fix your issue is doing that

if analysis_graph.is_directed():
    my_pos = nx.spring_layout(analysis_graph.to_undirected(), seed=0) 
else:
    my_pos = nx.spring_layout(analysis_graph, seed=0)

That way you always compute the undirected graph's positions.

Other than that, you can store the my_pos object and pass it to both cases.

Finally, you can use another layout that isn't producing random positions.

[rossbar]

Thanks for raising this @aleksandar-devedzic , this is an interesting corner case.

I agree with @z3y50n 's answer, though I wonder if the conversion to undirected graphs should be added to spring_layout itself. In this case, I think the difference in positions between directed/undirected graphs is due to the fact that the Fruchterman-Reingold functions convert to adjacency matrices under the hood (either scipy.sparse or numpy depending on what's installed). This affects the calculation, even though in principle I don't think FR should be sensitive to this.

I'm tempted to convert this to an issue and see if it can't be "fixed". Thoughts?

[boothby]

A simple solution is to always use DiGraphs, and specify the arrow keyword to nx.draw:

import networkx as nx
from matplotlib import pyplot as plt

g = nx.DiGraph([(1, 2), (2, 3)])
pos = nx.spring_layout(g)
_, (ax0, ax1) = plt.subplots(2, 1)
nx.draw(g, ax=ax0, pos=pos, arrows=True)
nx.draw(g, ax=ax1, pos=pos, arrows=False)
plt.savefig('arrow.png')

[aleksandar-devedzic]

Yeah, you cen move this to fixed. if analysis_graph.is_directed(): my_pos = nx.spring_layout(analysis_graph.to_undirected(), seed=0) else: my_pos = nx.spring_layout(analysis_graph, seed=0) суб, 25. сеп 2021. у 18:58 Ross Barnowski ***@***.***> је написао/ла:

…

Thanks for raising this @aleksandar-devedzic <https://github.com/aleksandar-devedzic> , this is an interesting corner case. I agree with @z3y50n <https://github.com/z3y50n> 's answer, though I wonder if the conversion to undirected graphs should be added to spring_layout itself. In this case, I think the difference in positions between directed/undirected graphs is due to the fact that the Fruchterman-Reingold functions convert to adjacency matrices under the hood (either scipy.sparse or numpy depending on what's installed). This affects the calculation, even though in principle I don't think FR should be sensitive to this. I'm tempted to convert this to an issue and see if it can't be "fixed". Thoughts? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#5101 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ATCV65PUW6TDTKO2DXLYWYDUDX5SLANCNFSM5EXODCBQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.