Terms & Concepts

This page explains some of the more complex topics you might come across when creating an energy site or creating a simulation request.

Energy Sites

System Losses/Derate
The GeneralDerate_Percent parameter is used to specify system losses that affect the energy output of a PV system but are not separately modeled by either of the SolarAnywhere solar simulation models (CprPVForm or pvlib). If you know the system losses, GeneralDerate_Percent can be calculated as:

GeneralDerate_Percent = 100 – System Losses (%) Eqn (1)
For example, a system loss of 14% can be converted to a General derate percent of 86% using the above equation. Table 1 shows a comparison of system losses between power models:

Table 1: Breakdown of general derate percentage by power model
pvlib (PVWatts) CprPVForm
General Derate Percent (Default) 86% 85%
System loss categories and defaults Soiling = 2%

Shading = 3%

Snow = 0%

Mismatch = 2%

Wiring = 2%

Connections = 0.5%

Light-induced Degradation = 1.5%

Nameplate Rating = 1%

Age = 0%

Availability = 3%
Soiling, Snow, Mismatch, Wiring, Connections, Age, Availability
Losses excluded from GeneralDerate_Percent Inverter Efficiency Inverter Efficiency, Shading, Degradation, Nameplate (STC) rating


Losses in the pvlib model

The system loss percentages presented in Table 1 are widely accepted default values for each loss component. However, these values can differ from system to system. You can adjust the defaults and calculate custom system losses using the formula:

Equation 2 Total Losses Calculation Eqn (2) (Source: PVWATTS documentation)
It is important to note that the total system loss is not simply the sum of the individual losses. The default system loss and GeneralDerate_Percent are calculated using Eqn (1) and (2) in the following steps:
  1. Calculate total system loss from individual components using Eqn (2).

    100% × [ 1- ( 1 - 0.02 ) × ( 1 - 0.03 ) × ( 1 - 0.02 ) × ( 1 - 0.02 ) × ( 1 - 0.005 ) × ( 1 - 0.015) × ( 1- 0.01 ) × ( 1 - 0.03) ] = 14%
  2. Calculate GeneralDerate_Percent from System Loss percent using Eqn (1).

    GeneralDerate_Percent = 100 – 14 = 86%
Losses in the CprPVForm model

The Total System Losses used to calculate the GeneralDerate_Percent should account for losses due to inverter efficiency, shading, PTC rating and degradation, as well as general system losses not explicitly specified. The power model calculates Total System Losses:

Total System Losses = General System Losses x Inverter Efficiency (%) x PTC Rating (kW) x Shading x Degradation

A degradation factor of 0.5% is considered for the CprPVForm model and cannot be modified.
Albedo Percent
Albedo (also called ground reflectance) is defined as the fraction of the Global Horizontal Irradiance that is reflected off the ground. The Albedo_Percent parameter is used by both SolarAnywhere solar simulation models (CprPVForm or pvlib) to adjust the incident irradiance on the PV module so that it accounts for the effect of irradiance reflected off the ground. To specify the albedo percent, insert Albedo_Percent="{Decimal Value}” into the PvSystem details.Albedo_Percent will be approximately equal to zero for dark surfaces that absorb all of the light incident. Albedo_Percent will be approximately equal to 100 for light surfaces that reflect all of the light incident. Both simulation models use a default value of 17%.

You can request SolarAnywhere satellite based albedo data at your location by including Albedo_Unitless as an OutputField or AverageAlbedo as a SummaryOutputField in your simulation request. You can learn more about SolarAnywhere albedo data by visiting this page of the SolarAnywhere website.

Additionally, Table 2 provides examples of albedo values for various types of ground surface. Additional information on possible values for albedo can be found at the Sandia National Laboratories website.

Table 2: Albedo values for various ground surface types (Source: Sandia PVFORM User’s Manual)
Surface Type Ranges for Albedo
Fresh snow cover 75% to 95%
Sandy soil 15% to 40%
Meadows and fields 12% to 30%
Densely built up areas 15% to 25%
Dark, cultivated soil 7% to 10%
PV Systems
Both of the SolarAnywhere solar simulation models (CprPVForm or pvlib) require the client to define one or multiple PvSystem(s). A PvSystem is made up of modules and inverters that are wired together in specific configurations. The PvSystem will output power at the point of interconnection (to the electric grid or to energy storage). The Solar Simulations API models the amount of power that this PvSystem is outputting. The PvSystem components will define how the PV simulation model calculates alternating current (AC) power and AC energy from the irradiance and weather data. PvSystem(s) modules output direct current (DC), which is then converted to AC by the inverter. See sections on Inverter, PV Modules and Array Configuration for more information on how these specific inputs impact the simulation.
Inverters
Inverter is a PvSystem component. Each is wired to a set of PV modules and converts the DC output of the module into AC power. Both of the SolarAnywhere solar simulation models (CprPVForm or pvlib) require that the client pass information about the number (Count), maximum rated power (MaxPowerOutputAC_kW) and rated efficiency (EfficiencyRating_Percent) for each inverter. For a mapping of inverter models to necessary input ratings, see the CEC inverter list.
PV Modules
PvModule is a component of a PvSystem. Each PV module converts incident irradiance under the ambient weather into DC output, which the inverter then converts to AC power.

Both SolarAnywhere solar simulation models (CprPVForm or pvlib) require that the client pass information about the number (Count) and rating of the PV modules. You will need to specify the performance test conditions AC rating (PtcRating_kW) of the PV modules and the nameplate DC rating (NameplateDCRating_kW). The CprPVForm simulation model will utilize the PtcRating_kW while the pvlib model will utilize the NameplateDCRating_kW.

If desired, you can also specify the module temperature rating (PowerTemperatureCoefficient_PercentPerDegreeC). If the client leaves this blank, the pvlib simulation model uses a default of 0.37%/°C and CprPVForm uses a default value of 0.40%/°C. For a mapping of PV modules to necessary input ratings, see the CEC module list.
Nameplate Rating
The nameplate DC rating of a solar panel is a PvModule component and describes the maximum rated output of the PV module under industry standard test conditions (STC). Standard test conditions are defined as 1,000 W/m2 of solar irradiance, an air mass of 1.5, and an operating cell temperature of 25°C. STC conditions are generally more ideal than what might happen in real-world conditions – for example, on most days except for a few clear spring or summer days, the solar insolation will be less than 1000 W/m2 and module temperature might be higher than 25°C. STC rating also does not account for the effect of wind speed and module height above ground. The SolarAnywhere pvlib solar simulation model uses Nameplate (STC) rating to account for PV module performance.

The module nameplate rating is a PvModule element. To specify the Nameplate or STC rating, insert NameplateDCRating_kW =”{Integer Value}” into the PvModule details.
PTC Rating
The performance test conditions (PTC) DC rating of a solar panel is a PvModule component and describes the maximum rated output of the PV module when operating in an environment with 1,000 W/m2 of solar irradiance, an air mass of 1.5, and an ambient temperature of 20°C at 10 meters above ground level with a wind speed of 1 meter per second. Additionally, the operating cell temperature is raised to 45°C in PTC tests. PTC are considered more representative of real-world operating conditions. The SolarAnywhere CprPVForm solar simulations model uses PTC rating to account for PV module performance.

The module PTC rating is a PvModule element. To specify the PTC rating, insert PtcRating_kW =”{Integer Value}” into the PvModule details.
Power Temperature Coefficient
The power temperature coefficient is a PvModule component and quantifies the effect of module operating temperature on the AC power output of the system. As the cell temperature increases, the power output of the module decreases. Manufacturers of PV modules usually provide this value in the module’s data sheet. To specify power temperature coefficient, insert PowerTemperatureCoefficient_PercentPerDegreeC = "{Decimal Value}” into the PvModule details. If not specified, the SolarAnywhere pvlib simulation model uses a default power temperature coefficient of 0.37%/°C and CprPVForm uses a default value of 0.40%/°C. Table 3 demonstrates common power temperature coefficients associated with different PV module types.

Table 3: Power temperature coefficients for standard, premium, and thin film panels (Source: NREL PVWATTS)
Module Type Temperature Coefficient
Standard PV (crystalline Silicon) 0.37%/°C
Premium (crystalline Silicon) 0.35%/°C
Thin Film 0.32%/°C
Array Configuration
The ArrayConfiguration is a component of a PvSystem that defines how the system is installed. The ArrayConfiguration elements are important to the simulation model as they help determine the incident irradiance on the plane of the PV module array, and can have a significant impact on the simulation accuracy. The SolarAnywhere solar simulation models (CprPVForm or pvlib) require that the client pass information about the tilt angle from horizontal (Tilt_Degrees) and azimuth angle (Azimuth_Degrees) in which each set of PV modules is installed. For residential systems, the tilt angle often is specified by the roof pitch. The azimuth angle is a reference to the Cardinal Direction that the array of PV modules is facing. The simulation modeIs use 180-degrees as South reference (90-degrees is East and 270-degrees is West). The client can also specify the type of tracking system on which the PV modules are mounted (Tracking), the rotation limit of the tracker (TrackingRotationLimit_Degrees), the number of rows of modules (ModuleRowCount) and the relative module row spacing (RelativeRowSpacing).
Tracking
The SolarAnywhere solar simulation models (CprPVForm or pvlib) support fixed and single-axis tracking PV systems. Additionally, CprPVForm can support dual-axis tracking PV systems and pvlib can support single-axis tracking systems with backtracking capabilities. If a single or dual-axis tracking type is specified, the simulation model calculates the rotation angle that minimizes the angle of incidence throughout the day. The angle of incidence is defined as the angle between a line that is normal to the module surface and a line drawn on a straight path from the sun to the module surface.

Fixed Tilt
  • Supported by: pvlib and CprPVForm power models.
  • Fixed tilt arrays do not track the sun to minimize the angle of incidence.
  • When defining a fixed tilt array, specify the following in theArrayConfiguration details:
    • Tracking=“Fixed”
    • The array surface tilt parameter: Tilt_Degrees
    • The array surface azimuth angle: Azimuth_Degrees
Single-Axis Tracking
    • Supported by: pvlib and CprPVForm power models.
    • Single-axis trackers move along a single axis of rotation. Single-axis trackers can be classified as horizontal, tilted, or vertical based on the tilt angle of the rotation axis with respect to horizontal.
    • Horizontal-axis trackers are most common in commercial and utility-scale systems. Horizontal tracking arrays are usually oriented North-South with modules that rotate from East to West throughout the day, limited by the tracking rotation limit.
    • When defining a single-axis tracking array, specify the following in theArrayConfiguration details:
      • Tracking=“SingleAxis”
      • The array axis of rotation tilt parameter: Tilt_Degrees
      • The array axis of rotation azimuth angle: Azimuth_Degrees
      • The tracking rotation limit: TrackingRotationLimit_Degrees
Single-Axis Tracking with Backtracking
  • Supported by: pvlib power model.
  • As tracking PV systems move to maximize exposure to solar irradiance, adjacent PV panels can partially shade each other across part of the module when the sun is low in the sky (i.e. the morning and evening hours). This effect, known as self-shading or row-on-row shading can decrease the output of a solar PV system by creating electrical mismatch losses. Backtracking is a tracking technology that operates single-axis trackers at a tilt or rotation angle other than the “ideal” rotation to minimize the effect of inter-row shading. The pvlib power model can model single-axis energy systems with backtracking technology.
  • When defining a single-axis tracking array with backtracking, specify the following in theArrayConfiguration details:
    • Tracking=“SingleAxisWithBacktracking”
    • The array axis of rotation azimuth angle: Azimuth_Degrees
    • The tracking rotation limit: TrackingRotationLimit_Degrees
Dual-Axis Tracking
  • Supported by: CprPVForm power model.
  • Dual-Axis trackers can move along two axes of rotation (East-West and North-South). This allows them to always maintain a 0° angle of incidence, which maximizes the solar radiation hitting the solar panels. Unlike with single-axis trackers, no tracking limit is placed on the rotation in the azimuth direction.
  • When defining a dual-axis tracking array, specify the following in theArrayConfiguration details:
    • Tracking=“DualAxis”
    • The tracking rotation limit: TrackingRotationLimit_Degrees
Tracking Rotation Limit
The tracking rotation limit is the rotational limit in degrees for single axis tracking systems. It is possible to use values between 0 and 90, which represent half the full range of motion of the tracker. For example, a value of 60 means the tracker can move +/-60 degrees around the axis of rotation for an overall range of 120 degrees. To specify tracking rotation limit, insert TrackingRotationLimit_Degrees =“{Decimal Value}”, into the ArrayConfiguration details.
Module Row Count
Module row count is the total number of rows in each PV array. As shown in figure 1, this value will correspond to the number of PV strings in parallel within an array. This parameter is used by both SolarAnywhere solar simulation models (CprPVForm or pvlib) to model the effect of row-to-row shading. To specify module row count, insert ModuleRowCount = "{Integer Value}” into the ArrayConfiguration details.

Figure 1: Module row count
Module Row Count Diagram
Relative Row Spacing/Ground Coverage Ratio
Relative row spacing is the inverse of the ground coverage ratio (GCR) and can be calculated as the ratio of row-to-row pitch to array length. A lower GCR (higher relative row spacing) means wider row spacing and a higher GCR means narrower row spacing. Typical utility scale PV systems have GCRs in the range of 0.3 to 0.6. This parameter is also used by both SolarAnywhere solar simulation models (CprPVForm or pvlib) to model the effects of row-to-row shading. The default value of relative row spacing used in both simulation models is 3, which is equal to a GCR of 0.3. To specify row spacing, insert RelativeRowSpacing = "{Decimal Value}” into the ArrayConfiguration details.

Figure 2: Relative row spacing
Relative Row Spacing/Ground Coverage Ratio Diagram

Energy Site Simulation

SolarAnywhere Solar Simulation Models
Clean Power Research offers two energy simulation models: pvlib and CprPVForm. Visit the introduction page for more detail on these models. Table 4 outlines their capabilities and limitations.

Table 4: Comparison of the CprPVForm and pvlib solar simulation models
CprPVForm pvlib
General Derate Percent Default: 85% Default: 86%
Module Rating PTC Rating STC Rating
Module Power Temperature Coefficient Default: 0.40%/°C Default: 0.37%/°C
Tracking types Fixed-Axis, Single Axis, Two-Axis Fixed-Axis, Single Axis, Single Axis with Backtracking
Reflection Losses No Yes
Near-object shading Yes No
Row-on-row shading Yes Yes
Snow Losses No Yes
Temperature Modeling
The SolarAnywhere pvlib solar simulation model uses the Faiman temperature model to calculate PV module temperature. The Faiman model implements the empirical heat loss factor model described in the original publication: “Faiman, D. (2008). “Assessing the outdoor operating temperature of photovoltaic modules.” Progress in Photovoltaics 16(4): 307-315.”

The Faiman model was adopted in the IEC 61853-2 and IEC 61853-3 standards published by the International Electrotechnical Commission (IEC) in 2018. When using the pvlib energy simulation model in the SolarAnywhere API, the Faiman model implements SolarAnywhere ambient temperature and wind speed data to determine PV module/cell temperature.

The following assumptions are used internally in the Faiman temperature model and cannot be modified by the user:

Table 5: Faiman temperature model internal assumptions
Internal parameters Definition Default value in pvlib
u0 Combined heat loss factor coefficient. The default value was determined by Faiman for 7 silicon modules. [W/m^2C] 25.0
u1 Combined heat loss factor influenced by wind. The default value was determined by Faiman for 7 silicon modules. [W/m^2 C (m/s)] 6.84
Module (DC) and Inverter (AC) Modeling
The SolarAnywhere pvlib solar simulation model uses NREL PVWatts as the core simulation engine for PV module and inverter modeling. The PVWatts model has been used extensively by solar project developers and financiers for PV performance assessment and is also supported by the System Advisor Model (SAM).

PVWatts makes internal assumptions about module and inverter characteristics, enabling energy simulations API users to accurately model any PV system type and configuration with just a few basic inputs about their energy site.

The following assumptions are used internally in the pvlib implementation of PVWatts DC and AC models and cannot be modified by the user:

Table 6: pvlib module and inverter modeling assumptions
Internal parameters Definition Default value in pvlib
T_ref Cell reference temperature for DC modeling. [Celsius] 25.0
Eta_inv_ref Reference inverter efficiency. [Unitless] 0.9637
Near Object Shading Losses
The SolarAnywhere CprPVForm solar simulations model supports two shading and obstruction models that can be input into ShadingOptions as ShadingModel="ShadeSimulator" or ShadingModel="MonthlyPercentSolarResource". The SolarAnywhere pvlib solar simulation model does not currently support a near-object shading model.

Shade Simulator

The shade simulator model uses information about obstructions surrounding the PV system to modify simulated output. Obstructions can be objects such as trees or adjacent buildings that shade the PV system at certain times of day.

Figure 3: The interaction of a shading object with a PV system
Solar Obstructions

Specifying obstructions for the ShadeSimuator model requires an input combination of azimuth, elevation, and opacity for each obstruction in relation to the position of the PV system. The distance and height of shadow-casting objects can be calculated using a site plan and sun path diagram or shading analysis software coupled with digital photography. The azimuths of the obstructions can be calculated directly from the site plan or sketch. The opacity or transmission factor specifies the amount of solar radiation passing through the shading objects.

The azimuths, elevations, and opacities of solar obstructions are PvSystems elements and can be specified at the time of creating an energy site using the Clean Power Research simulation API.

The shade simulator uses the azimuths, elevations, and opacities of the obstructions to generate a digital elevation model (DEM). This is an internal, three-dimensional model of the obstructions surrounding the PV system that is used to modify simulation outputs based on the time of day.

Figure 4: The solar obstruction profile determined using a DEM
Solar Obstruction Profiles

Monthly Percent Solar Resource

The MonthlyPercentSolarResource shading model is useful when details about the surrounding obstructions (buildings, trees, etc.) are unknown. This model applies monthly solar access percentage derate factors to hourly simulation outputs to account for the effect of shading on PV system production.

The solar access percentage can be calculated as the ratio of incident solar energy on the shaded PV panel to the incident solar energy on the un-obstructed PV panel. It is the opposite of the shading percentage. For example, an array with 10% shading would have a solar access of 90%. If monthly shading percentages are not specified, 100% solar access (0% shading) is assumed for all months.

Figure 5: The percentage of solar energy available each month based on the site-specific shade conditions
Monthly Percent Solar Access Percentages

Monthly solar access percentages are PvSystems elements and can be specified at the time of creating an energy site using the Clean Power Research simulation API.
Snow Losses
Accumulated snow can reduce the energy output of a solar PV system by obstructing the sunlight available for energy conversion. PV energy losses due to snow—commonly referred to as “snow losses”—vary widely between locations. Modeling the uncertainty that results from snow losses can be complex, as several factors can affect the rate of snow accumulation and shedding. The local climate and the PV system’s configuration (such as the system tilt and tracking type) can impact the magnitude of energy losses.

The SolarAnywhere pvlib solar simulation model uses the snow loss model developed and validated by NREL. pvlib leverages SolarAnywhere snow depth and ambient temperature data as well as user provided energy site configuration(s) to calculate site-specific snow loss estimates. To learn more about the snow loss model, refer to the original publications: “Marion, B.; Schaefer, R.; Caine, H.; Sanchez, G. (2013). ‘Measured and modeled photovoltaic system energy losses from snow for Colorado and Wisconsin locations.’ Solar Energy 97; pp.112-121” and “Ryberg, D; Freeman, J. (2017). “Integration, Validation, and Application of a PV Snow Coverage Model in SAM” NREL Technical Report NREL/TP-6A20-68705.”

The following assumptions are used internally and cannot be modified by the user:

Table 7: pvlib snow loss modeling assumptions
Internal parameters Definition Default value in pvlib
Initial_coverage Fraction of row’s slant height that is covered with snow at the beginning of the simulation. [Unitless] 0
threshold_snowfall Hourly snowfall above which snow coverage is set to the row’s slant height. [cm/hr] 1.0
can_slide_coefficient Coefficient to determine if snow can slide given irradiance and air temperature. [W/(m^2 C)] -80
slide_amount_coefficient Coefficient to determine fraction of snow that slides off in one hour. The default indicates value in tenths of a module’s slant height. [Unitless] 0.197
Improving the accuracy of P50/P90 loss estimates with time-series modeling can reduce the uncertainty in reported energy estimates. This helps project owners minimize financial and operational risk to their solar project. To learn more about snow loss modeling with SolarAnywhere time-series weather data, see the blog and snow-losses resource page.
Reflection Losses
The angle of incidence (AOI) is defined as the angle between a line that is normal to the module surface and a line drawn on a straight path from the sun to the module surface. When the AOI is greater than zero, there are optical losses due to increased reflections from the module materials. To quantify reflection losses, an angle of incidence modifier (IAM loss factor) is calculated using an IAM model and is defined as the ratio of non-normal to normal incidence transmitted light after deducting the reflected portion of each component.

The SolarAnywhere pvlib solar simulation model uses the Physical IAM model to quantify reflection losses. The Physical IAM model determines the fraction of light transmitted through the air-glass interface as a function of AOI and models the attenuation in the glazing layer. To learn more about the Physical IAM model, see the original publication: “W. De Soto et al., “Improvement and validation of a model for photovoltaic array performance”, Solar Energy, vol 80, pp. 78-88, 2006.” The following assumptions are used internally for the Physical IAM model and cannot be modified by the user:

Table 8: pvlib reflection losses modeling assumptions
Internal parameters Definition Default value in pvlib
n The effective index of refraction. [Unitless] 1.526 for glass
K The glazing extinction coefficient. [1/m] 4.0
L The glazing thickness. [m] 0.002 (2 mm)
Self-shading losses
Self-shading losses (also known as row-to-row shading losses) occur when adjacent PV rows partially shade each other, blocking direct irradiance from reaching parts of the shaded module. At steep tilt and low sun elevation (i.e., morning and evening hours), inter-row shading creates cell to cell electrical mismatch in modules with a conventional cell layout, resulting in severe nonlinear power loss.

To determine losses due to row-to-row shading the SolarAnywhere CprPVForm and pvlib solar simulation models implement a simplistic model based on first principle solar geometry. The model has been described in “Richard Perez, Ronald Stewart (1985) ‘Solar Irradiance Conversion Models’, ASRC, State University of New York Albany”.

Even when the sun is high in the sky, a row’s view of the sky dome will be partially blocked by the row in front. This causes a reduction in the diffuse irradiance incident on the module. The pvlib model also implements the diffuse self-shading model described in “D. Passias and B. Källbäck, ‘Shading effects in rows of solar cell panels’, Solar Cells, Volume 11, Pages 281-291. 1984. DOI: 10.1016/0379-6787(84)90017-6”, to estimate the fraction of sky diffuse irradiance that is blocked by the row in front.
Time Stamps
The simulation request time stamps indicate the start and end period for which the client wishes to return data. Time stamps are absolute and follow the ISO 8601 convention. For example, if the client wishes to request data from January 1, 2020 at 11:00 AM Pacific Standard Time to January 2, 2020 at 12:00 PM Eastern Standard Time:
  • StartTime ="2020-01-01T11:00:00-08:00"
  • EndTime="2020-01-02T12:00:00-05:00"
Time stamps are all handled as an absolute reference, so if the client wishes to request forecast data, they will need to create a time stamp for a future time from the present. Forecast data can be requested up to 90-days ahead. Short and medium term forecast models apply for forecast horizons of 1-minute up to 168-hours (7-days) into the future. Climatology models are applied starting on day 8 out to 90-days. Time stamps with a different GMT offset in the StartTime and EndTime will be synchronized in the response to the time zone of which the site location falls.
Irradiance and Weather Data
In energy simulation requests you can also request SolarAnywhere irradiance and weather data output fields. To see a list of all of the irradiance and weather data output field options, you can visit this page of our documentation.
Simulation Output Fields
When included in a simulation request the following output fields and summary output fields will be generated based on the inputs specified when creating an energy site:

  • PlaneOfArrayIrradiance_WattsPerMeterSquared:The irradiance incident on the plane of the array (POA) based on the sun’s position, the module spacing, the module orientation (azimuth), tracking (if applicable), shading and ground surface albedo. POAI is modeled using the Perez transposition model.
  • PowerAC_kW:The modeled power output of the PV system based on the total available plane of array irradiance, weather conditions, shading, array configuration, and module and inverter characteristics.
  • PowerDC_kW:The modeled power output of the PV modules based on the total available plane of array irradiance, weather conditions, shading, array configuration, and module characteristics.
  • EnergyAC_kWh: The modeled energy output of the PV system based on the total available plane of array irradiance, weather conditions, shading, array configuration, and module and inverter characteristics.
  • ClearSkyPowerAC_kW: The modeled power output of the PV system based on the total available clear sky plane of array irradiance, weather conditions, shading, array configuration, and module and inverter characteristics. The clear sky irradiance is the irradiance calculated assuming there are no clouds present.
  • ClearSkyEnergyAC_kWh:The modeled energy output of the PV system based on the total available clear sky plane of array irradiance, weather conditions, shading, array configuration, and module and inverter characteristics. The clear sky irradiance is the irradiance calculated assuming there are no clouds present.
  • PVModuleTemperature_DegreesC: The modeled operating temperature of the PV modules based on the ambient temperature and wind speed as well as the PV module characteristics.
  • SnowLossesDC_kW:* The modeled DC power output losses in kW due to snow accumulation on the PV module surface. See the snow losses definition above for more information on the snow loss model.
  • SnowLossesDC_Percent:*The percentage of total DC power output lost due to snow accumulation on the PV module surfaces. See the snow losses definition above for more information on the snow loss model.
Simulation Summary Output Fields:
  • TotalEnergy: Total modeled energy output of the PV system (summed to calendar month and year) based on the total available plane of array irradiance, weather conditions, shading, array configuration, and module and inverter characteristics over the period of measure specified by the request StartTime and EndTime. Units of kWh.
  • TotalSnowLosses:* Total DC power output (summed to calendar month and year) lost due to snow accumulation on the PV module surfaces over the period of measure specified by the request StartTime and EndTime. Units of kW.
  • AveragePercentSnowLosses:* Mean percentage of total DC power output (averaged to calendar month and year) lost due to snow accumulation on the PV module surfaces over the period of measure specified by the request StartTime and EndTime.
*Field can only be requested when you have specified PowerModel="PvLib" and SnowLossModel="NREL" in your simulation request, and you are requesting historical or real-time time series data. Real-time time series requests for this field outside the Continental United States is limited to the trailing week rather than the current hour. Unavailable for forecast requests or requests for typical year or average year weather data sources.

What’s Next?