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 hopp solver #305

Merged
merged 15 commits into from
Apr 22, 2024
Merged

Refactor hopp solver #305

merged 15 commits into from
Apr 22, 2024

Conversation

bayc
Copy link
Collaborator

@bayc bayc commented Apr 5, 2024

Refactor HOPP solver to be more modular

This PR generalizes the HOPP dispatch structure to more easily allow for the inclusion of new technologies and facilitate debugging of the dispatch codes. This will also support adding new dispatch strategies.

Related issue

#307
#308

Impacted areas of the software

The dispatch classes and code.

Additional supporting information

Most of the changes are moving code from hybrid_dispatch.py into the respective technology dispatch classes.

Other significant changes are calling general functions from HybridDispatch such as self.power_sources[tech]._dispatch._create_variables() while looping over technologies instead of building the attribute to be retrieved with through strings. This will make debugging easier.

The remaining changes are mainly formatting the code for improved readability.

Test results, if applicable

The tests will be passing.

@bayc bayc added enhancement New feature or request refactor Associated with the refactor of HOPP labels Apr 5, 2024
@bayc bayc self-assigned this Apr 5, 2024
@bayc bayc force-pushed the feature/refactor_hopp_solver branch from 223fc0c to ae0fcb6 Compare April 6, 2024 16:51
Copy link
Collaborator

@kbrunik kbrunik left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it looks really great in general. I do think that while we go about refactoring different pieces of the solver that it would be valuable to add docstrings.

At a minimum I'd like to see a docstring for each individual technology dispatch and for each objective function.

I think it would be valuable to add docstrings for the functions you've added/changed even internal functions to help make it easier for future developers to add additional technologies and start to understand the various pyomo connections.

Copy link
Collaborator

@jaredthomas68 jaredthomas68 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree with Kaitlin. This looks fine, but some doc strings would go a long way. Since you are up against a milestone I'm fine with merging it in now, but at least make an issue to add the doc strings. I also pointed out one typo that should be fixed prior to merge.

@bayc bayc force-pushed the feature/refactor_hopp_solver branch from 0103e50 to b63c22c Compare April 19, 2024 17:54
@bayc bayc merged commit 55b39dd into NREL:develop Apr 22, 2024
4 checks passed
@bayc bayc deleted the feature/refactor_hopp_solver branch April 22, 2024 16:20
@bayc bayc mentioned this pull request Apr 22, 2024
3 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request refactor Associated with the refactor of HOPP
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Generalize adding new generation technologies Look at generalizing objective function structure
3 participants