This versions brings a whole new kind of feature in the API - PDF reports - and continues a series of planned improvements to the structural models ahead of their next major update.

As architects prepare their reporting for the AIA 2030 Commitment, we're providing a series of PDF reports to allow them to easily reconcile modeling scope in C.Scale with the DDx reporting requirements.

While the calculation endpoints remain stateless, the PDF endpoint requires the temporary storage of user data (for up to 30 days). These data are organized in an AWS S3 bucket using the field added to the top-level of the schema. If a is not passed, the PDF is stored in a dir.

To populate the project phase field of the PDF, we have also added a field to the API request.

Previously, the API could not accept the explicit declaration of a percent reduction to energy use intensity. Instead, users had to query the API, return the result, calculate the reduction and query it again with the new value - eesh. Now, the API does all that for you :] and you can declare the reduction as a percentage against the quantity declared in - yee!

In this version, we continue to deploy incremental improvements to our structural estimation models. These changes create a diff in the structural results. In this update, the emissions for Reinforced Concrete structures are lower in some cases, and the emissions from some Mass Timber buildings are higher. Across the 1,600ish buildings in our regression set, we saw the following changes to the structural emissions:

With the minor increases in some mass timber structures and the largest reductions in reinforced concrete structures.

In some US locations, users querying the object and passing both a and a were encountering calculation errors due to errors in queries to background energy use benchmarking services.

These errors have been addressed, and our testing suite expanded to ensure stability. We recommend re-running any projects which meet the criteria above.

The endpoints were affected.

This patch contains a few small improvements and housekeeping items.

A minor update to allow the endpoint to query correctly when a US or Canadian postal code is passed; previously, the endpoint only accepted a lat/long pair.

When passed in a primary and secondary structural system in the of a building, the average live load parameter was not being correctly area-weighted. Instead, only the value for the primary structural system was used in formulating the response (even though both were used correctly in the calculation). In this update, the live load exposed in the response body is correctly area-weighted.

While we were at looking at live loads, we pulled out good ol' ASCE 7-16 and phoned some engineer friends for a friendly review of our live load values, making a few small tweaks and a more substantive update to those used for distribution centers and warehousing. These updates will yield a minor diff for those use types.

The changes in the default live loads change have a minor effect on the structural emissions. Across the 1,600ish buildings in our regression set, we saw the following changes to the structural emissions:

With the largest (positive) changes to warehousing and distribution centers.

Previously, we used a simplified per-area model to account for emissions from building interiors. This general model has been replaced by an assembly-level model which accounts separately for interior wall construction and finishes, doors, casework, ceiling construction and finishes, floor finishes, and furniture & equipment. This high-resolution model is primarily governed by the building’s declared use category.

Note that this makes references to in the API request and response a bit of a misnomer - these data and emission estimates include both tenant fit-out and all interior construction/finishes and applies to use categories where there aren’t tenants doing fit-outs. To prevent breaking changes, this naming convention will be preserved until a more holistic overhaul of naming convention occurs.

This update will, in all but a few cases, increase interiors-related emissions. Across the 1,600 buildings in our regression test set, the changes to interiors-related emissions are as follows:

We'll be exposing more granular editing capabilities to this model in upcoming releases.

This update improves C.Scale's support for 2.5D geometry by extending it's stacked building form to handle cases where a building has multiple masses, but building levels across those masses are not aligned.

One common use case is multiple towers on a shared podium. If one tower contains offices and another housing units, each tower will have different floor to floor heights. Accordingly, "level 16" in the first tower may be at a different vertical datum than "level 16" in the other.

This is now handled by allowing the API to accept nested lists, where each nested list is a "mass" of the building with unique levels. A mass, like any building passed in the stacked form, must have a ground level () and does not describe architecturally exuberant cantilevers.

A Python Notebook with some common use cases is available on Google Drive.

There are no changes in results.

In a previous update (version 2.40.00), we introduced updates to the structural quantity predictor models, which we continue to improve here. This update complete the implementation of the previous updates across all use types and structural systems. Additionally, we cleaned up naming conventions throughout the app to set the stage for new features.

This update will, in all but a few cases, increase structure-related emissions. Across the 1,600 buildings in our regression test set, the changes to structural emissions are as follows:

Hotfix! In the last model update, we removed an internal check on the structural quantities estimation which reconciled the estimations for each structural material and compared their sum to the separate prediction of SMQi. This led to a large diff in some cases, and occasionally unrealistic results. This reconciliation step has been re-added.

We’ve updated our structural quantity predictor models to address some underlying issues with how structural emissions are calculated. Additionally, we’ve modified the refrigerants response object to always display values, even when refrigerants are out of scope.

Previously, structural quantities for Reinforcing Bar and Structural Steel were inconsistently estimated, overestimated in low-rise and underestimated in high-rise buildings. With peer review comments from colleagues at global engineering firms, we updated these models. Additionally, we’ve improved data coverage for high-rise buildings. Users can see up to a 20% increase in structural emissions and, in fewer cases, a decrease of up to 10%.

Previously, displayed values only when refrigerants were included in the scope of the request (). Otherwise, the object would look like this:

We’ve adjusted this behavior so that these values now display regardless of whether refrigerants are in scope. Note that the scope for refrigerants () is already set to by default if not explicitly defined, so most users will not need to make additional adjustments.

In this update, we are preparing for new features by cleaning up endpoints, deprecating fields, and loosening validations.

We have removed upper-limit validations on and , migrating these checks to warnings instead. If a user inputs floor areas that exceed the previously validated limits, and/or will appear in . This allows users more flexibility while still raising awareness of the possible limitations of our model.

The field has been deprecated. This field allowed for comparisons of buildings with different areas, which could lead to inconsistent evaluations by comparing unlike buildings. To create such comparisons, we recommend sending separate payloads with the desired floor areas instead.

The and endpoints have been deprecated as part of our effort to consolidate our API. Users can still generate equivalent data through any of the endpoints; corresponds to within the response, while replicates the data previously available in .

In the endpoint, we have updated example responses and introduced a new object within the . This addition consolidates all material-based carbon intensities into a single category, as a material may appear in multiple parts of the building (e.g., is used in both the structural bill of materials and glazing assemblies).

The object is now planned for deprecation in a future release, as the object provides a more comprehensive representation. Additionally, the object now includes carbon intensities for and , materials used in glazing assemblies.

In this update, we’ve introduced a new endpoint, updated glazing carbon intensities, and refactored the unit conversion approach to reduce rounding artifacts.

We added a new endpoint that provides the latest version and deployment time. This endpoint is not counted against a token.

The carbon intensities for framing materials in glazing assemblies have been updated. In a peer review process with an API user, they identified that we were undercounting steel used in these assemblies as we were excluding the brackets, connectors, and misc. hardware required to attach the glazing back to the building. This change is highest for steel-framed glazing units, and may be higher than 10% in some geographies.

We re-factored the unit conversion process to mitigate rounding errors associated with . Previously, the need to perform unit conversions with the data model would lead to annoying rounding errors, where an request value of 100.0 might appear in the response object as 100.00000000001. We re-factored the unit conversion process so that input units are explicitly declared within the calculation, providing both "unit safety" and preventing some of these bummer rounding artifacts.