Flux diagram generation issues

[nawtrey]

Improvements:

• Need to add check into flux diagram generation that makes sure each generated flux diagram has only 1 valid cycle in it
• Need to add more stringent sorting of generated flux diagrams: each relevant flux diagram must contain the entire cycle of interest, not just the nodes for that cycle (add edges check)

These issues have caused problems when evaluating diagrams with many more edges than nodes (nodes have multiple pathways away from them).

[nawtrey]

The real problem is that to properly define a cycle you have to have the list of edges belonging to that cycle, which is not how NetworkX defines cycles. They use a list of nodes to define a cycle which is inherently ambiguous. For a given set of nodes, there can be many ways to draw edges between them. Now, it is only ambiguous if the order is not specified, at least for all of the cases I have observed.

[nawtrey]

Small fix has been added to kda.generate_flux_diagrams(). It now checks if input cycle contains all nodes in the input diagram and returns "None" if so. Still allows for the operation of kda.calc_cycle_flux() without a glitch, but the issue of valid cycles that contain all nodes still needs to be addressed. Maybe write a new function just to find all possible cycles that contain all nodes in a diagram, such that users who are looking at these cycles can easily obtain a list of all of them since kda.find_unique_cycles() will only give them 1.

[nawtrey]

A slightly better band-aid has been added, where it takes in an input diagram G and finds all the possible node lists (cycles) for that diagram. For simple diagrams where the number of unique edges is equal to the number of nodes, there should only be 1. But for more complicated diagrams, there can be many different ways to put N edges in M possible locations (N is number of nodes, M is number of edges). For the time being, if one wants to calculate the cycle flux of a cycle that contains all possible nodes, they can use the normal process, but they should keep in mind that the order of the nodes matters in that context. This is now added in a print statement if this case arises.