Terms & Concepts
Creating custom solar simulations involves key inputs that define how the PV system will be modeled to behave in the real world. To make working with the API easier, this section explains some of the more complex topics you might come across.
The Solar Simulations API requires the client to define a PV system. This PV system is made up of modules and inverters that are wired together in specific configurations. The PV system 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 PV system is outputing.
The PV system components will define how the PV simulation model calculates alternating current (AC) power and AC energy from the irradiance and weather data. PV system 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 PV simulation.
The inverter is a component of the PV system. Each inverter is wired to a set of PV modules and converts the DC output of the module into AC power. The PV power model used in the Solar Simulation API requires 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 the inverter model to the necessary input ratings, see the CEC inverter list.
The PV module is a component of the PV system. Each PV module converts incident irradiance under the ambient weather into DC output, which the inverter then converts to AC power. The PV power model used in the Solar Simulation API requires that the client pass information about the number ("Count"), nameplate DC rating ("NameplateDCRating_kW") and performance test conditions AC rating ("PtcRating_kW") of the PV module.
The client can also specify the temperature rating ("PowerTemperatureCoefficient_PercentPerDegreeC") and nominal operating cell temperature ("NominalOperatingCellTemperature_DegreesC") of the module, if desired. If the client leaves these two optional fields blank, the defaults are set to:
For a mapping of the inverter model to the necessary input ratings, see the CEC module list.
The array configuration specifies parameters about the PV system that define how the system is installed and what near-field obstructions may occur. The array configuration inputs are important to the PV simulation model as they help determine what the incident irradiance is on the plane of the PV module array, and can have a significant impact on the PV simulation accuracy.
The PV power model used in the Solar Simulation API requires 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 Solar Simulations API uses 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 tracking rotational limit ("TrackingRotationLimit_Degrees"), the number of rows of modules ("ModuleRowCount") and the relative module row spacing ("RelativeRowSpacing").
For more information about each of these attributes, see the Complete Schema.
PV simulation methods work by converting the available irradiance and weather conditions into an available PV power output. The model used to complete this step of the PV simulation is called the PV power model. There are a number of PV power models that have been developed, including approaches that start with the PV module's response as a single diode, to others that use empirical relationships based on real world testing.
The Solar Simulations API currently supports two PV power models. The first is the Clean Power Research implementation of the PVForm model. This model uses an empirical relationship between the incident irradiance and PV module DC output. DC is then converted into AC power through a non-linear inverter model. To specify this PV power model, indicate PowerModel="CprPVForm" in the Simulation Request.
A second option is an earlier implementation of the PVForm model, called Clean Power Estimator. To specify this PV power model, indicate PowerModel="CleanPowerEstimator" in the Simulation Request.
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, 2015 at 11:00 AM Pacific Standard Time to January 2, 2015 at 12:00 PM Eastern Standard Time, the StartTime would be set to "2015-01-01T11:00:00-08:00" and the EndTime would be set to "2015-01-02T12:00:00-05:00" in the Simulation Request.
Time stamps are all handled as an absolute reference, so if the client wishes to request data forecast into the future, 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.
In the Simulation request, the client will specify their desired irradiance and weather data source. The client needs to specify two aspects of the simulation request.
First, the irradiance and weather data source will specify the solar model used as the source of the data. Release Notes further detail the makeup of the solar model. For example, the client would set the WeatherDataSource="SolarAnywhere3_2" if they wanted to request SolarAnywhere Data Version 3.2 as the source for their PV simulation.
The second aspect is the irradiance and weather data type desired by the client. The data type refers to either time series and forecast data, or long-term average (i.e., Typical GHI Year) data. When using time series and forecast data, the client is requesting a consecutive time period such as 1/1/2015 11:00 AM Pacific Standard Time to 1/2/2015 12:00 PM Eastern Standard Time. For long-term average data, the client is requesting a full year of hourly data that represents the long-term average condition for the desired location.
For more information about the available irradiance and weather data options, see the Complete Schema.
For more details on the irradiance and weather data sources, see Irradiance and Weather Data Terms & Concepts.