Flux diagram generation issues about kda HOT 3 CLOSED

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.

from kda.

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.

from kda.

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.

from kda.