Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MAINT: create KineticDiagram object and move relevant functions into class body #58

Closed
nawtrey opened this issue Jan 28, 2022 · 2 comments
Labels
API API-related changes

Comments

@nawtrey
Copy link
Collaborator

nawtrey commented Jan 28, 2022

KDA is in dire need of a more user-friendly interface. Having functional code sorted into function-specific modules isn't always a bad thing, but at this point it is quite cumbersome to perform basic tasks, even for me. It would be nice if we could define a class to handle all of the function calls and data handling so a user can do something like the following, given a pre-defined rate matrix K:

import kda

KD = kda.KineticDiagram(K)

KD.calc_state_probs(store_diagrams=False, store_expressions=True)
KD.calc_net_cycle_fluxes(store_diagrams=False)

# print out results
print("State probabilities: ", KD.state_probs.values)
for cycle, net_cycle_flux in zip(KD.cycles, KD.net_cycle_fluxes):
    print(f"Net cycle flux for cycle {cycle}: {net_cycle_flux}")

# print out state probability expressions
for i, expression in enumerate(KD.state_probs.expressions):
    print(f"Expression for state {i+1}: {expression}")

Having a central object to store all of the various information associated with a kinetic diagram would substantially simplify the process to go from a simple rate matrix to a complex set of expressions or diagrams. I think this would make the user experience much more delightful, and prevent a lot of user errors since some of the functions are a bit tricky to use.

@nawtrey
Copy link
Collaborator Author

nawtrey commented Aug 1, 2023

I've thought about this a bit more, and there may be some downsides to creating a new object for storing all of the info. The networkx.MultiDiGraph() object offers quite a bit of features that may be worth keeping, so it may be better to keep everything within that object instead of making our own. We could inherit its methods into our own object instead, but there may be some reasons not to do that either. Whatever gets us an easy-to-use interface without losing all of the well-developed NetworkX methods will take the cake.

Before moving forward it would be worthwhile to review other similar objects and see how others are handling similar situations. The MDAnalysis.Universe object comes to mind.

@nawtrey nawtrey added API API-related changes and removed maintenance labels Aug 1, 2023
@nawtrey
Copy link
Collaborator Author

nawtrey commented Aug 8, 2024

Addressed in GH-83. Closing.

@nawtrey nawtrey closed this as completed Aug 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
API API-related changes
Projects
None yet
Development

No branches or pull requests

1 participant