CE-RISE SEE Impacts Calculation Service

A containerized HTTP service for calculating environmental footprints from CE-RISE Product System and LCI Dataset records using Brightway, the BONSAI background, and Environmental Footprint (EF) 3.1 characterization factors.

Each successful request calculates the inventory once and returns all 25 configured environmental indicators in one validated CE-RISE Integrated LCA object. The result includes units, methods, the functional unit, input references, and data and software provenance.

SEE stands for socio-economic and environmental. This service provides environmental impact calculations.

Related data models and software are described on the CE-RISE Solution website.

Using the Service

Submit a Product System, its LCI Dataset records, a functional unit, and their schema versions to POST /compute. The service validates the records through HEX Core, assembles the foreground, links it to the BONSAI background, and calculates the indicators. HEX Core validates the Integrated LCA result before it is returned.

• Compute Workflow: input records, inventory links, and result structure.
• PV Example: a complete request and calculated results for a photovoltaic panel.
• Methods and Background: the configured EF3.1 categories, result units, and factor coverage.
• API Reference: endpoints, request fields, responses, and diagnostics.

Deployment and Integration

Deployment covers installation, container builds, runtime settings, and service checks. HEX Core Integration describes schema validation and authentication.

Engineering

Architecture documents foreground assembly, project isolation, and numerical execution. Testing covers the regression suite and Codeberg CI checks.

Funded by the European Union under Grant Agreement No. 101092281 — CE-RISE.
Views and opinions expressed are those of the author(s) only and do not necessarily reflect those of the European Union or the granting authority (HADEA). Neither the European Union nor the granting authority can be held responsible for them.

© 2026 CE-RISE consortium.
Service source licensed under the European Union Public Licence v1.2 (EUPL-1.2).

Attribution: CE-RISE project (Grant Agreement No. 101092281) and the individual authors/partners as indicated.

Developed by NILU (Riccardo Boero - ribo@nilu.no), Leiden University (Mintjes, B.A. (Berend) - b.a.mintjes@cml.leidenuniv.nl; Stefano Merciai - s.merciai@cml.leidenuniv.nl), and Empa (Francesco Barilli - francesco.barilli@empa.ch; Roland Hischier - roland.hischier@empa.ch) within the CE-RISE project.

Compute Workflow

The service calculates all configured environmental impact indicators in one request. A CE-RISE Product System selects the foreground activities, and LCI Dataset records supply their inventory flows. The bundled BONSAI-EF3.1 project provides background activities, elementary flows, and characterization factors. The service validates the input records, calculates the inventory once, and returns all indicators in a validated CE-RISE Integrated LCA object.

Required Inputs

POST /compute accepts a JSON object with these four fields:

Record Relationships

The Product System’s dataset references must match exactly one supplied LCI Dataset each; referenced record versions must also match. Selected activities must exist in those datasets. The Product System reference flow must be a product flow produced by a selected activity, and its identifier, declared amount, and unit must match the LCI flow. The functional unit repeats that flow identifier and unit, while its quantity is the amount to assess.

Foreground and Background Links

The foreground is the inventory supplied in the LCI Dataset records. The background provides the external activities and elementary flows referenced by that inventory.

Internal foreground links are resolved from the selected activities and their flows. External product inputs can identify a background activity with counterpart_activity_reference or output_of_activity_reference; external waste treatment uses counterpart_activity_reference. These must resolve to activity codes in the configured background database. Elementary flows use flow_object_reference values that resolve in the configured biosphere database. The service converts compatible flow units and rejects unresolved or incompatible links. The bundled BONSAI background is prepared by the image build or local setup. Activity and elementary-flow identifiers in the input records provide the links to it.

In the bundled project, external activities resolve in BONSAI and elementary flows resolve in ef31_biosphere. See Methods and Background for database contents, characterization factors, and geographic treatment.

Send a Request

1. Start the service with HEX_CORE_BASE_URL pointing to a reachable HEX Core that has the requested Product System, LCI Dataset, and Integrated LCA schemas. See Deployment.
2. Check GET /capabilities for the background and GET /methods for the configured indicators.
3. Send the model versions, Product System, LCI Dataset records, and functional unit to POST /compute.

The PV Example provides the input records, request commands, and complete calculated result for a photovoltaic panel.

Read the Response

A successful response has one lca_analysis_instances entry containing all 25 assessment_results.assessment_indicators entries.

The API Reference shows the full result shape. If the technosphere is singular, POST /compute instead returns status: "not_calculable" with a SINGULAR_TECHNOSPHERE diagnostic and identified activity groups. This response has no calculated indicators. Invalid models or links return 422; unavailable HEX Core validation returns 503.

Diagnostic Requests

POST /compute/diagnostics accepts the same inputs and performs the calculation, but returns only whether it is calculable or a singularity diagnostic. Use POST /compute to obtain the indicators; a separate diagnostic request is not required before computing results.

PV Example

This example calculates the environmental impacts of a photovoltaic panel product system for 1 m^2 of its declared reference flow. It uses the service’s bundled BONSAI background and all 25 configured EF3.1 methods.

Example Records

The records are included in the repository:

The example supplies the foreground through the same CE-RISE input records as any other assessment. Background data, characterization factors, and project preparation are provided by the service.

Send the Request

Start the calculator using Deployment. These commands use its local address, http://127.0.0.1:8081, and require jq. The schema versions in the request must be registered in HEX Core. Run the commands from the repository root:

jq -n \
  --slurpfile system tests/fixtures/pv/product-system.json \
  --slurpfile inventory tests/fixtures/pv/lci-dataset.json \
  '$system[0].reference_flow_specification as $reference |
  {
    model_versions: {
      product_system: "0.0.1",
      lci_dataset: "0.0.1",
      integrated_lca: "0.2.0"
    },
    product_system: $system[0],
    lci_datasets: [$inventory[0]],
    functional_unit: {
      reference_flow_identifier: $reference.reference_flow_identifier,
      quantity: 1.0,
      unit: $reference.reference_flow_unit_reference
    }
  }' > compute-request.json

curl --fail-with-body --silent --show-error \
  -H 'Content-Type: application/json' \
  --data-binary @compute-request.json \
  --output compute-result.json \
  http://127.0.0.1:8081/compute

The response in compute-result.json is the complete Integrated LCA object. It contains one analysis instance and 25 indicators calculated from one inventory.

Inspect the Results

Count the returned indicators:

jq '.lca_analysis_instances[0].assessment_results.assessment_indicators | length' \
  compute-result.json

The result is 25. To list each indicator with its value and unit:

jq -r '.lca_analysis_instances[0].assessment_results.assessment_indicators[] |
  [.indicator_identifier, .indicator_result.numeric_value, .indicator_result.unit] | @tsv' \
  compute-result.json

The saved result includes the following values, rounded here for readability. All values refer to the same 1 m^2 functional unit:

The complete result record contains every indicator, its method and factor-set reference, the functional unit, input references, background identification, software versions, and calculation timestamp.

See Methods and Background for interpretation of categories and subcategories and Testing for numerical regression and schema-validation checks.

Methods and Background

The service calculates environmental impacts from a CE-RISE Product System, its referenced LCI Dataset records, and a functional unit. HEX Core validates the inputs and result against the data-model versions specified in the request.

The bundled BONSAI-EF3.1 background provides 25 methods with fixed characterization factors and elementary-flow links. Every request uses this shared configuration to calculate all indicators from one inventory.

Calculations are independent of product category. The supplied inventory defines the foreground, and its external activity and elementary-flow identifiers link it to the background.

Background Inventory

The bundled Brightway project contains:

The background manifest identifies the source archive, database counts, method metadata, and checksums. The background data are licensed CC BY-SA 4.0; the service source code is licensed separately under EUPL-1.2.

Characterization and Results

The BONSAI-EF3.1 project has 25 registered method entries that include impact categories and subcategories. Each request solves the inventory once, applies each method to that same inventory, and returns all 25 characterized indicators in one Integrated LCA object. Each indicator has its own unit, method version, and factor-set reference. Characterization factors are part of the deployed background configuration; changing them requires deploying an updated project.

All methods belong to the EF3.1 family. The table lists their registered categories and result units; GET /methods returns the complete identifiers used in the output:

The results are characterized values in each indicator’s unit, not a single weighted score. Categories and their subcategories are reported separately and overlap; interpret them individually rather than summing them.

Flow Coverage and Geography

External background activity references resolve in BONSAI; elementary-flow identifiers resolve in ef31_biosphere. Compatible units are converted. An unknown identifier is an error. A resolved elementary flow with no factor in a particular method contributes zero to that indicator, while remaining part of the calculated inventory.

The calculation uses each method’s global (GLO) factors, as defined by the Brightway LCIA implementation. Regional factor records remain in the project but are excluded from the calculation. Geographic background differences enter through the selected BONSAI activities. Foreground location metadata does not select country-specific characterization factors.

Reproducing and Comparing Results

To reproduce a result, retain the input records, functional unit, background snapshot, and configured methods and factor sets. Comparisons between alternatives require compatible functional units and study boundaries and the same background and method setup. Replacing the background or factors can change scores even with an unchanged foreground. The Integrated LCA output records the available background version and source-archive identifier, plus each indicator’s method version and factor-set reference for this purpose.

API Reference

Base URL

http://127.0.0.1:8081/

The deployment examples use port 8081 for the calculator and port 8080 for HEX Core. Interactive OpenAPI documentation is available at GET /docs; the OpenAPI document is available at GET /openapi.json.

GET /health

Returns service identity and the configured HEX Core and background-project locations. It does not open the Brightway project, so it can be used as a lightweight liveness check.

Example response:

{
  "status": "ok",
  "service": "see-impacts-calculation-service",
  "version": "0.0.1",
  "hex_core_base_url": "http://127.0.0.1:8080",
  "background_project_dir": "/app/data/background/projects/cerise_bonsai.c4e8a461df1485d0b80d98d3e46a35b9"
}

GET /capabilities

Opens the configured Brightway background project and reports the databases and impact methods that are available to the service. Use this endpoint as a readiness check after provisioning or updating background data.

The response contains calculation_status: "request_dependent", a background object with the project name, databases, method count, and sample method identifiers, and a brightway object with the bw2data and bw2calc versions. Database names and counts depend on the configured project. Input validation and calculation checks are performed by the compute endpoints.

GET /methods

Returns the full sorted set of impact-method identifiers registered in the configured Brightway project. Every compute request applies all of these methods to the same calculated inventory.

The response contains project_name, method_count, and methods. Each entry in methods is an array of strings. For example, the climate-change indicator uses the registered identifier ["EF 3.1", "Climate change", "Radiative forcing as Global Warming Potential (GWP100)"]. The bundled project supplies 25 fixed EF3.1 method entries. An unavailable project returns 503 BRIGHTWAY_PROJECT_UNAVAILABLE with an explanation in detail.message.

POST /compute

This endpoint validates input models through HEX Core, assembles a foreground, solves the inventory once, and applies every configured impact method. It validates and returns one Integrated LCA object containing all 25 environmental indicators for the bundled EF3.1 project.

Required Request Fields

Additional top-level request fields are rejected. The configured impact methods and factors are supplied by the service.

The Compute Workflow explains the required links between the CE-RISE records. The PV Example provides a complete request and its results.

Response

A successful request returns an Integrated LCA object after HEX Core validates it against the requested model_versions.integrated_lca schema. The complete PV result, including all 25 indicators, is in tests/fixtures/pv/integrated-lca.json.

The response contains one lca_analysis_instances entry with these sections:

Each indicator contains:

The method version comes from registered metadata or an explicit version in the method name. For the bundled EF3.1 family, a value such as 01.00.000 identifies the individual method dataset’s version. It is separate from the EF3.1 family name and from the CE-RISE schema versions in model_versions. The factor-set reference identifies the factor dataset within the Brightway project. The background artifact URI identifies the source archive by its SHA-256 checksum. Fields without a recorded value are omitted. Results are returned to the caller; foreground data are temporary and the source background remains unchanged.

Validation Errors

FastAPI returns 422 Unprocessable Entity when a required field is absent or has an incompatible JSON type. HEX Core model failures return 422 MODEL_VALIDATION_FAILED, with detail.field identifying the input and detail.results containing the validation findings. Inconsistent reference-flow links return 422 CALCULATION_INPUT_INVALID, with detail.field naming the affected field. Missing input or output schemas, or an unavailable HEX Core, return 503. A generated result that fails HEX Core validation returns 500 OUTPUT_MODEL_VALIDATION_FAILED and is not returned. Worker startup failures and timeouts return 503 CALCULATION_WORKER_UNAVAILABLE. When the configured per-process calculation capacity is full, the service returns 503 CALCULATION_CAPACITY_EXCEEDED. A singular calculation returns 200 with the same not_calculable diagnostic shape documented below, without a score.

POST /compute/diagnostics

Accepts the same four-field request as POST /compute. The service validates the CE-RISE inputs through HEX Core, assembles the selected foreground, links external inputs to the configured background and biosphere databases, and attempts the calculation in a disposable per-request project. The prepared background is not modified. This endpoint does not return an impact score or an Integrated LCA result.

For the request in the PV Example, a diagnostic call returns:

{
  "status": "calculable",
  "request": {
    "product_system_identifier": "pv-panel",
    "functional_unit": {
      "reference_flow_identifier": "PVPanelManufacturingCNAct_flow0_PhotovoltaicPanelSingleSi",
      "quantity": 1.0,
      "unit": "m^2"
    }
  },
  "diagnostic": null
}

When Brightway reports a singular technosphere, the response is 200 with status: "not_calculable", the same request summary, and a diagnostic object. Its code is SINGULAR_TECHNOSPHERE; message explains that no unique solution or score is available. components contains any small groups of involved activities the service can identify. Each activity has a database, code, and name, and each group has reachable_from_request. The scope field describes the diagnostic coverage. components can be empty when the diagnostic cannot isolate small activity groups. reachable_from_request reports graph connectivity to the demand, rather than the cause of the singularity.

A foreground or background linkage failure returns 422 CALCULATION_PRECONDITION_FAILED; invalid foreground construction returns 422 FOREGROUND_CONSTRUCTION_FAILED. Input-model and HEX Core errors follow the same rules as POST /compute.

Error Responses

Errors use the standard FastAPI detail envelope:

• BRIGHTWAY_PROJECT_UNAVAILABLE (503): the configured background project cannot be opened;
• MODEL_VALIDATION_FAILED (422): an input does not conform to its declared model version;
• MODEL_SCHEMA_UNAVAILABLE (503): HEX Core has no JSON Schema for a requested input or output model version;
• MODEL_VALIDATION_UNAVAILABLE (503): HEX Core cannot complete validation;
• MODEL_VALIDATION_RESPONSE_INVALID (502): HEX Core returned an incomplete validation report;
• CALCULATION_INPUT_INVALID (422): the functional unit or reference-flow links are inconsistent;
• OUTPUT_MODEL_VALIDATION_FAILED (500): the generated Integrated LCA object did not pass HEX Core validation and was not returned;
• FOREGROUND_CONSTRUCTION_FAILED (422): the validated input objects cannot be assembled into a foreground calculation;
• CALCULATION_PRECONDITION_FAILED (422): the calculation cannot start or finish for a reason other than a reported singular technosphere;
• CALCULATION_WORKER_UNAVAILABLE (503): the isolated worker could not start or finish;
• CALCULATION_CAPACITY_EXCEEDED (503): all configured calculation slots are occupied; retry after an active calculation finishes.

Deployment

Requirements

The service runs from source with Python 3.11 or 3.12, or in a container built from the repository’s Dockerfile. Calculations require a reachable HEX Core service with the requested Product System, LCI Dataset, and Integrated LCA schema versions.

The examples use HEX Core on http://127.0.0.1:8080 and the calculator on http://127.0.0.1:8081. Set HEX_CORE_BASE_URL to the address of HEX Core in your deployment.

Run from Source

From the repository root, install the service and prepare its background:

python3 -m venv .venv
.venv/bin/python -m pip install --upgrade pip
.venv/bin/python -m pip install .
.venv/bin/python -m see_impacts_calculation_service.prepare_background \
  data/background/cerise_bonsai.tar.gz data/background/projects \
  --project-name cerise_bonsai
.venv/bin/see-impacts-compatibility

The preparation command verifies the archive and extracts the BONSAI-EF3.1 project. The compatibility command checks that Brightway can read its databases and impact factors.

Start the calculator:

HEX_CORE_BASE_URL=http://127.0.0.1:8080 \
  .venv/bin/python -m uvicorn see_impacts_calculation_service.app:app \
    --host 127.0.0.1 --port 8081

Build the Container

podman build -t see-impacts-calculation-service:local .

The image includes the BONSAI-EF3.1 project and runs as an unprivileged application user. During the build, it extracts the background and checks that Brightway can read its databases and methods. A verification failure stops the build. The default container command listens on 0.0.0.0:8080.

Run the Container

On Linux, this example uses host networking to reach HEX Core on the host and runs the calculator on port 8081:

podman run --rm --network host \
  -e HEX_CORE_BASE_URL=http://127.0.0.1:8080 \
  see-impacts-calculation-service:local \
  python -m uvicorn see_impacts_calculation_service.app:app --host 127.0.0.1 --port 8081

For container-network deployments, configure HEX_CORE_BASE_URL with an address reachable from the calculator container. With separate network namespaces, 127.0.0.1 refers to the calculator container itself.

Runtime Configuration

The service accepts the following environment variables:

• HEX_CORE_BASE_URL: HEX Core base URL; default http://127.0.0.1:8080;
• HEX_CORE_BEARER_TOKEN: optional service-to-service token for HEX Core validation requests;
• HTTP_TIMEOUT_SECS: timeout for HEX Core requests in seconds; default 30;
• BACKGROUND_PROJECT_DIR: Brightway project directory; default data/background/projects/cerise_bonsai.c4e8a461df1485d0b80d98d3e46a35b9;
• BACKGROUND_PROJECT_NAME: expected project name from .project-name.json; default cerise_bonsai;
• BACKGROUND_DATABASE_NAME: Brightway database used for external technosphere links; default BONSAI;
• BIOSPHERE_DATABASE_NAME: Brightway database used for elementary flows; default ef31_biosphere;
• BRIGHTWAY_WORKSPACE_DIR: writable Brightway registry workspace; default runtime/brightway locally and /var/lib/see-impacts/brightway in the container image.
• CALCULATION_TIMEOUT_SECS: maximum time for one isolated calculation; default 900.
• MAX_CONCURRENT_CALCULATIONS: maximum active Brightway calculations per server process; default 2. Additional compute requests return 503 while all slots are occupied.

POST /compute and POST /compute/diagnostics call HEX Core to retrieve each requested input model’s JSON Schema and validate the Product System and LCI Dataset objects. POST /compute also validates the generated Integrated LCA object through HEX Core. Provision a reachable HEX Core registry and an appropriate service identity before using that endpoint. The bearer token is never returned by GET /health.

Set the HTTP listening address and port with Uvicorn’s --host and --port options.

Background Data

The image contains the general BONSAI-EF3.1 Brightway project and treats it as immutable. Each compute request creates a temporary project copy under BRIGHTWAY_WORKSPACE_DIR/requests, calculates in a separate process, and removes the copy after completion or timeout. The workspace must be writable and must not be inside the background source directory. The fixed base has 49,978 BONSAI activities, the EF3.1 elementary-flow database, and 25 registered EF3.1 method entries. Each request supplies its own CE-RISE foreground; the background is independent of product type. The source archive and matrix checksums are recorded in the background manifest.

The BONSAI background is licensed CC BY-SA 4.0. The computing module’s source code has a separate EUPL-1.2 license. Retain the BONSAI attribution when redistributing the image.

Concurrent compute requests have separate Brightway processes and request workspaces. Workers default to one BLAS thread to avoid multiplying numerical-library threads across concurrent calculations; explicit numerical-library thread settings in the environment are retained.

Service Checks

After startup, check the HTTP process, background availability, and registered methods:

curl -sS http://127.0.0.1:8081/health
curl -sS http://127.0.0.1:8081/capabilities
curl -sS http://127.0.0.1:8081/methods

Use GET /health for a lightweight liveness check. Use GET /capabilities as the readiness check to confirm that Brightway can open the configured background project. The PV Example provides a complete calculation request and its results.

HEX Core Integration

Input and Output Models

The service uses these CE-RISE data models:

model_versions specifies the schema versions registered in HEX Core. These are distinct from the versions assigned to individual input records.

Validation Requests

Both compute endpoints check the Product System and each LCI Dataset against the versions named in model_versions. After a successful calculation, POST /compute also validates its generated Integrated LCA object against model_versions.integrated_lca. For each record, the service first requests the JSON Schema artifact from HEX Core and then calls:

GET /models/{model-family}/versions/{version}/schema
POST /models/{model-family}/versions/{version}:validate

The validation request body is a JSON object whose payload field contains the record.

The validation report must include a JSON Schema result for the requested model version. Failed input validation returns 422 with HEX Core’s findings. Failed output validation returns 500, and the generated result is not returned. An unavailable schema or HEX Core returns 503; a malformed report returns 502. After input validation, the service checks reference-flow links and assembles the inventory.

Connection and Authentication

Set HEX_CORE_BASE_URL to the running HEX Core service. If it requires bearer-token authentication, provide HEX_CORE_BEARER_TOKEN through deployment secrets. The token is sent only to HEX Core and is not included in the health response.

See Deployment for connection settings and the API Reference for validation error codes.

Architecture

The service separates HTTP handling and model validation from numerical execution. Each calculation runs in its own worker process and temporary Brightway project. The bundled background and characterization factors are shared configuration, while the foreground comes from the request’s CE-RISE records.

Request Execution

1. The HTTP application validates the Product System and LCI Dataset records through HEX Core.
2. Foreground assembly resolves the selected activities, product outputs, internal inputs, elementary exchanges, and reference flow.
3. An isolated worker copies the prepared background and adds the foreground as an in-memory Brightway datapackage.
4. Brightway solves the inventory once and characterizes it with all configured methods.
5. The application builds one Integrated LCA object, validates it through HEX Core, and returns it to the caller.

All indicators must complete successfully. A method failure returns an error rather than a partial result. Singular calculations return the structured diagnostic described in the API Reference.

Project Isolation

The bundled project is cerise_bonsai, located by default at data/background/projects/cerise_bonsai.c4e8a461df1485d0b80d98d3e46a35b9. The compressed project archive and its provenance manifest are included in the repository. Source deployments extract the archive during setup; container builds extract it into the image.

Brightway project state is mutable and process-global. Each compute request therefore runs in a separate process with a project copy under BRIGHTWAY_WORKSPACE_DIR/requests. The copy is removed when the request completes, fails, or times out. The source background remains unchanged, and the writable workspace must be outside its directory.

MAX_CONCURRENT_CALCULATIONS limits active workers per server process. CALCULATION_TIMEOUT_SECS limits each worker’s execution time. Runtime settings and their defaults are listed under Deployment.

Foreground Construction

Foreground assembly resolves selected activities, product outputs, internal inputs, and the reference output using model identifiers. External background demands and elementary flows retain their identifiers for resolution against the configured databases. Units determine quantity conversion. Brightway projects and temporary foreground data are managed internally.

For calculation, the foreground runner adds a transient Brightway datapackage to the read-only background and method datapackages. External activity and biosphere flow references must resolve to exact identifiers in their configured databases; compatible units are converted. The runner rejects missing links and incompatible units and diagnoses singular calculations.

Numerical Calculation

Numerical execution uses SciPy’s sparse direct solver with minimum-degree column ordering (MMD_AT_PLUS_A) to reduce factorization fill-in in the shared input-output matrix. The ordering controls matrix factorization without changing the inventory equations or factors.

After solving the inventory, Brightway switches the characterization method and calculates each indicator over that same inventory. The service collects the scores, units, method versions, and factor-set references in one result. Foreground construction and the technosphere solve are not repeated for different indicators.

Modules

Testing

The test suite covers input and output validation, foreground construction, numerical calculations, diagnostics, and request isolation. Service setup is documented under Deployment.

Setup

Use Python 3.11 or 3.12 to create a virtual environment and install the service with its test dependencies:

python3 -m venv .venv
.venv/bin/python -m pip install --upgrade pip
.venv/bin/python -m pip install -r requirements-test.txt

Tests

.venv/bin/python -m pytest

The PV integration test extracts a fresh copy of the bundled background and submits the example records to POST /compute. It compares all 25 calculated indicators with the saved result in tests/fixtures/pv/integrated-lca.json. Other numerical tests use a small synthetic background to check known results, unit conversion, singularity diagnostics, concurrent requests, and one inventory solve per request.

Schema validation uses the latest published Product System, LCI Dataset, and Integrated LCA schemas from Codeberg. These checks require network access to Codeberg and run without a live HEX Core service.

Continuous Integration

Codeberg runs the core tests on codeberg-medium and PV record validation on codeberg-small for pushes, pull requests, and releases. The PV CI job validates the example inputs and the complete saved output against the published schemas. It does not run the full numerical PV calculation.

Run the same record-validation check locally:

.venv/bin/python -m pytest -q tests/test_pv_integration.py::test_pv_records_against_published_models

Background Verification

The compatibility command checks that Brightway can read the background and its registered impact methods. Prepare the bundled project before running the check:

.venv/bin/python -m see_impacts_calculation_service.prepare_background \
  data/background/cerise_bonsai.tar.gz data/background/projects \
  --project-name cerise_bonsai
.venv/bin/see-impacts-compatibility

The default background project location is data/background/projects/cerise_bonsai.c4e8a461df1485d0b80d98d3e46a35b9. BACKGROUND_PROJECT_DIR selects a different project location. The separate BRIGHTWAY_WORKSPACE_DIR holds Brightway’s writable project registry and defaults to runtime/brightway.

The command reports database and method metadata as JSON. It reads a record and its exchanges from each database, opens the processed datapackages, and loads factors from a registered method. This verifies data access; numerical calculations are covered by the integration tests.

Container Smoke Test

Build the image locally:

podman build -t see-impacts-calculation-service:local .

Run it with the included BONSAI background project:

podman run --rm -p 8081:8080 \
  see-impacts-calculation-service:local

In a second terminal, check the background:

curl --fail-with-body -sS http://127.0.0.1:8081/capabilities

This check reads the bundled background and reports its databases and methods. It does not require HEX Core. The Compute Workflow covers calculation requests with input and output validation; the PV Example provides a complete request.