Strange visualization behavior

[vani0vani0]

Hi team,
First of all allow me thank you for the great app you've built. I find it very useful.

I am facing an issue with it, where I am trying to explore the Eigencentrality within a large group of people (100+).
The resulting dataset contains around 1500 rows with src, dest, count and all the other necessary fields for the visualization.
I actually used the same queries that are available in the app OOTB for the centrality measures.

My problem is that if a use a "| sort - src" I get one result in the visualization. When I use a "|sort src" (i.e. ascending order) then I get different result in the visualization. I.e. different nodes are marked as "influential" or "prestigious" depending on the sort order.

Is this something to be concerned about or is it expected? I am not sure, but I think the results should always be the same, when trying to visualize the eigencentrality of the same group, regardless of the sort order.

Any ideas?

BTW, same thing can be tested if you change the sort order of the graph query of the OOTB dashboard called "graph_analysis_centrality". You will get two different pictures depending on the sort order.

[pdrieger]

Hi @vani0vani0 thank you for your great feedback. Let me give some context here: the actual calculation of the eigenvector shows stable / consistent results after the | fit command. But the appearance of the graph, e.g. colors, sizes etc. that come out of the predefined dashboards can indeed vary given different ordering (src as dest and dest as src) and the colors for src and dest: in case there is a node with the same value, e.g. IP address, appearing in the list that feeds into the graph viz multiple times and probably sometimes as src and sometimes as dest: the graph viz "overrides" the last node with the last found coloring attribute. I think this would also explain, that when you flip the ordering it takes on 2 different appearances based on what was overridden last. A possible solution might be to dedup the edge list and investigate if src is also appearing on some dest field and therefore can cause a collision. Another trick could be to postprocess with eventstats or similar to "clean up" the scr_color dest_color etc. accordingly to make it stable. I respect this can be a problem and might lead to inconsistent results, so we look into possibilities how to resolve that. Thank you again for bringing this to our attention!