--- title: "PV simulators comparison: Solar data and system configuration" slug: "comparison-solar-data-and-system-config" description: "Compare PV simulators on data inputs, scene modeling, and simulation variables to enhance the accuracy of your PV yield simulations." updated: 2026-08-11T06:44:48Z published: 2026-08-11T06:44:48Z canonical: "kb.solargis.com/comparison-solar-data-and-system-config" --- > ## Documentation Index > Fetch the complete documentation index at: https://kb.solargis.com/llms.txt > Use this file to discover all available pages before exploring further. # PV simulators comparison: Solar data and system configuration **In this document** This article compares how the PV simulators handle three foundations of every yield simulation: the input data they consume, the way they represent the PV scene, and the hardware specifications they use. ### Overview The accuracy of any PV yield simulation depends first on the quality of its inputs, the fidelity of its scene representation, and the precision of its hardware specifications. Before any optical or electrical calculation runs, the simulator needs solar radiation and meteorological data, supporting parameters such as albedo, soiling, and horizon, hardware specifications, and a geometric model of the PV power plant and its surroundings. These inputs shape every result that follows, and differences between simulators at this stage propagate through every subsequent calculation. This article covers three topics from the simulator comparison series: - [Data inputs](/v1/docs/comparison-solar-data-and-system-config#data-inputs1): where solar, meteorological, and environmental data come from, and at what temporal resolution - [Scene modeling](/v1/docs/comparison-solar-data-and-system-config#scene-modelling): how the PV power plant and surrounding objects are represented - [Hardware specification](/v1/docs/comparison-solar-data-and-system-config#simulation-chain-and-variables1): where the parameters describing PV modules, inverters, and other components come from For the test sites, system configurations, versions of the tested software, and statistical methodology shared across the series, see [Setup and test methodology](/v1/docs/comparison-setup-and-test-methodology). ### Data inputs Two characteristics distinguish how simulators source their data: whether they integrate a solar and meteorological database, and whether they include internal models for supporting parameters such as soiling and snow. The simulators also require different input parameters and different temporal resolutions. #### Integrated database and imported data An integrated database simplifies operation, because the user does not have to source, format, and import data. Imported data widens the choice of data source, which allows technical and cost optimization but also admits low-quality inputs. Solargis Evaluate and Solargis Prospect use the Solargis database as their internal source of solar, climate, and environmental parameters. The data product depends on the use case: Solargis Evaluate runs either full historical time series or typical meteorological year (TMY) P50 files, while Solargis Prospect uses twelve daily profiles representing average conditions in each calendar month. pvlib, PVsyst, SAM, and SolarFarmer rely on data from external providers. SAM connects directly to the National Solar Radiation Database (NSRDB). SolarFarmer integrates with the Solcast API and PVGIS TMY service. pvlib provides IO tools that retrieve and parse data from a wide range of services and file formats, including CAMS, NSRDB, PVGIS, SolarAnywhere, Solargis, Solcast, Meteonorm, and NASA POWER, as well as several ground measurement networks. PVsyst imports through a set of predefined data formats. #### Temporal resolution The temporal resolution of the input data determines how well [short-term variability](/v1/docs/solar-resource-variability#very-shortterm-to-shortterm-variability-1minute-to-60minute) and transient effects such as fast-moving clouds and tracker position changes are captured, because hourly resolution smooths them away. This smoothing may lead to inaccuracies further in the simulation chain, such as in [inverter clipping evaluation](/v1/docs/the-importance-of-sub-hourly-input-data-in-pv-systems-simulation-using-satellite-based-solar-model-data), regardless of modeling methods. Solargis Evaluate runs at 15-minute resolution for both time series and TMY, and at 1-minute resolution for TMY. Solargis Prospect uses 15-minute resolution daily profiles. pvlib, PVsyst, SAM, and SolarFarmer accept any regular hourly or sub-hourly data. #### Primary solar and meteorological parameters All simulators consume global horizontal irradiance (GHI) and air temperature as core inputs. Beyond that, the parameter sets differ. SolarFarmer additionally accepts direct normal irradiance (DNI), diffuse horizontal irradiance (DIF), global tilted irradiance (GTI), precipitable water (PWAT), atmospheric pressure, wind speed, and relative humidity. PVsyst requires GHI and air temperature and treats DIF, DNI, GTI, wind speed, snow depth, and a number of atmospheric parameters as optional. SAM accepts irradiance as two of the three main radiation components (GHI, DNI, DIF), or as measured GTI. Solargis Evaluate and Solargis Prospect supply all required input parameters automatically from their integrated database. #### Soiling, snow, and albedo The treatment of soiling, snow, and albedo data inputs is where the differences between simulators are most pronounced – the differences are summarized in Table 1. | Parameter | Solargis Evaluate | Solargis Prospect | pvlib | PVsyst | SAM | SolarFarmer | | --- | --- | --- | --- | --- | --- | --- | | **Soiling** | Monthly long-term average (LTA) from internal Solargis soiling model, or manual input override | Manual input with defaults | Monthly LTA, or built-in HSU/Kimber models | Monthly LTA, manual input | Monthly LTA, manual input | Yearly or monthly LTA, manual input | | **Snow** | Monthly LTA from Solargis snow model or manual override | Manual input with defaults | Monthly LTA, or built-in Marion/Townsend models | Monthly LTA, manual input | Internal Marion model | Not modeled separately; typically included as part of the soiling factor | | **Albedo** | Monthly LTA from internal Solargis database, editable | Monthly LTA from internal Solargis database | Yearly, monthly LTA, or time series, manual input | Monthly LTA, manual input (separate value for bifacial) | Monthly LTA, manual input | Yearly, monthly LTA, or daily time series, manual input | ***Table 1****: Soiling, snow, and albedo parameters comparison per simulator.*
Data inputs - How does Solargis Evaluate compare
 #### Horizon data The far horizon determines how much distant terrain blocks direct radiation. The simulators source it differently. - **Solargis Evaluate and Solargis Prospect** supply the horizon line from an internal database and allow manual editing. In Solargis Evaluate, the horizon can be defined per segment within the designed power plant. - **PVsyst** takes the horizon from its own internal file, from PVGIS, from Meteonorm, or from manual definition. - **SAM** has no dedicated horizon editor. Horizon shading is handled as part of object shading, defined independently for each of up to four subarrays through imported files (PVsyst, SolarPathFinder, SunEye), shading tables, or the 3D shading scene editor. - **SolarFarmer** imports horizon files from SolarFarmer, Meteonorm, Solargis, or PVsyst, or generates the horizon from downloaded terrain. - **pvlib** accepts imported or user-defined horizon data, applied to adjust DNI and plane-of-array irradiance. ### Scene modeling The scene represents the physical layout of the PV power plant and its surroundings. Scene fidelity determines how accurately the simulator can compute near shading, mutual shading between arrays, and reflected radiation contributions. A terrain model forms the base layer of the scene. Solargis Evaluate offers a choice of three: Copernicus Digital Surface Model (DSM) and Shuttle Radar Topography Mission (SRTM) GL1, both at approximately 30 m resolution, and the Solargis Digital Elevation Model (DEM) at approximately 90 m. Solargis Prospect uses the Solargis DEM automatically. PVsyst retrieves terrain on demand from the gpxz.io elevation service, while pvlib and SolarFarmer require the user to define or import it. SAM does not model terrain elevation at all. Table 2 summarizes the scene editing capabilities of each simulator. #### Available objects in the scene The objects available in the scene editor differ by simulator. Solargis Evaluate supports shading objects, shading lines, restricted areas, inverters, transformers, the high voltage (HV) transformer station, and the grid connection point. PVsyst supports 2D and 3D shapes, building objects, ground objects, and arrays (fixed and tracking). SAM supports active area, box, cylinder, roof, and tree objects. SolarFarmer supports box, cylinder, wind turbine, tree, and building objects through its object editor, together with arrays, regions, and restricted regions. #### Visual energy system editor The [Energy System Designer](/v1/docs/energy-system-configurator-introduction) in Solargis Evaluate renders a 3D scene with topography and overlaid satellite imagery, which helps the user orient the design against real site features. SolarFarmer offers a comparable editor at lower fidelity, rendering a smaller area without integrated terrain. PVsyst and SAM provide a simplified editor built on a blank x-y-z space. Solargis Prospect and pvlib have no visual editor: both define array geometry parametrically through row spacing, tilt, azimuth, and tracker angles. Solargis Prospect applies this through built-in calculations on a single reference point with horizon, while pvlib expects the user to supply the geometry and the shading calculation programmatically. | Scene capability | Solargis Evaluate | Solargis Prospect | pvlib | PVsyst | SAM | SolarFarmer | | --- | --- | --- | --- | --- | --- | --- | | Visual editor | Yes | No | No | Yes | Yes | Yes | | Layout import | KML | N/A | N/A | DAE, 3DS, PVC, H2P | S3D | CSV, SHP, KML, KMZ, PVC | | Built-in terrain | Copernicus DSM (default), SRTM GL1, Solargis DEM | Solargis DEM | No | No (gpxz.io on-demand integration) | N/A | No | | Terrain import | Tiles (x-y-z), GeoTIFF | N/A | Can be manually defined | CSV, GeoTIFF, Bing/Azure maps, gpxz.io elevation | N/A | Multiple formats | | Scene export | KML, PVC, DAE, DWG, DXF (indirect) | N/A | N/A | SHD | S3D | PVsyst, Google Earth, SHP, PVC | ***Table 2****: Scene editing capabilities per simulator.*
Scene modeling - How does Solargis Evaluate compare
 ### Hardware specification Hardware specifications (most importantly PV modules and inverters but also transformers, cables, and trackers) are an important factor in the accuracy of the PV yield simulation. The specified hardware parameters define the response of the simulated components and the losses they cause in the simulation chain. If the specifications are inaccurate, the losses can swing several percentage points in either direction. The compared simulators obtain these parameters by three routes. Several simulators support more than one route. - **Curated catalog.** Solargis Evaluate reads verified module and inverter specifications from the Solargis PV Components Catalog (PVCC), maintained centrally by Solargis. - **Bundled library.** SAM includes component libraries built from California Energy Commission (CEC) and Sandia National Laboratories datasets. PVsyst includes its own component database. Solargis Prospect uses a small set of predefined component specifications, fixed by design to keep configuration fast. - **User-supplied specification.** SolarFarmer imports manufacturer-authored PAN and OND files from PVsyst, or takes values entered by hand. PVsyst accepts PAN and OND files alongside its database. pvlib takes the parameters as a data structure assembled by the user, populated from the same CEC and Sandia datasets that SAM includes or from any other source. The routes differ in where responsibility for parameter accuracy lies. A curated catalog or a bundled library assigns it to the software vendor, and the user selects a verified component from a list. File import shifts it to whoever authored the PAN or OND file. Manual entry places it entirely on the user.
Hardware specification - How does Solargis Evaluate compare
 ### Impact on downstream simulation Data, scene, and hardware quality bound the accuracy of every subsequent calculation: - Hourly input data smooths away transient effects that no downstream model can recover, - A scene that cannot represent obstacles, mounting structures, or terrain limits the near shading calculation regardless of how rigorous the shading algorithm is, - A simulator with no internal database of hardware specifications and no model for soiling, snow, or horizon depends entirely on the factors the user supplies. The next article in this series, [Irradiance modeling](/v1/docs/comparison-irradiance-modeling), covers how each simulator converts these inputs and scene into plane-of-array irradiance on each cell, including the near shading calculation that builds directly on the scene representation discussed above. ### Further reading - "[Argus PV simulation chain](/v1/docs/argus-pv-simulation-chain)": Solargis - "[Argus PV simulator inputs](/v1/docs/argus-simulation-inputs-overview)": Solargis - "[Solar, meteorological, and environmental data](/v1/docs/solar-meteorological-and-environmental-data)": Solargis - "[Time series and TMY data](/v1/docs/time-series-and-tmy-data)": Solargis - "[Supported temporal resolutions](/v1/docs/5-minute-15-minute-and-60-minute-data)": Solargis - "[Satellite-based albedo data](/v1/docs/satellite-based-albedo-data)": Solargis - "[Soiling loss model](/v1/docs/soiling-losses)": Solargis - "[Snow loss model](/v1/docs/snow-losses)": Solargis - ["Terrain models"](/v1/docs/terrain-models): Solargis