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

Refactor how we support or do not support some Component types. #16

Open
josephmckinsey opened this issue Nov 12, 2024 · 0 comments
Open

Comments

@josephmckinsey
Copy link
Collaborator

josephmckinsey commented Nov 12, 2024

Often, we have very case-specific code that specifically ignores or selects certain types such as "TransformerTypes" in lines.

https://github.com/NREL-Sienna/PRASInterface.jl/blob/4af507db21695cc6bf5963111162a92f8a422cbe/src/PSY2PRAS.jl#L818

This is somewhat worrying for multiple reasons:

  • What is a transformer actually is connecting multiple regions? In that case, this code may disconnect a network.
  • We cannot support custom types, and we are unclear about which types are supported. This makes pre-emptive error checking on Systems impossible.

I would like to have a function that we can define on components which indicates that we support it as well as indicates which interfaces should work.

function supports_resource_adequacy(component_type::Type{T}) where {T <: PSY.Component}
    return false
end

For anything that supports resource adequacy, we would need the existence of certain functions such as line_rating.

function line_rating(branch::T) where {T <: PSY.Branch}
    error("$(PSY.get_name(branch)) with type $T has unsupported type")
end

Ideally, the "Branch" interface would be documented, testable, and declared in main-line Sienna.

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

No branches or pull requests

1 participant