Changelog

Follow up on the latest improvements and updates.

RSS

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.
  • em
    represents the annual embodied emissions in each year.
  • op
    represents the annual operational emissions in each year.
  • av
    represents 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_cumul
    represents the cumulative operational emissions from fossil fuels from year of completion to the end of the reference period.
  • op_ref_cumul
    represents the cumulative operational emissions from refrigerants from year of completion to the end of the reference period.
  • op_elec_cumul
    represents 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
Endpoint
We'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.
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.
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_height
    is the average floor-to-floor height.
  • window_to_wall_ratio
    is 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.
  • perimeter
    is the average lineal distance around the exterior(s) of the building (including any courtyards or exclusions).
  • average_live_load
    is 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.
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.

new

General Updates

Backend updates

2.38.01 - Updated Defaults and Validation Ranges

Building on our schema updates from last week, we have improved some defaults used in the model to reflect the building's region and use type. These changes are summarized below and reflected in updates to our documentation.
There is no change in values between this version and the previous version (except where using the default values) and no breaking changes.
Regionalized Insulation Values
The default R-value of the opaque wall assembly is now set in relation to the building's climate zone. As with other characteristics of the envelope, it can be overridden using the "description" field of the
envelope.cladding
request object.
The default R-values here are recorded in our documentation.
Improved Floor-to-Floor Height Defaults
The floor-to-floor height defaults in C.Scale are now a function of use category. Floor to floor (F2F) height can still be set by users for each floor individually (if using the stacked
BuildingForm
object) or for all floors together (in the simple
BuildingForm
object).
The default floor-to-floor heights here are recorded in our documentation.
Increased Below-Grade Floors Validation Range
The API now accepts requests with up to 15 floors below-grade. If more than 8 floors are passed, the API raises a warning in the
API-messages
object.
Addition of 50-Year Reference Period
Danish LCA guidelines require a 50-year reference service life. This has been added as an option to
reference_period
.
Alias "Refurbishment" to "Service Life"
Aligning with emerging standards worldwide, all instances of
refurbishment_period
in the API are now alias'ed to
average_service_life
. We will continue to accept both, but recommend API users change over to the new label to stay in alignment with future documentation, as all future Swagger docs will reference the new parameter name.

new

Hotfix!

Backend updates

2.38.00: Backend Schema Updates

This update represents a major re-factor of C.Scale's internal schemas and how they're managed. These changes will not be visible on any of the exposed endpoints. Additionally, this change includes a minor update to the stacked
building_form
to better handle instances where the list of levels is not sequential.
Schema Updates
Objects shared by more than one request schemas are now all pulled from a single source of truth. Default values previously stored in the schema itself are now injected via functions.
These changes pay down a significant amount of the technical debt we had accrued in keeping our schemas backwards-compatible. This will allow us to develop future features faster. Additionally, this clears roadblocks for the near-term development of "smarter" defaults dependent on building type, building form, relevant standards, and other characteristics of the model.
This change has no effect on the API's use or functionality.
Hotfix for Stacked Building Form
The stacked
building_form
object was originally written to deal with non-sequential levels correctly (e.g. if the passed levels are
0,1,3,5,6
). But today we learned that the API struggled when the order of the levels in the list did not match the sequence of levels in the building (e.g.,
3,5,6,0,1
). Moving forward, we now sort all levels to be sequential before evaluating them. In these cases, we pass
message_0018
:
The building levels in the request were listed out of order. They have been automatically re-ordered prior to calculation.
Load More