9 Assumptions to Standardize in Solar Production Analysis

Two analysts can model the same roof and produce different annual values without either making an arithmetic error. One used a different weather file. Another assigned roof azimuth from imagery. Shading, soiling, module temperature, inverter behavior, availability, and curtailment may also sit behind the final number with no visible record.

Standardization should not force every project to use identical values. It should force every scenario to name the same categories, show the source and status of each input, and preserve the decisions that changed them. That makes disagreement inspectable.

This guide is for commercial solar design, analysis, and sales teams. It is not a prediction, performance guarantee, financing opinion, or substitute for engineering, lender, insurer, utility, authority, or manufacturer review. Use the model documentation and evidence applicable to the project.

Standardize definitions, not site values

A team needs two different records. The assumption dictionary defines what each input means and how it maps to a model. The project assumption register records the actual value, source, evidence status, owner, and change trigger for a particular run. Keep the dictionary reusable; keep site values project-specific.

Sandia’s PV modeling guide separates weather and design inputs, module behavior, conversion, and AC output. Use that calculation chain to name your fields. A label such as “losses: 14%” is insufficient without its included mechanisms, application stage, and source.

What should a production-assumption dictionary contain?

A production-assumption dictionary should define each input category, exact term, unit, accepted provenance, model location, owner, maturity state, default policy, project-evidence requirement, comparison rule, and reopen trigger for later review. It should also name overlaps and exclusions between categories, so shading, soiling, availability, curtailment, inverter behavior, or another effect cannot be counted twice or hidden inside an undefined total-loss field.

The dictionary is a company control, while the register is a project record. The dictionary explains what a field means and which evidence states are allowed. The project register records the actual value, source, status, and scenario. Do not paste standard values into the dictionary unless they are explicitly governed defaults with a permitted use.

Use this dictionary structure:

Use this copy-ready entry:

Assumption ID and canonical name:
Definition and model stage:
Unit, sign, and conversion rule:
Accepted provenance labels:
Default allowed only for:
Project evidence required:
Known overlaps and exclusions:
Comparison and sensitivity rule:
Owner and reopen trigger:

Version the dictionary. A software update, revised company method, new equipment model, or corrected definition can change how a field behaves without changing its display label. Active scenarios should retain the dictionary version used for their release.

Keep customer language mapped to the technical term. If a proposal says “system losses,” the report should reveal which dictionary categories contribute and which do not. A plain-language label may be appropriate, but it should not erase the calculation chain.

1. Weather data and period

Weather is the beginning of the modeled chain. Record the dataset provider, station or grid point, file identifier, period type, coverage, retrieval date, and any processing. Distinguish a typical-year file from observations for a particular year. A typical year is not a forecast for the next calendar year.

The PVPMC section on weather and design inputs covers irradiance, weather observations, sun position, orientation, and related inputs. A project record should show which variables the chosen model actually used and how missing fields were handled.

Standardize review questions:

• Does the file represent the correct geographic area and elevation basis where relevant?
• Are irradiance components and meteorological fields compatible with the model?
• Is the time convention understood?
• Did preprocessing alter units, timestamps, missing records, or extreme values?
• Is this dataset suitable for the decision, or is it an early screening default?

Do not call one weather source “conservative” without a defined comparison and period. Compare alternative valid datasets through controlled model runs and report the result as sensitivity, not proof that one future will occur.

2. Coordinates, elevation, and time basis

Latitude and longitude can point to the wrong parcel, the wrong building in a campus, or the center of a postal code. Record how the coordinate was established and the coordinate reference expected by the model. Preserve enough precision for site identity without implying survey accuracy that the source does not have.

Time basis matters throughout production and load comparison. State time zone, standard or daylight treatment, interval convention, and any conversion from source weather. A one-hour offset can move modeled output against consumption and tariff periods even when annual production remains unchanged.

Elevation may come from the weather dataset, site survey, mapping source, or model default. Record which one controls and whether the model uses it. Do not populate a field simply because the interface requires a number. If the source precision is coarse, carry that limitation.

Set a trigger when site identity, weather file, consumption series, or jurisdiction changes. Copying a prior project is a common way coordinates and time settings survive unnoticed.

3. Array geometry and orientation

Geometry includes tilt, azimuth, row spacing, module orientation, tracker configuration where used, and the assignment of modules to surfaces. Standardization should preserve whether a value came from a survey, drawing, remote model, customer record, or planning choice.

PVPMC documents array orientation as an input area for performance modeling. A production scenario should match the same array geometry shown in the current design. When the layout changes, the old run should not remain attached to the new proposal.

Use zone-level geometry instead of one site-wide average when materially different roof planes exist. Averaging east- and west-facing arrays into one azimuth can make the annual total appear plausible while distorting the daily shape used for load matching.

Keep setbacks and excluded areas in the design evidence, not in the production assumption register unless they affect the modeled array. The register should link to the layout revision that already contains them.

4. Shading and horizon treatment

Shading can come from near objects, terrain or horizon, adjacent rows, building features, and vegetation. Record the geometry source, observation date, model method, spatial resolution, seasonal assumptions, and any excluded future change. Separate shade from soiling and other optical losses even if a software interface groups them.

PVPMC collects material on shading, soiling, and reflection losses. These mechanisms can occupy nearby parts of a workflow while remaining physically different. The project should define which effect each input represents so the same loss is not applied twice.

Remote shade analysis needs a limitation. It may miss recent construction, tree growth, roof equipment, or geometry unavailable in the source. Field evidence can improve the model but also needs date, location, and method. Do not present a colored shade map as a site measurement unless it is one.

Reopen the assumption after array movement, obstruction change, new survey, vegetation plan, or site development information.

5. Module identity and electrical model

Record manufacturer, exact model, rating revision, model source, and the mathematical representation used by the analysis tool. A module with similar nameplate power is not necessarily equivalent in dimensions, electrical behavior, temperature coefficients, or compatibility.

The PVPMC DC module modeling section outlines model approaches and effective irradiance, temperature, and current-voltage relationships. The correct parameter set depends on the chosen method and product evidence. A software library entry should be checked against current documentation rather than accepted by name alone.

When a product is not selected, use an explicitly representative model only for the release stage that permits it. State which characteristics made it representative and what selection will trigger rerun. Do not carry “generic 550 W module” into a customer commitment or procurement-linked forecast.

Module quantity and zone assignment must reconcile with the layout and BOM. A model rerun after a product swap should also prompt geometry and stringing checks where dimensions or electrical properties differ.

6. Temperature model and mounting context

Module operating temperature affects modeled electrical behavior and depends on environmental and mounting conditions represented by the selected model. Record the temperature model, parameters, weather fields, mounting or airflow assumption, and source. Avoid a generic “roof mount” label when the model distinguishes configurations more specifically.

The U.S. Department of Energy discusses factors affecting PV performance and efficiency, including temperature at an educational level. The page does not select a temperature model for a particular array. That decision belongs with the analyst and model documentation.

Standardization should prevent silent changes when analysts copy projects or switch software versions. Put the parameter set in the scenario comparison. If the team lacks enough design detail, label the mounting treatment as preliminary and run sensitivity where it can affect the customer decision.

Do not confuse module temperature with ambient air temperature. Use the exact term and unit expected by the model.

7. Inverter and DC-to-AC configuration

The inverter model includes more than a rated power field. Record exact equipment, quantity, input allocation, efficiency representation, operating limits, clipping treatment, auxiliary use if modeled, and availability of current product parameters. The configuration should match the SLD and stringing basis.

A substitute inverter can change both electrical design and production analysis. Do not change only the model library selection. Reconcile inputs, ratios, string assignments, protection and equipment records through the responsible design review.

Use an explicit output point. Does the modeled result represent inverter AC output, an AC collection point, the meter, or another location after additional losses? Sandia’s modeling guide treats AC system output as a separate stage after conversion. Customer charts should name the output boundary.

Rerun after inverter model, quantity, stringing, export setting, or major DC configuration changes. Preserve old results beside their old equipment revision.

8. Loss categories and calculation order

Use named loss categories instead of one undifferentiated haircut. The categories depend on the model and project, but may address soiling, shading, reflection, mismatch, wiring, connections, availability, degradation, transformer or AC losses, and other modeled effects. Define each category and map it to the model stage where applied.

Standardize whether values are percentages, efficiencies, energy quantities, or model mechanisms. Record whether components combine additively, multiplicatively, chronologically, or through a physical submodel. Do not sum displayed percentages mentally and claim the result as total loss.

Guard against double counting. Detailed shading applied to irradiance should not reappear unchanged in a generic DC loss. Inverter efficiency modeled from a curve should not also be represented by a blanket conversion loss unless the method calls for it. The independent review should trace each category once through the chain.

Project-specific values need project-specific sources. A company default can support screening if labeled and reviewed; it does not become site evidence through repetition.

9. Availability, curtailment, degradation, and output use

Availability assumptions represent time or energy effects from outages and operating limits, depending on the model. Curtailment may arise from interconnection, export controls, grid direction, plant control, or operating decisions. Degradation describes change over time and needs a defined method and evidence. Keep these concepts separate.

State whether the result is a first-year scenario, a typical-year output, a lifetime series, or another period. Identify degradation start point and application if a multi-year model uses it. Availability should not silently absorb curtailment, snow, soiling, and maintenance because the model has one convenient field.

The output’s use controls review depth. A preliminary sales comparison may carry visible defaults. A lender or contract model can require independent criteria, data, and review that a sales tool cannot supply. Do not label an output “bankable” or approved because it looks detailed.

Create triggers for new utility limits, operating strategy, equipment reliability evidence, maintenance planning, contract guarantees, or changed financial horizon. Each can alter the meaning of the final production series.

Test whether the standard makes runs comparable

Freeze a baseline and compare the nine categories field by field before comparing annual outputs. Mark a difference as intended, inherited, unresolved, or introduced by software or library changes. Review linked changes as a declared group when they cannot be isolated physically. A result delta measures sensitivity under those inputs; it does not assign a probability to either scenario.

Illustrative workflow example, not a measured project result: An analyst intends to compare a revised layout with the prior proposal. The new run also inherits a different inverter record and generic loss setting. Restore or reconcile those unintended settings before attributing the result to layout. Retain the accepted linked changes and the exact run identities.

For a disputed pair of forecasts, follow the designer forecast reconciliation method. This article defines the team-wide input categories; that guide compares two specific runs.

Publish the assumption register beside the result

A production summary should show the assumptions most likely to change the reader’s decision and link to the full register. Include weather source and period, array revision, module and inverter identity, shading evidence, major loss categories, availability or curtailment treatment, output point, model version, and fact-check date.

Do not bury limitations in a small footer while presenting one annual number as certain. Put modeled, measured, estimated, and customer-supplied labels near the relevant inputs. Explain which assumptions are preliminary and what evidence will replace them.

Standardization succeeds when a second analyst can reproduce the scenario, challenge one input, and see every downstream document that needs an update. It does not erase uncertainty. It makes uncertainty possible to manage.

Link the standard to release review

Use the production estimate trust checklist for the pre-send ready, conditional, or hold decision. Unresolved site identity, stale equipment, duplicated losses, ambiguous output boundaries, or unexplained scenario drift need a named owner and closure evidence. A plausible annual number cannot close an evidence gap.

Maintain a distribution record showing which proposal, financial file, customer chart, or external package uses each run. When an input changes, review those consumers and retain the superseded package. Updating a model does not update a previously exported PDF.

Apply different assumption gates at each milestone

An assumption acceptable for lead screening may be unacceptable for a signed proposal or procurement-linked forecast. Teams need named maturity gates so a value cannot move downstream merely because nobody reopened the model.

At screening, require correct site identity, a suitable weather source, approximate geometry with its source, a representative equipment basis, and visible defaults. The output should support a question such as whether the roof and load deserve deeper work. It should not support a production guarantee or final financial commitment.

At proposal development, require the current layout, clearer equipment identity, shade evidence appropriate to the site, a reviewed loss register, customer load and tariff sources where financial output is shown, and scenario limitations visible in the customer document. Any product or site assumption still open needs an owner and a trigger before the next release.

At technical design, reconcile production inputs with electrical and structural decisions. Module and inverter selections, string configuration, array zones, support constraints, and external operating limits can change the model. The production file should point to those accepted revisions rather than reconstruct them separately.

At contract, finance, or external review, follow the criteria required by the responsible party. They may request particular datasets, independent review, probability treatment, reports, or sensitivity cases. The sales-stage register is useful evidence of how the scenario developed, but it does not replace that party’s requirements.

Use a maturity table:

The gate should fail loudly when maturity is missing. Do not solve a failure by renaming the scenario “final.” Return the missing evidence, restrict the output, or route the decision to the reviewer who can accept the remaining uncertainty.

Keep a reason for every assumption change between gates. A weather file may change because the later reviewer requires another dataset. A generic module may become a selected product. A shade input may change after survey. These are healthy refinements when the record explains them.

Also preserve assumptions that did not change. If a proposal update affects price only, the production scenario can remain linked to its prior accepted model. Regenerating every output without need increases the chance that a default or software version changes silently.

Before publishing a customer-facing revision, run a delta report across the nine categories. The reviewer should be able to see changed values, sources, model locations, output effects, and required downstream updates. If the software cannot export that comparison, maintain it in the project record.

Finally, test one old project against the new gate. Do not change its published result. Reconstruct the register from retained files and mark every field that cannot be proven. Those gaps show where the workflow previously depended on analyst memory. Use them to improve future capture, not to invent retrospective certainty. A mature register is valuable precisely because it shows what the team does not know alongside what it can support, including the exact evidence another reviewer would need to close each material gap before the next scenario release.

Sources reviewed September 30, 2026. The dictionary and project values require review by the responsible team; this guide does not confer external approval.

Frequently Asked Questions

What is a solar production assumption register?

It is a controlled list of the inputs and choices that shape a production scenario. Each entry states the value, unit, source, owner, status, observation date, model location, sensitivity, and review trigger. The register lets another reviewer distinguish measured project facts from defaults, estimates, and customer-supplied scenarios.

Should every project use the same solar loss percentages?

No. Teams can standardize loss categories, evidence requirements, and review methods, but project values should reflect site conditions, equipment, configuration, climate data, operating plan, and model behavior. A shared default may support early screening when visibly labeled, yet it should not survive into later releases without project-specific justification.

How often should production assumptions be updated?

Update an assumption when its source expires, the layout or equipment changes, better site evidence arrives, the weather or tariff dataset changes, an operating constraint appears, or the release purpose becomes more consequential. Review volatile and project-specific inputs more often than stable definitions, and preserve prior scenarios rather than overwriting them.

Can two analysts compare results from different solar models?

Yes, if they first reconcile weather data, geometry, equipment, loss definitions, time basis, availability, curtailment, and output point. A result difference can come from inputs, model algorithms, or configuration. Comparing annual totals alone cannot identify the cause; run controlled cases that change one declared element at a time.

Does a standardized production model guarantee actual generation?

No. Standardization makes assumptions visible and scenarios reproducible within the chosen method. Actual production depends on weather, soiling, shading, equipment behavior, outages, curtailment, installation, maintenance, and other conditions. A modeled value should carry its source basis, uncertainty, intended use, and any approval or finance limitations.