Every ASTM E2848 capacity test is a comparison, and a comparison needs something to compare against. ASTM E2939 is the standard that produces it: the reporting conditions the test will be evaluated at, and the modeled baseline the measured result is judged against.

It is the less discussed of the two standards, and the more consequential. By the time a field test runs, E2939 has already fixed the number the plant has to beat. Get the baseline wrong and a healthy plant fails, or an underperforming one passes — and in either case the argument that follows happens after the crew has demobilized.

This article covers what E2939 produces, how to build it from a PVsyst model, and the decisions inside it that most affect the outcome.

What E2939 Produces

Two things, both of which belong in the contract before anyone goes to site:

  1. Reporting conditions (RC) — a single set of environmental values (POA irradiance, ambient temperature, wind speed) representing the conditions the plant will be judged at.
  2. A modeled capacity at those conditions — the output the energy model predicts when evaluated at the RC.

E2848 then produces a measured capacity at the same reporting conditions, and the ratio of the two is the Capacity Test Ratio. For how that second half works, see ASTM E2848 capacity testing.

Why Not Just Use Standard Test Conditions?

STC — 1000 W/m², 25 °C cell temperature — is a laboratory reference. Most plants rarely operate there, and some never do. Testing a site in Seattle in November against 1000 W/m² means extrapolating the regression well outside the range of data that fitted it, which is exactly the condition under which a regression stops being trustworthy.

Site-specific reporting conditions solve this by placing the evaluation point inside the cloud of data the test will actually collect. This is the core idea of E2939: judge the plant at conditions it genuinely experiences, and keep the evaluation point away from irradiance levels where the plant is shaded, clipping, or otherwise not behaving linearly.

Building the Baseline

1. Start From a Representative Weather Record

E2939 works from a weather record that represents the conditions expected during the test — a TMY file in most cases, or measured site data where a long enough record exists. The formal minimum is small, a handful of contiguous days, but in practice you want a full year on hand so the seasonal window can be chosen later.

Historical records such as a TMY have one significant advantage: they exist before the plant does, so the reporting conditions and the expected capacity can be fixed in the contract rather than negotiated afterwards. This is what the standard generally recommends. Their main weakness is that they are rarely measured in the plane of array, so the data has to be transposed, and transposition error against a real pyranometer is a recurring source of disagreement later. Measured on-site data avoids that step and captures the site's actual irradiance and temperature climate, at the cost of only being available once the plant is instrumented.

2. Filter to Testable Conditions

Not every hour in the record is a candidate. The reporting conditions should be drawn from the conditions a capacity test can actually be run in, which means excluding:

  • Low irradiance, where signal-to-noise is poor — a threshold of a few hundred W/m² also removes night and dawn/dusk hours as a side effect
  • Hours with shading, whether row-to-row, terrain, or horizon — in a PVsyst export this is a threshold on the shading beam loss channel
  • Hours where the plant would be clipping, since output there is insensitive to irradiance
  • Unstable sky conditions, where the model's hourly resolution has no real equivalent on the measured side and the two datasets can only be matched approximately
  • Simulated downtime, if the model was run with unavailability — clear-sky hours at zero power will otherwise drag the modeled regression down

What remains is the population the reporting conditions are computed from. The filtered set has to clear the same volume bar the field test does — 750 minutes spanning at least three days, which is fifty points at a 15-minute interval. On hourly model data that works out to only thirteen points, thin for fitting four coefficients, so fifty modeled points is the more defensible working minimum.

3. Compute the Reporting Conditions

This part is mechanical, and it is worth stating precisely because it is frequently described wrongly:

  • Reporting POA irradiance is the 60th percentile of the filtered irradiance — the value that 60 % of the filtered data falls below. It is not a mean.
  • Reporting ambient temperature is the arithmetic mean of the filtered data.
  • Reporting wind speed is the arithmetic mean of the filtered data.

The percentile is what pulls the evaluation point up toward the high-irradiance end of the distribution without pushing it out to the extreme tail where few points support it.

4. Decide the Season

This is the decision that moves the number most, and the one most often left implicit.

Reporting conditions computed over a full year describe an annual average. If the test is run in June, the plant will be tested at ambient temperatures well above that annual average, and it will be judged against a baseline that assumed cooler conditions. The regression normalizes for this, but only within the range the data supports. The standard is unambiguous that the modeled period and the test period have to correspond.

There are two clean ways to handle this, and one messy one.

The first is to compute reporting conditions over a window matching the expected test period — May and June data for a June test. This requires the test date to be roughly known when the contract is written.

The second, for when it is not, is to compute a table of reporting conditions by month or by season, and agree in the contract which entry applies once the test date is fixed. This is explicitly provided for, and it is the better answer to a schedule that has not settled. Four to twelve sets is the usual range, with more granularity in strongly seasonal climates.

The third path is common in practice and perfectly legitimate: the baseline is built after construction, from a PVsyst model updated to as-built, with the seasonal window chosen to match the test period that is by then already known. The risk is that whoever picks the window can pick a flattering one. The fix is to agree the rule rather than the numbers — "a two-month modeled window centered on the test period" is specific enough to be checked and leaves no room to shop for a season.

Whichever you choose, write it down. "Reporting conditions per ASTM E2939" without specifying the seasonal window is an ambiguity that will be discovered at the worst possible moment.

5. Run the Model and Extract the 8760

The energy model — PVsyst in most cases, or SAM — is run against the same weather file to produce an hourly (8760) dataset.

You need the raw hourly output, not the summary report. This is worth insisting on early: the summary PDF that gets circulated during development is useless for a capacity test, and by the time anyone notices, the modeling firm may have moved on or the license may have lapsed. Ask for the 8760 export while the model is still open.

At minimum the export must include, per hour:

  • AC power at the point of interconnection (E_Grid in PVsyst), and inverter output (EOutInv)
  • POA irradiance (GlobInc)
  • Ambient temperature and wind speed
  • Shading beam loss (ShdBLss) and inverter overload loss (IL_Pmax) — without these, the shading and clipping filters cannot be applied to the modeled side at all
  • For bifacial systems, rear POA irradiance (GlobBak)

6. Regress the Modeled Data

The same regression form E2848 uses is fitted to the filtered 8760:

Evaluated at the reporting conditions, this gives the modeled capacity. That value, the coefficients behind it, and the filters used to produce it are the baseline — and all three should be recorded, not just the final number. A baseline you cannot reproduce is a baseline you cannot defend.

Where Baselines Go Wrong

  • The model was never validated against the as-built plant. Module counts change, a string gets dropped, an inverter is substituted. A baseline from the pre-construction model tests a plant that was never built.
  • Soiling assumptions differ between baseline and test. Commissioning tests usually follow a wash, so the annual-average soiling loss carried in the energy model is the wrong number for the test window. Run the model with a soiling loss that reflects the plant's actual condition during the test, and agree that value before the model is re-run rather than after the result is known.
  • Availability assumptions. Models usually assume 100 % availability. The remedy is not to de-rate the baseline — nothing in either standard supports that — but to exclude the affected measured intervals, which is what E2848 requires anyway for an inverter that is off or not tracking. On the modeled side, run the simulation without downtime so the comparison is between a healthy model and a filtered measurement.
  • Filtering the baseline differently from the test. The same criteria and thresholds have to be applied to both sides wherever a modeled equivalent exists: the shading time window on the measured data corresponds to a shading-loss threshold on the model, the irradiance range and wind limit apply unchanged. A few filters have no counterpart at hourly resolution — inter-sensor spread, intra-interval stability — and that asymmetry should be stated rather than glossed over. This is the most common defect and the hardest to spot after the fact.
  • No seasonal window specified. Covered above, and worth repeating, because it is the one that turns into a commercial dispute rather than a technical correction.

Documenting It

A baseline that survives third-party review states, at minimum:

  • The weather source, its period of record, and why it was chosen
  • The seasonal window used for the reporting conditions, and the reasoning
  • Every filter applied, with thresholds, and the averaging interval used on each side — a PVsyst export is hourly, field data rarely coarser than 15 minutes
  • The resulting reporting conditions
  • The regression coefficients, the mean and standard deviation of the residuals, and the modeled capacity
  • The model version and the as-built configuration it represents
  • Once the test has run, a comparison of the conditions the baseline was drawn from against the conditions actually measured, before and after filtering

If you cannot hand a reviewer that list, expect the baseline itself to become the subject of the discussion rather than the plant's performance.

Next Steps

With the baseline set, the field half of the work begins. ASTM E2848 capacity testing covers the test window, filtering, regression, and a worked example of the capacity ratio calculation.

If your site has multiple array orientations, bifacial modules, or only GHI sensors, the baseline needs additional handling before the regression will be valid — see capacity testing for complex sites.

HelioTest stores the baseline alongside the test and drives both sides from a single filter configuration, applying the modeled equivalent wherever one exists, so the two datasets cannot silently drift apart. The reporting conditions are derived from the modeled dataset by default, and built-in checks flag it when the modeled window is off-center from the test period or when the result turns out to be sensitive to the choice of reporting conditions. Download a sample report to see how the baseline is documented.