Basic Concepts

Core Ideas

Renewables.Architect (RA) is a flexible systems engineering framework for building and running connected engineering calculations.

You build applications (workflows) from reusable components, not hard-coded workflows.
Data flow between models is explicit and configurable.
The same network of models can run as a simple sequence, in optimisation loops, or as large multi-run studies.
Scaling and execution strategy (local, parallel, cloud, HPC) are separate from modelling logic, so calculations are written by engineers without concern for software implementation and orchestration complexities.
Applications are described in a serializable JSON Application Definition File, not custom Python glue code.
Any application definition can run on desktop or cloud without changing the definition itself.

Component Types

RA uses a small set of core building blocks:

Model: A single calculation (or complex calculation package) or service wrapper for one discipline/process.
Assembly: A connected set of models and their data flow / relationships, stored in RA as a network diagram.
Validator: Typed input/output interface checks used for connectivity and value validation. Validators are built on the interfaces of Models, Environments and Drivers to support and validate data flow.
Environment: Runtime algorithm used to execute the assembly (for example, sequential execution in the most basic sense, more in-depth optimization in other cases).
Driver: Multi-run logic (batching, sweeps, some types of optimization, sensitivity and stochastic sampling e.g. Monte Carlo, etc.).
Runner: Runs applications on provided hardware and handles interprocess communication across parallel processes (local, cloud, HPC). Runners are not application components, they are typically created by the RA development team or advanced in-house developers to allow users to run and scale calculations.

Models, Environments, and Drivers are all component types in this system, and components can produce results and figures whenever they run.

Components are distributed as packages. Each user has access to a certain combination of packages and these are loaded by RA when specified in an application definition, making the components they contain available for use.

Application Definition File Format

An RA application is described in JSON. A minimal top-level structure is:

{
  "application_name": "Name",
  "packages": [],
  "environment": {},
  "assembly": {}
}

Common/extended fields seen in real applications include:

driver (optional): multi-run setup and run results processing.
shared_inputs: reusable values for common inputs to multiple models.

You can find sample application definitions in the Applications Library (Log In first).

How Assembly Connections Work

Inside assembly, each model defines a model_type and inputs. Whether an input is user-provided or connected from another model, it is validated against that model’s data model (validators). Input values can be:

Literal values, e.g. "length": 60
Connections to another model output using ->, e.g. "root_radius": "Blade1->radius"
Shared input references using $, e.g. "rating": "$rating"

Example:

{
  "shared_inputs": {
    "rating": 4000000
  },
  "assembly": {
    "Blade1": {
      "model_type": "Blade",
      "inputs": {
        "length": 60,
        "turbine_rating": "$rating"
      }
    },
    "Hub": {
      "model_type": "ThreeBladeHub",
      "inputs": {
        "root_radius": "Blade1->radius",
        "rating": "$rating"
      }
    }
  }
}

Practical Mental Model

Think of RA as:

Models + Connections define engineering logic,
Environment defines how a single run executes,
Driver defines how many runs are generated,
Runner defines where/how those runs scale,
Application Definition File defines the whole setup as configuration.