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:

	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:

	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 (also called ground reflectance) is defined as the fraction of the Global Horizontal Irradiance that is reflected off the ground. The albedo value is used to adjust the ground reflected irradiance component of the Plane-of-Array Irradiance (POAI) and also has a significant impact on the rear-side irradiance of bifacial modules.

SolarAnywhere uses a default albedo value of 0.17 irrespective of the data model version or the simulation time range.
At any time, the user has the option of overriding the default behavior by specifying a static Albedo_Percent parameter in the energy site specification. 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. 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.

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%

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.

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.

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.

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 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.

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.

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.

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.

Module Type	Temperature Coefficient
Standard PV (crystalline Silicon)	0.37%/°C
Premium (crystalline Silicon)	0.35%/°C
Thin Film	0.32%/°C

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).

For Bifacial PV systems, the user has the option to specify different parameters that can affect Bifacial energy output. Table 5 lists the optional array configuration parameters for a bifacial energy site.

Optional Energy Site Parameters	Definition	Default value	Acceptable Ranges	Unit
BifacialityFactor_Unitless	Ratio of the efficiency of the module’s rear surface to the efficiency of the front surface.	0.65	0 to 1, inclusive	Unitless
RowHeight_Meters	Height of the center point of the row above the ground.	1	1 to 50	meters
Pitch_Meters	Distance between two rows.	10	1 to 50	meters
TransmissionFactor_Unitless	Fraction of irradiance on the back surface that does not reach the module’s cells due to module features such as busbars, junction box, etc. A negative value is a reduction in back irradiance.	-0.013	-1 to 0, inclusive	Unitless
ShadeFactor_Unitless	Fraction of back surface irradiance that is blocked by array mounting structures. Negative value is a reduction in back irradiance.	-0.02	-1 to 0, inclusive	Unitless

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 the ArrayConfiguration 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 the ArrayConfiguration 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 the ArrayConfiguration 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 the ArrayConfiguration details:
  • Tracking=“DualAxis”
  • The tracking rotation limit: TrackingRotationLimit_Degrees

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 =“{Integer Value}”, into the ArrayConfiguration details.

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.

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.

The Pvlib power model supports Bifacial PV system modeling. To specify a bifacial PV system, set Bifacial as true in the PvSystems element of the energy site definition. If your PV system has monofacial PV modules, specify Bifacial as false or remove it from the request completely.

SolarAnywhere supports modeling energy sites with a mix of monofacial and bifacial PV systems, such that an inverter in the PV system can only be connected to either Monofacial PV Arrays or Bifacial PV Arrays. To specify energy sites with a mix of monofacial and bifacial systems on the site, set Bifacial as true in the PV system element for Bifacial PV Arrays and Bifacial as false for Monofacial PV Arrays.

Array geometry is defined by the following array configuration parameters:

• RelativeRowSpacing, which is the inverse of the ground coverage ratio (GCR). GCR is defined as the ratio of row slant height to the spacing between rows (pitch).
• Height of row center above ground, specified as RowHeight_Meters
• Distance between two rows of PV modules, specified as Pitch_Meters
• Tilt of the row from horizontal, Tilt_Degrees
• Azimuth of the row’s normal vector, Azimuth_Degrees

SolarAnywhere API users can specify the following optional input parameters for use with this model. Table 2 lists the optional set of parameters for use with bifacial energy systems.

Optional Energy Site Parameters	Definition	Default value	Acceptable Ranges	Unit
BifacialityFactor_Unitless	Ratio of the efficiency of the module’s rear surface to the efficiency of the front surface.	0.65	0 to 1, inclusive	Unitless
RowHeight_Meters	Height of the center point of the row above the ground.	1	1 to 50	meters
Pitch_Meters	Distance between two rows.	10	1 to 50	meters
TransmissionFactor_Unitless	Fraction of irradiance on the back surface that does not reach the module’s cells due to module features such as busbars, junction box, etc. A negative value is a reduction in back irradiance.	-0.013	-1 to 0, inclusive	Unitless
ShadeFactor_Unitless	Fraction of back surface irradiance that is blocked by array mounting structures. Negative value is a reduction in back irradiance.	-0.02	-1 to 0, inclusive	Unitless

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

	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	Yes
Row-on-row shading	Yes	Yes
Snow Losses	No	Yes
Soiling Losses	No	Yes
Bifacial	No	Yes

The pvlib solar simulation model in SolarAnywhere 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:

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

The pvlib solar simulation model in SolarAnywhere 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:

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

MonthlyPercentSolarResource

The MonthlyPercentSolarResource shading model can be applied when using either of the available SolarAnywhere solar simulation models. This shading 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.



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.

ShadeSimulator

The ShadeSimulator model can only be applied using the SolarAnywhere CprPVForm solar simulations model. The ShadeSimulator 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.



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.

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 pvlib solar simulation model in SolarAnywhere 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. Because snow loss calculations are based on accumulated snow, the snow loss model will consider snow depth and ambient temperature data for 6 months prior to the start time specified in your simulation request. 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 input parameters and default values used in the Snow Loss model are as follows:

Internal parameters	Definition	Default value in pvlib	Can be specified by the user
Initial_coverage	Fraction of row’s slant height that is covered with snow at the beginning of the simulation. [Unitless]	0	No
threshold_snowfall	Hourly snowfall above which snow coverage is set to the row’s slant height. [cm/hr]	1.0	Yes
can_slide_coefficient	Coefficient to determine if snow can slide given irradiance and air temperature. [W/(m^2 C)]	-80	Yes
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	Yes

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.

Accumulated dirt can reduce the energy output of a solar PV system by obstructing the sunlight available for energy conversion. PV energy losses due to module soiling—commonly referred to as “soiling losses”—vary widely by location. The local climate and PV system configuration (such as the system tilt and tracking type) can impact the magnitude of soiling related energy losses.

The pvlib solar simulation model in SolarAnywhere uses the soiling loss model developed and validated by Humboldt State University (HSU). Pvlib leverages SolarAnywhere precipitation and particulate matter data as well as user provided energy site configuration(s) to calculate site-specific soiling loss estimates. Because soiling loss calculations are based on accumulated dirt, the soiling loss model will consider precipitation and particulate matter data for 6 months prior to the start time specified in the simulation request. To learn more about the soiling loss model, refer to the original publication: M. Coello and L. Boyle, “Simple Model For Predicting Time Series Soiling of Photovoltaic Panels,” in IEEE Journal of Photovoltaics. doi: 10.1109/JPHOTOV.2019.2919628”

The input parameters and default values used in the Soiling Loss model are as follows:

Internal parameters	Definition	Default value in pvlib	Can be specified by the user
cleaning_threshold	Amount of rain in an accumulation period needed to clean the PV modules. [mm]	6	Yes
depo_veloc	Deposition or settling velocity of particulates. [m/s]	Particulate Matter 2.5: 0.0009, Particulate Matter 10: 0.004	No
rain_accum_period	Period for accumulating rainfall to check against cleaning_threshold. [hours]	24 (It is recommended that rain_accum_period be between 1 hour and 24 hours.)	Yes

To learn more about soiling loss modeling with SolarAnywhere time-series weather data, see the blog and soiling loss resource page.

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 pvlib solar simulation model in SolarAnywhere 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:

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 (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 pvlib and CprPVForm solar simulation models in SolarAnywhereSolarAnywhere 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.

The simulation request timestamps indicate the start and end period for which the client wishes to return data. Timestamps 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"

Timestamps are all handled as an absolute reference, so if the client wishes to request forecast data, they will need to create a timestamp 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. Timestamps 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.

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.

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.
• PlaneOfArrayIrradianceBackSurface_WattsPerMeterSquared:The irradiance incident on the back surface 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.
• PlaneOfArrayIrradianceFrontSurface_WattsPerMeterSquared:The irradiance incident on the front surface 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.
• SoilingLossesDC_kW:* The modeled DC power output losses in kW due to dirt accumulation on the PV module surface. See the soiling losses definition above for more information on the soiling loss model.
• SoilingLossesDC_Percent* The percentage of total DC power output lost due to dirt accumulation on the PV module surfaces. See the soiling losses definition above for more information on the soiling 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.
• TotalSoilingLosses:* Total DC power output (summed to calendar month and year) lost due to dirt accumulation on the PV module surfaces over the period of measure specified by the request StartTime and EndTime. Units of kW.
• AveragePercentSoilingLosses:* Mean percentage of total DC power output (averaged to calendar month and year) lost due to dirt 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" or SoilingLossModel="HSU" 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.

Simulation results will automatically contain the total calculated AC nameplate rating, DC nameplate rating, PTC rating and CEC rating of the system(s) included in your simulation request. These are defined below:

TotalNameplateDCRating_kW: The maximum rated DC power output of the PV system under industry standard test conditions (STC). STC 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 does not account for the effect of wind speed and module height above ground. Calculated as: PV module quantity x PV module STC nameplate rating.

TotalPtcRating_kW:  The maximum rated DC power output of the PV system under performance test conditions (PTC). PTC are defined as 1,000 W/m2 of solar irradiance, an air mass of 1.5 and an operating cell temperature of 45°C. Additionally, PTC consider an ambient temperature of 20°C and a wind speed of 1 meter per second at 10 meters above ground level. PTC are considered more representative of real-world operating conditions. Calculated as: PV module quantity x PV module PTC nameplate rating.

TotalNameplateACRating_kW: The maximum AC power output of the PV system without the consideration of inefficiencies and system losses. Calculated as: inverter quantity x inverter maximum AC capacity.

TotalCecRating_kW: This is an alternative means of representing the maximum expected AC power output of the PV system. This rating was originally developed for the California Solar Initiative (CSI) Program in order to determine if a PV system qualified for the program’s incentives. However, it is commonly used to present a more realistic AC system rating since it considers inverter efficiency and module PTC rating. Calculated as: PV module quantity x PV module PTC nameplate rating x inverter efficiency.

SolarAnywhere supports the use of the Infinite Sheds bifacial model when using the pvlib power model. In order to model a bifacial PV system, specify Bifacial = “true” when creating your energy site, then specify InfiniteSheds as the BifacialModel in the SimulationOptions. If your PV system has monofacial PV modules, specify BifacialModel as None or remove it from the request completely.

The infinite sheds¹ model is a 2-dimensional model of irradiance on the front and rear surfaces of a PV array. The model assumes that the array comprises of parallel, equally spaced rows (sheds) and calculates irradiance in the middle of a shed which is far from the front and back rows of the array. Sheds are assumed to be long enough that end-of-row effects can be neglected. PV modules can be fixed-tilt or single-axis tracking (with and without backtracking). The ground is assumed to be horizontal and level, and the array is mounted at a fixed height above the ground.

The infinite sheds model accounts for the following effects:

• • Limited view from the row surfaces to the sky due to blocking of the sky by nearby rows.
  • Reduction of irradiance reaching the ground due to shadows cast by rows and due to blocking of the sky by nearby rows.

The model operates in the following steps:

• • 1. Find the fraction of unshaded ground between rows where both direct and diffuse irradiance is received. The model assumes that there is no direct irradiance in the shaded fraction.
    2. Calculate the view factor from the ground to the sky accounting for the parts of the sky that are blocked from view by the array’s rows. The view factor is multiplied by the sky diffuse irradiance to calculate the diffuse irradiance reaching the ground. Sky diffuse irradiance is thus assumed to be isotropic.
    3. Calculate the view factor from the row surface to the ground which determines the fraction of ground-reflected irradiance that reaches the row surface.
    4. Find the fraction of the row surface that is shaded from direct irradiance. Only sky and ground-reflected irradiance reach the shaded fraction of the row surface.
    5. For the front and rear surfaces, apply the incidence angle modifier to the direct irradiance and sum the diffuse sky, diffuse ground, and direct irradiance to compute the plane-of-array (POA) irradiance on each surface.
    6. Apply the bifaciality factor, shade factor and transmission factor to the rear surface POA irradiance and add the result to the front surface POA irradiance to calculate the total POA irradiance on the row.

View factors from the ground to the sky are calculated at points spaced along a one-dimensional axis on the ground, with the origin under the center of a row and the positive direction toward the right. The positive direction is considered to be towards the “front” of the array. Array height differs in this code from the description in [1], where array height is described at the row’s lower edge.

The Perez model is used as the transposition model for POA calculation.

The InfiniteSheds model is influenced by the 2D model published by Marion, et al..

For PV systems that are bifacial, users can access the front and back surface Plane of Array Irradiance (POAI) separately by specifying PlaneOfArrayIrradianceBackSurface_WattsPerMeterSquared and PlaneOfArrayIrradianceFrontSurface_WattsPerMeterSquared respectively in the OutputFields under SimulationOptions. The total POAI for each time step can be accessed using the PlaneOfArrayIrradiance_WattsPerMeterSquared output field and is calculated as the sum of the front and back surface Plane of Array Irradiance for the specific time step.

To learn more about the Bifacial Model, visit the Support Center page here.

¹Mikofski, M., Darawali, R., Hamer, M., Neubert, A., and Newmiller, J. “Bifacial Performance Modeling in Large Arrays”. 2019 IEEE 46th Photovoltaic Specialists Conference (PVSC), 2019, pp. 1282-1287. doi: 10.1109/PVSC40753.2019.8980572.