seed
seed copied to clipboard
BETTER - GHG emission reduction units
Describe the bug
The GHG Emissions Reduction value in the BETTER HTML Report == MTCO2e (metric tons)
The BETTER Potential GHG Emissions Reduction field in SEED == kgCO2e (kilograms)
Seems like they should be the same
Expected Behavior I expected for all the values in the BETTER HTML report to match the SEED BETTER field values
Actual Behavior Values didn't match for GHG Emissions Reduction
Steps to Reproduce n/a
Instance Information
Instance: dev1 SHA: 7dadf4020 Org: LBNL 444
As some context, we get two types of responses from BETTER about an analysis. The standalone HTML file, as well as a JSON representation. See here for how that looks: https://gist.github.com/nllong/880ee0af2aea3e0e5f355d12f3a7e53d
They actually provide kgCO2e in the JSON data, which is what we use in the inventory list, e.g. https://gist.github.com/nllong/880ee0af2aea3e0e5f355d12f3a7e53d#file-better-json-L113
They don't explicitly say this is kgCO2e, but if you compare this to the value in HTML report, you'll see that the value is something like x 10^3
@nllong -- make sure I have characterized this properly based on the DOE Tools meeting today.
Here is the clarification from Paul Matthew per the guidelines he is developing
-
GHG Emissions Reduction
- Units == MTCO2e
- SEED needs to report in these units for BETTER and BuildingSync
-
GHG Emissions Intensity Reduction
- Units == kgCO2e/ft2
- BETTER will need to change the units on their HTML report
@nllong / @macintoshpie -- should we make 2 issues from this, one for the SEED change, one for the BETTER change ?
I'm ok with keeping the ticket as is, thanks for the update Robin 😃 . It sounds like the SEED-specific work is making sure that we're showing GHG Emissions Reduction as MTCO2e instead of kgCO2e
Yup !!
This issue has been automatically marked as stale because it has not had recent activity within 60 days. It will be closed if no further activity occurs. Thank you for your contributions.
I am removing the stale label, as we need to keep this on the list.
This issue has been automatically marked as stale because it has not had recent activity within 60 days. It will be closed if no further activity occurs. Thank you for your contributions.
I am unsure what to do for this ticket. I ran an analysis and got a GHC Emmissions Reduction value, but it was reported in the HTML as 3583.5 tCO2e:
However, the value being reported in the results was 3583454.05 (this value comes straight from the analysis and shouldn't be undergoing any unit conversions):
This would make sense if the HTML was reporting MTCO2e (Metric Tons), as the actual value would then be 3583454.05 kgCO2e, but it's listed as tCO2e (Tons). For now I am going to assume the HTML is intending to report MTCO2e as commented earlier by @RDmitchell and scale by 1000 to ensure the HTML and the stored values line up.
I'll let @RDmitchell chime in too. According to the latest version of the BPS scoping document, it looks like we need to report Carbon in metric tons CO2e, so I think we need to do a database update. The conversion of kg to metric tons is just multiplied by 1000, so the math is right above. This also impacts the buildingsync world @laurenliz22.


At the tools meeting today, it was decided that the abbreviation for metric tons is "Mt" (not "t") ie MtCO2e
@Ryoken -- I have moved this from Test to In Progress to make this small change, ie, the "case" of the units
@RDmitchell -- This PR currently has the units at "MtCO2e". Is there another change that needs to be made?
@Ryoken -- if the units are already "Mt..." then no other change is needed. I just wanted to make sure that it wasnt' "MT.."
thx
Instance: dev1 SHA:
There are still units discrepancies between the BETTER report displayed in SEED and the fields populated in SEED with the BETTER results.
In the example below, which only has electricity savings, no fossil fuel savings:
- Energy Savings
- BETTER == kBtu
- SEED == kWh
- GHG Emissions Reduction
- BETTER == MTCO2e
- SEED == kgCO2e
@Ryoken -- this doesn't appear to be fixed ... ??
Unless I am missing something.
Looking into this using a test property...
BETTER is reporting via the API: 'energy_savings_f': 398490.59508147935 'ghg_reductions_combined': 72234.39017041973
BETTER is reporting via the HTML: Potential Energy Savings: 1,359,706 kBTU GHG Emissions Reduction (tCO2e): 72.2
I am not sure what to do here. All of our unit conversions are done based on the assumption that the units coming from the API are the same from call to call. Enery Savings was kWh and Emissions Reduction was kgCO2e (which after a .001 mulitplier gave us MtCO2e) . Are they subject to change with each call, or have they just recently changed on BETTER's side? Regardless, the units we show and the units in the HTML report can't be conistent until we get consistent units from the API.


Also, regarding the screenshot listing BETTER values on the property detail page: I am not sure why these are even here, but new BETTER analyses will create extra data columns with the correct units and show them on the property list. (see above screenshot)
I think the BETTER values should be on the property detail page, just like any other field, as well as in the property list.
@nllong -- is this units issue something we need to discuss with the BETTER team (Han) so that they are sending results in consistent units via the API returns?
I can't test this because I don't have a file with meter data that I can import into SEED - see #3450
Instance: dev1 SHA: 449f54dcf
This issue has been automatically marked as stale because it has not had recent activity within 60 days. It will be closed if no further activity occurs. Thank you for your contributions.
closing for release. Reopen if we discover that this is still an issue.