Changelog
Follow up on the latest improvements and updates.
RSS
new
General Updates
Additional Time Series Data
In this release, we are adding additional data streams to the
timeseries
response object to support an API user's development. The following keys were added:
- av_biogenic_cumul: cumulative biogenic carbon storage in a year
- av_pv_cumul: cumulative emissions avoided by onsite PV in a year
- op_elec_cumul: cumulative electricity use-related emissions in a year
In this minor update, we've added
pv_array
to the response object of the /calculate
and /carbon-intensities
endpoints. Accessing New Fields
Users can access the
pv_array
carbon intensity in the /calculate
endpoint by returning response.carbon_intensities.pv_array
.Users can access the
pv_array
carbon intensties in the /carbon-intensities
endpoint by returning response.pv_array
. This object follow the same structure as the other keys in the response, and will return all three levels of specification (Conservative, Best Practices, and Low Carbon), along with the data source and units of the carbon intensity.In this update, we have enhanced the granularity of the timeseries response object; users will be able to view cumulative operational emissions with more resolution, alongside their annual emission counterparts. Additionally, we have made significant improvements to our testing suite, expanding coverage for the /carbon-intensities endpoint. Lastly, we have adjusted the validation process for the C.Scale parameters, specifically for primary percentages related to
use_category
and structure
. This change aims to provide more flexibility when a second use_category
and/or structure
is not explicitly specified.New Timeseries Responses
We've added
em
, op
, av
annual emissions to the timeseries object.- emrepresents the annual embodied emissions in each year.
- oprepresents the annual operational emissions in each year.
- avrepresents the annual avoided/stored emissions in each year.
We've also added
op_foss_cumul
, op_ref_cumul
, and op_elec_cumul
cumulative emissions, these break down the categories that make up operational emissions (fossil fuels, refrigerants, and electricity).- op_foss_cumulrepresents the cumulative operational emissions from fossil fuels from year of completion to the end of the reference period.
- op_ref_cumulrepresents the cumulative operational emissions from refrigerants from year of completion to the end of the reference period.
- op_elec_cumulrepresents the cumulative operational emissions from electricity from year of completion to the end of the reference period.
Primary Use/Structure Validation and Messages
If there is no
secondary_(use/structural_system)
explicitly defined, the validation for primary_(use/structural)_percentage
has been loosened to accept values other than 100
. If the user inputs a value other than 100
and there is no secondary use_category
and/or structure
, the model will default this value back to 100
and the user will see message_0022
and/or message_0023
.message_0022
: "Primary use percentage does not equal 100% when a secondary use category has also not been defined. Primary use percentage has been defaulted back to 100%."message_0023
: "Primary structural system percentage does not equal 100% when a secondary structural system has not been defined. Primary structural system percentage has been defaulted back to 100%."Additional Test Coverage for the
api/carbon-intensities
EndpointWe've expanded our regression testing suite to include the
/carbon-intensities
endpoint. This allows us to monitor and report changes to this endpoint that happen in the course of development. new
General Updates
Hotfix!
2.38.08: Glazing Improvements, Bug Fix for Legacy Schema
With this update, bills of materials for glazing assemblies are calculated live with each request, rather than preprocessed and then intermittently uploaded. The updates in performance with our re-deployment to AWS Lambda made this possible, and we will be extending this approach to other assemblies in the balance of 2024.
Glazing Improvements
Moving forward, every request to the API will generate a bill of materials for glazing assemblies rather than referencing "pre-baked" bills of materials or carbon intensities. This allows for more precise regionalization of results. The background refactoring necessary to make a transition to a dynamic bill of materials-based approach possible for all other assemblies in C.Scale's calculation engine.
Since the background data previously used and the new approach take the same approach and are based on the same methodology, there new results are within 1-5% of calculations in previous versions.
Bug Fix for Legacy Schema
With the recent improvement to below-grade excavation and structural emissions, a minor difference in calculation for below-grade floors had opened up between the simple and stacked schemas. This update addresses the bug, and adds greater testing coverage to these schemas to ensure their results are aligned moving forward.
Expanded Regression Testing
We have significantly updated our approach to regression testing, unlocking the ability to version the API results based on the degree of change from one update to the next. The specifics of this versioning are still under development, and we are open to feedback on how it is implemented. In future release notes, we will provide quantitative reports on differences in calculation from one version to the next.
This is a minor update to the geodatabase, patching an error where the geodatabase was being inconsistently queried for recently added geographies (Saudi Arabia, UAE, and Singapore). We have now updated the entirety of the geodatabase to the latest version (which we developed in parallel with the 2.37.00 updates).
With this update to geodata, there will also be a minor regression on some structural emissions or envelope emissions as relates to data regionalization. In our testing, this change is less than 5% everywhere.
new
General Updates
New Features!
2.38.06: Unconditioned Parking + Excavation Emissions
With the addition of
Unconditioned Parking
as a use type in C.Scale, now all users can measure and get bummed out about emissions related to structured parking. We've also addressed a peer review comment on our models with the addition of excavation emissions to all construction below-grade. Unconditioned Parking
Now, both
Conditioned Parking
and Unconditioned Parking
are available as use types. Life cycle emissions from both are modeled alike, with the one difference being that Unconditioned Parking
does not have associated MEP emissions. To make this change, we changed "conditioned area" from a global parameter to one that can be defined for each level of the stacked building form. Where no value is passed, a use-specific default (typically 100%) is used. Declaring a global value for
conditioned_area
still functions as expected, overriding all locally defined values. This change also gives us a clear path to the calculation of a richer set of area metrics (CFA, GFA, GIA, etc.), a much-requested improvement we will be targeting in a near-term release. Excavation Emissions
Following Roy et al. (2024), we are now including estimates for excavation emissions for all below-ground construction.
Additional Tests
This update also includes an updated testing suite designed to catch and prevent errors like the one leading to the 2.38.05 hotfix.
About an hour ago, a user alerted us to suspiciously high numbers coming through from the Simple BuildingForm. We traced this to an error in the data model where a percentage [0,100] was being interpreted as a proportion [0,1], leading to a 100x mis-estimation of the envelope area take-offs.
This bug is fixed and coverage to these cases will be added to the testing suite later today.
We've added more resolution in the Life Cycle Stages schema. For specific descriptions of each measure, please refer to our API documentation under
request_LifeCycleStages
. With this update, users can individually include/exclude B1
, B2_5
, B6
, D1
, D2
, and biogenic
stages. We've also added new response outputs to structural_quantities
and areas
. Finally, Conditioned Parking is now being offered as a use type. These updates do not result in any differences in our model's calculations. Added B Phase Resolution
Currently, C.Scale's B-phase module includes
B1
("in-use" emissions), B2_5
(maintenance, repair, replacement, refurbishment emissions), and B6
(energy use emissions across all fuel types) life cycle stages, which are included by default. A user can access all of these at the top-level using scope.B1_6
, which will include/exclude all B-phase stages, or at the sub-level (i.e., scope.B1_6.B1.include
), which allows inclusion/exclusion of individual stages.Added Benefits Resolution
C.Scale's benefits module includes
D1
(recovery, construction, use, and end-of-life carbon burdens), D2
(avoided emissions from the grid), and biogenic
(storage and release of biogenic carbon), which are included by default. A user can access all of these at the top-level using scope.benefits
, which will include/exclude all benefit stages, or at the sub-level (i.e., scope.benefits.D1.include
), which allows inclusion/exclusion of individual stages.New Response Parameters
floor_to_floor_height
, perimeter
, and window_to_wall_ratio
are new area
response parameters, and average_live_load
is a new structural_quantities
response parameter. - floor_to_floor_heightis the average floor-to-floor height.
- window_to_wall_ratiois the proportion of glazing to total vertical envelope. If the user is sending a request using the Stacked Building Form schema, this parameter is calculated using a weighted average by facade area approach.
- perimeteris the average lineal distance around the exterior(s) of the building (including any courtyards or exclusions).
- average_live_loadis the average live load design criteria. In the Stacked Building Form schema, this is done using a weighted average approach.
Conditioned Parking
Conditioned Parking is now a supported use type in the C.Scale API.
New API Messages
The API
message_0021
will be triggered when a user uses the Stacked Building Form schema and selects a structural system other than Reinforced Concrete for a below-ground level. Since below-ground levels with non-Reinforced Concrete systems are not currently represented in the background data, the system will default to Reinforced Concrete for such requests.Data Centers are now a use type supported by the C.Scale API.
The inclusion of data centers is an experimental feature. When a Data Center is declared in the API, we pass
message_0020
: Data Centers are included in C.Scale as an experimental feature with limited background data to support our predictions (esp. for all life cycle phases beyond A1-A3). Proceed with caution, and note that this use category may be removed from a future release.
Additional notes on Data Centers
- Estimates for refrigerant volumes in data are likely too low to be reasonable. This will be addressed in a future release.
- Embodied carbon in Data Center MEP is a function of energy use.If the request does not include an estimate of data center energy use, a default value will be used. Energy use in data centers is much more variable on an absolute basis than for other use types, and its veracity will depend on the user-entered value for EUI.
new
Hotfix!
2.38.02: Site Area Hotfix
This morning, a user alerted us to a validation error in
site_area
for a request using the "stacked" building_form
object. This hotfix addresses that bug, and adds additional tests to check for it moving forward. Load More
→