GSYE-846: export carbon_emissions when imported_exported_energy is no… #1839
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #1839 +/- ##
==========================================
- Coverage 69.62% 69.57% -0.06%
==========================================
Files 150 150
Lines 14264 14282 +18
Branches 2672 2677 +5
==========================================
+ Hits 9932 9936 +4
- Misses 3808 3821 +13
- Partials 524 525 +1 |
src/gsy_e/gsy_e_core/export.py
Outdated
| carbon_emissions = {} | ||
| if imported_exported_energy != {}: | ||
| carbon_emissions = ( | ||
| carbon_emissions_handler.calculate_from_gsy_imported_exported_energy( |
There was a problem hiding this comment.
From here, I do not see an option to provide a carbon ratio csv file, which we discussed should be possible for a cli user.
Providing the path to the carbon ration file should probably be a cli option and saved in the simulation config. Maybe there is a better way. Let's discuss.
In any case, there should be a validator that checks if the carbon ration file contains values for all time slots in the simulation .
There was a problem hiding this comment.
Yes, I should have explained why I decided to keep the country code. What we are solving with the CarbonEmissionsHandler is essentially the calculation of the carbon ratio. It is very unlikely that a cli user will spend time to generate a file with the carbon ratio for every hour compatible with our interface, because that is essentially the problem we are solving for him. In addition, the calculate_from_carbon_ratio_and_imported_energy offers a simple interface to calculate the results in a post-processing step, which is what we use in research-scripts. So, with this approach we offer a simple and accessible solution to calcule the carbon footprint from non-granular and out-of-date sources. With the file path option we could offer a flexible and precise solution to calculate the carbon footprint, but most likely nobody will use it, particularly when the real sauce for retrieving precise hourly carbon ratios from Entosoy-e is now in our private repo.
There was a problem hiding this comment.
Let me know if you agree with the explanation and if it needs further explanation. Very grateful for your attention in reviewing and discussing
There was a problem hiding this comment.
IMO this option should be provided. I am fairly certain that we will use this feature in future project studies / simulations, in which case we will need to provide detailed CO2 emission files with 15-min / hourly resolution, in order to have substantial and detailed results. Therefore we cannot rely in monthly / yearly aggregated data, but we should give the capability to the CLI user (us, essentially) to provide CO2 emission data profiles.
There was a problem hiding this comment.
Is doing in post-processing like we are doing for HSB LL a valid alternative? Should I leave it for post-processing, add the two options (country_code and carbon_ratio_file_path) or just the carbon_ratio_file_path?
There was a problem hiding this comment.
In order to avoid doing it in the postprocessing for future projects, I would recommend to just add the carbon_ratio_file_path. In order to not complicate the structure of the solution, as a starting point I would recommend to save the timeseries data from the file in the GlobalObjects singleton class, by creating a new class that is instantiated there and manages only the carbon footprint file data. This class can then be imported in the CSV results files generator, and use the Carbon Emissions in order to calculate the footprint and savings.
…n empty dict
Reason for the proposed changes
Please describe what we want to achieve and why.
Proposed changes
INTEGRATION_TESTS_BRANCH=master
GSY_FRAMEWORK_BRANCH=feature/GSYE-846