pvperfsolar performance modeling

Reference

Guide

East-west racking

East-west ridges: how the two faces run, the inputs, ridges in a scene, the example request and the result

What it is

East-west racking (array.track_mode ewf) mounts the modules on ridges: two faces back to back at the same tilt, one looking east of the ridge bearing and one looking west, each with half the modules. This page covers how the run treats the two faces, the inputs, east-west ridges in a scene, the example request and what the result shows. The field pages (array.track_mode, scene.types, scene.types.gap) hold each key's detail.

How the run treats the two faces

Each face runs its own irradiance chain: transposition, horizon, near shading, soiling and the angle-of-incidence losses. In the row models (geometric, unlimited_sheds) each face is a fixed tilted row whose next row of the same facing stands one ridge spacing away, so the face takes GCR / (2 × cos(tilt)) as its own GCR: 0.83 / (2 × cos 10°) = 0.421 in the example. The pvperf path keeps the row model on east-west racking with a scene; the scene's objects add their shade. Each face then runs the cell temperature and the DC chain on half the strings of each inverter. The two faces share the inverter's DC input, and the array's DC power is the sum of the two faces' powers. The inverter step runs the operating point chosen in the Inverter operating limits row. Two faces have no single current-voltage curve, so the operating point on the array's I–V curve runs as power limits (page step.inverter_limits.power_limits). Under the power limits and the AC clip, the voltage is the higher of the two faces' voltages and the current is the power over that voltage. Under the MPPT window on the module curve, each face runs at its own maximum-power point and the inverter's input voltage is the mean of the two faces' string voltages, held inside the MPPT window (page step.inverter_limits.mppt_window). The night consumption, the AC losses, the grid power limitation and the unavailability periods apply as on fixed racking. The reported irradiance series and the irradiance rows of the loss diagram are the per-square-metre means of the two faces. A bifacial rear side is not available on east-west racking.

Inputs

Key Meaning on east-west racking Example
array.track_mode ewf ewf
array.tilt_deg The tilt of each face 10
array.azimuth_deg The ridge bearing; the faces look toward azimuth − 90 and azimuth + 90 180 (faces east and west)
array.collector_width_m One face's slant width, from its lower edge to its top edge 2.278
array.gcr The two faces' horizontal footprint over the ridge spacing: 2 × width × cos(tilt) / spacing 2 × 2.278 × cos 10° / 5.4 = 0.83
array.inter_row_shading Whether the ridges shade each other's faces true
array.strings_per_inverter Strings per inverter; each face takes half, rounded down, so give an even number 56

The module and inverter sections are those of any run.

East-west ridges in a scene

A scene places each ridge as one placement of an ewf type.

A scene of ewf types needs array.track_mode ewf and holds no gft or sat types. The run blends the east-facing faces and the west-facing faces separately by module count, and array.azimuth_deg tells the two sides apart. The pitch check compares the ridge spacing from the placements with 2 × width × cos(tilt) / GCR.

The example request

GET /api/scene-examples/east_west returns the example scene; GET /api/scene-examples gives its array_patch and notes. It holds 42 ridges of 40 modules, 1,680 modules in all. Each face is 22.7 long and 2.278 wide at 10°, and the faces' top edges are 0.3 apart at a height of 0.9. The ridges run north–south, 5.4 apart, in lines 23.5 apart from north to south; two short lines make one ragged edge. A two-storey building (20 × 12 on plan, 7 high) stands to the south-east and a tree (6 across, 12 high) to the west. The array_patch sets ewf racking at tilt 10 and azimuth 180, collector width 2.278, GCR 0.83 and 30 modules per string × 56 strings on one inverter: 1.008 MWp with the default 600 W module.

To build the request, take GET /api/defaults without its _meta key, put the example in scene, merge the array_patch into array, set bifacial to null and choose an inverter of about 1 MW AC from GET /api/library/inverters. The demo east_west does this with the Delta EPCS-1200 (1,217 kW AC); its stored result is GET /api/demos/east_west. The request's start, with the placements cut to one:

{
  "array": {"track_mode": "ewf", "tilt_deg": 10, "azimuth_deg": 180,
            "collector_width_m": 2.278, "gcr": 0.83, "inter_row_shading": true,
            "modules_per_string": 30, "strings_per_inverter": 56, "n_inverters": 1},
  "module": {"id": "trina-solar-tsm-600de20"},
  "inverter": {"id": "delta-electronics-epcs-1200us-480v"},
  "bifacial": null,
  "scene": {"version": 2,
            "types": [{"id": "ew", "kind": "ewf", "length": 22.7, "width": 2.278,
                       "gap": 0.3, "modules": 40, "strings": 2}],
            "placements": [{"id": "r1", "type": "ew", "x": 0, "y": 0, "z": 0.9,
                            "azimuth_deg": 180, "tilt_deg": 10}],
            "objects": []}
}

POST /api/run lists the full request as its east_west example in the OpenAPI document (/openapi.json); /v1/run takes the same request.

What the result shows