Flow decompossition

[BazilSansom]

We discussed that decomposition into circular flow network and potential flow network could be useful for systems maps.

This could also be useful for other potential users and applications.

Just putting in a marker for now: to consider whether this decomposition is something we would like to add to Gephi tool. It's just solving another linear equation evaluated using trophic levels (I would provide explanation and references). I suppose could easily be reported as circ flow weight and potential flow weight in data table for edges. Question over whether/how visualisation of this decomposition could also be made easy.

[WouterSpekkink]

Yes, I was wondering about this. Seemed like a good thing to add. Let's get the easier issues out of the way first though.

[WouterSpekkink]

Could you indeed provide some references so that I can start exploring this for future inclusion?

About the visualization: I assume that this would be something like a float or double-type variable? I think it is possible to have Gephi assign a colour scale to edges (e.g., lighter colour for low values, darker colour for high values). Perhaps that would give you a visual indication of flow weights.

[BazilSansom]

Calculation:

This is simple

This is implemented by function HHD in my Python module:
https://github.com/BazilSansom/Trophic-Analysis-Toolbox/blob/master/Python_files/trophic_tools.py

Should be very simple to add calculation and save circ_weight and gradient_weight to edges datatable.

Visualisation:

Yes we can think of F_p and F_c as different networks, but it could be good to be able to visualise e.g. the circular flow on the entire network - so e.g. colour scale from no circular flow (0) to max(max(F_c)).

[WouterSpekkink]

Could you check with the 0.9.2 version of the trophic incoherence plugin that I implemented the flow decomposition correctly? Also see the latest commit for the lines of coded that I added to implement this.

[BazilSansom]

Nice work Wouter! This looks good to me and the basic decomposition is working.

I think though that we probably need to interpret so as to have positive flows only.

So once the basic decomposition is obtained (as you have already implemented) we need to interpret any negative flows as positive flows (in the other direction). Basically where a(i,j)<0 this should be changed to a(j,i)=a(j,i)+abs(a(i,j)) and set a(i,j)=0. The reason for the sum a(j,i)+abs(a(i,j) is that sometimes the gradient flow is split between a positive flow in one direction and a negative flow in the other direction.

Hope this makes sense?

[WouterSpekkink]

That makes sense. Looks easy to implement, so I will get to it.

[WouterSpekkink]

I do have a question actually: If I interpret this correctly, this could also mean that we would create a new edge (if there isn't already one there) between i and j if there is a negative flow from j to i. Is that correct?

[BazilSansom]

So it can mean the reversal of an edge - e.g. if you have a cycle, and you want to break it, you can either delete a link or reverse a link, right. HHD will lead to the reversal of a link rather than deletion - of course only if there is some gradient flow over the cycle (so think about a cycle with weighted edges where the flow isn't balanced i.e. there is some net flow from low potential to high potential nodes)! But not possible to generate the gradient/potential flow network (a DAG) from cyclic network without reversal of some edges. However the HHD won't generate a negative flow from j to i unless the edge j->i exists in the original network.. so reversal of existing edges not creation of new edges. (Of course where flow balanced, these edges won't appear in the gradient network at all...).

[WouterSpekkink]

Okay, I think I have a version that works (not commited to the repo yet). However, I still have some doubts about the desirability of this. I think we should keep in mind that we look at circular flows through attributes of the edges of the input graph, and not through the creation of a new network. I think a statistics plugin should ideally not change the network that the user runs it on.

With this new addition, whenever the user runs the plugin and whenever the plugin then encounters a negative circular flow, it will remove the original edge and replace it with a reversed one (basically what you describe as a reversal, but the practical effect is the same). I find that quite a big change, just to accomodate the resolution of negative flows. Think about the application of this method to participatory systems mapping. You are now potentially reversing the causal flows that the participants have identified. Do we really want that?

Isn't it actually just as informative to keep the negative flows, so that you can see where the network is unbalanced in its flows?

I guess that, if you really think that this is a good addition, it at least needs to be optional and not default. I think it is usually a bad idea that a staistics plugin actually changes the network.

[WouterSpekkink]

After using the plugin in an actual application, I feel that reversing edges is indeed undesirable, because it changes the original data that the user puts in. Also, the behaviour is sometimes buggy. I just commented out the part of the code that does the reversal of edges for now.