-
Notifications
You must be signed in to change notification settings - Fork 23
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
Unify calls to read json resource from e-mission-common in generate_plots.py #164
base: main
Are you sure you want to change the base?
Conversation
iantei
commented
Oct 3, 2024
- We had multiple calls to emcu.read_json_resource("label-options.default.json"). I have moved the call for emcu.read_json_resource("label-options.default.json") into generate_plots.py such that we can pass either dynamic labels or default labels based on availability for program/study in their respective config file.
- Replaced "dynamic_labels" with "labels", as we it can be either dynamic labels or default labels.
- Removed all checks for dynamic_labels as we are already passing the proper labels from the generate_plots.py
…e program/study name from the database name of the dataset.
- Pass labels instead of dynamic_labels to the notebooks - labels can either be: - Custom labels from the program deployment config, from nrel-openpath-deploy-configs - In case, we do not have custom labels for the program/study, load default labels from e-mission-common with read_json_resource
…e-mission-common in scaffolding.py Replace dynamic_labels with "labels" - labels could be either default labels or dynamic labels (provided for program/study) depending on availability in config file - Use labels passed from notebook instead of calling read_json_resource("label-options.default.json") from e-mission-common Remove async and await for mapping_color_labels() and translate_values_to_labels() Remove filtering for dynamic_labels availability, as we will only have either labels or dynamic_labels. Update load_viz_notebook_* functions to use labels instead of dynamic_labels
…abels() and translate_values_to_labels().
…move filter for dynamic_labels, since we pass either dynamic_labels or labels based on the availability of dynamic labels in program/study config.
… Remove await for mapping_color_labels() and translate_values_to_labels().
…ince we pass dynamic labels or labels based on the availabilty in study/program's config file.
Testing Scenario: Dataset used: Detailed execution of notebooks using generate_plots.py:
Note: We cannot run the mode_specific_* notebooks and survey_notebook_* since this is not a program or a survey related study. Results:
All charts are loading properly. |
Tested for both configuration of |
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.
Great refactor! Loading the default label options upfront definitely simplifies the codebase, with fewer functions needing to be async.
I just have a couple comments.
viz_scripts/bin/commit_message.txt
Outdated
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.
Did you mean to commit these commit_message.txt
files?
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.
Ah, I tried to use git commit -F <file_name.txt>
. I didn't realize it had checked-in these files as well. I will remove these commit files.
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.
Removed the commit_message.txt files
@@ -54,9 +54,8 @@ def get_participant_uuids(program, load_test_users): | |||
disp.display(participant_list.user_email) | |||
return participant_uuid_str | |||
|
|||
async def add_base_mode_footprint(trip_list): | |||
async def add_base_mode_footprint(trip_list, labels): |
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.
Is there a reason this one is still async
?
I think if you make this one synchronous, you can also make load_all_confirmed_trips
, load_all_participant_trips
, and the load_viz_notebook_*
functions all synchronous.
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.
Yes, we are calling await emffc.calc_footprint_for_trip()
for the calculation of footprint for the trip inside add_base_mode_footprint()
. Therefore this function needs to be an asynchronous one. That in turn has resulted in load_all_confirmed_trips
, load_all_participant_trips
and load_viz_notebook_*
functions to remain async.
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.
Ah, I see now. Thanks for explaning
…e parameter for load_viz_notebook_sensor_inference_data().
…em-public-dashboard into unify_read_json_resource