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

Better specify PowerFlowData parametric type aliases #50

Open
GabrielKS opened this issue Oct 17, 2024 · 2 comments · Fixed by #48
Open

Better specify PowerFlowData parametric type aliases #50

GabrielKS opened this issue Oct 17, 2024 · 2 comments · Fixed by #48
Assignees

Comments

@GabrielKS
Copy link
Contributor

GabrielKS commented Oct 17, 2024

This:
Screenshot 2024-10-16 at 11 40 16 PM
is

  • deeply unsettling and
  • problematic for multiple dispatch.
@GabrielKS GabrielKS self-assigned this Oct 17, 2024
@GabrielKS
Copy link
Contributor Author

GabrielKS commented Oct 17, 2024

I'm not fully convinced that these pseudo-subtypes should be based on the types of the matrices they contain; that feels like an implementation detail, even though it's a pretty fundamental one. One can at least in principle imagine a pair of PowerFlowDatas with the same types of matrices except you want to solve them differently. Maybe the PowerFlowData contains the PowerFlowEvaluationModel it was constructed with, is parameterized on that, and that's what the aliases key onto (or at that point it's readable enough that we don't need the aliases)? Or maybe one is required to pass a PowerFlowEvaluationModel to solve_powerflow! along with the PowerFlowData? Guess this overlaps with #38.

@GabrielKS
Copy link
Contributor Author

For now I'll just strictly specify vPTDFPowerFlowData as has been done for all the other aliases. I still think this might warrant rethinking more deeply later.

@GabrielKS GabrielKS linked a pull request Nov 5, 2024 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant