-
Notifications
You must be signed in to change notification settings - Fork 40
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
Split input_data into separate modules #613
Conversation
@staticmethod | ||
def get_file_components(scenario_info, field_name): | ||
"""Get the file name and relative path for either ct or grid. | ||
def _get_file_path(self, scenario_info, field_name): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we can still use the staticmethod decorator here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Think that would require moving self._file_extension
outside the class. Feels simpler to have it be an instance method since I'm not 100% sure about static methods and inheritance (though it does seem to work similarly).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oops, I did not see that the _file_extension
attribute was used
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
AFAIK, static methods will work with inheritance, as well as class methods, while the latter will be more convenient when dealing with multilayer inheritance.
d0f5ac3
to
6e0818d
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Much cleaner. Thanks!
Purpose
We need to add support for loading electrification profiles and determining the versions, but they will likely be organized differently than the existing profiles. So rather than add more conditional logic to InputData it seems like a good time to do this.
What the code is doing
Move logic to get profiles into the
ProfileInput
class. Most of this PR is renaming accordingly. The shared logic is inInputBase
which also defines the "abstract" methods that are filled in by subclasses.If we like this design (it's not perfect, but hopefully better than before) I will follow the pattern for electrification profiles, which would probably just be another subclass. I'm also on the fence about whether to separate the demand flexibility profiles but that could be another follow up PR.
Testing
Other than tox, I ran a simulation in the container environment which completed successfully.
Time estimate
20 min