André Mermoud

There is often a unit's confusion with the quantity Yr, which may be understood : - either as the incident energy (with units [kWh/m² / day]) - or as the ideal array Yield according to Pnom (expressed as [kWh / kWp / day]). This numerical identity results of the STC definition: one kWh/m² of irradiance should produce one kWh/kWp of electricity. The confusion comes from the fact that the kWh are not the same: - in the former case [kWh/m² / day], the kWh represent incident irradiance energy (light flux) - in the latter case [kWh / kWp / day], the kWh mean produced electrical energy !!!

Yes, when the shade takes all cells of a string in the same way (as with protrait mounting in a rows arrangement), there is no electrical mismatch loss, and the "Linear" calculation (irradiance deficit) is perfectly suited. The calculation of the "Module layout" part is only applicable for crystalline modules, i.e. with about square cells.

When you have imported your logo using (in Version 6) : main menu "Preferences" / "User Info and Logo", you can get it on the printed forms: - By default for any "new" print or calculation version: main menu "Preferences" / "User Info and Logo" - For a given form or report: in the printer dialog, button "Option" you can still decide if you want the logo or not. For simulations from version 5, this may be unchecked by default.

This is a complex problem indeed. With the PVGIS old monthly values for example (before 2018), or any ground-measured data, the horizon loss of irradiance is already included in the meteo data. This is very difficult to manage because: - the horizon line is very sensitive to the exact location: the horizon at the exact sensor position may be very different of the horizon seen by the PV system at some hundreds of meters. - if applied to monthly values, the synthetic generation doesn't "know" the horizon, and will generate values with beam component below the horizon. Which will be incorrect during the simulation of course. Therefore in any case (except with real on-site measurements), the meteo data should ideally be horizon-free and the horizon effect should be computed within PVsyst, using the effective horizon line of the site. This is the case, namely in the Meteonorm V7.1 or NASA-SSE data provided within PVsyst. But other sources (like for example PVGIS, monthly values) deliver indeed meteo data already corrected for the horizon of the site. There is no simple way for evaluating or avoiding the horizon loss in the original meteo data. With monthly values, we could generate a full year of hourly values, perform a synthetic generation, evaluate the loss (on beam hourly values) due to the pre-specified horizon of the site, and then add these losses to the monthly original values for a re-generation of hourly file. This file will have better "free horizon" values on which we can apply the real horizon of the PV system during the simulation. With hourly measured values, we can use the data "as such" for the simulation, but without defining an horizon line. If we really want to evaluate the loss due to horizon, we should reconstruct the supposed beam component below the horizon line. We have now models for doing this with some confidence (probabilistic continuity of the weather). We have tested these methods, and they can give acceptable results. But sorry, I don't know any public program doing this, and I did not yet implement this special case in PVsyst. Especially for PVGIS, this is not possible directly within PVsyst as the horizon line profile is given only as a plot in PDF, which cannot be read automatically in a numeric way by PVsyst. But you can follow the procedure proposed above manually.

In PVsyst, the north orientation in southern hemisphere corresponds to an azimuth of 0°. Please see our FAQ How is defined the plane orientation ?

I never heard about such a problem. This calculation is immediate (fraction of second for 20 random generations), and you can ask to add statistics as much times as desired.

In version 5: In the main menu "Status and Activation", you have a button for the import of your logo. The file should be in *.BMP format. In version 6: Main menu "Preferences" / "User Info and Logo". The file may be in BMP, PNG or JPeg formats. The optimal size is 64 x 128 pixels (the limit on the printed report).

You probably did not use the right procedure, and got the data directly from the Meteonorm 6.1 database. You should: - Define your own site in "Geographical Sites" and save it under a chosen filename (a *.SIT file) - Open the button "Synthetic Hourly Data Generation" and choose the file you have created (normally appearing by default). - Create your Synthetic file by clicking the "Execute generation" button. This tool cannot create wind data !!!

To my mind, this is not really possible, because this is related to many parameters that you can choose as you like. The main uncertainties are: - The meteo input values (RMS of the order of 4-5% from year to year, discrepanciesw > 10% between differnt sources of data, climate evolution, etc), - The exact behaviour of the PV moudles by respect to their specifications (in the "Module quality loss" and LID parameters) - You parameters like soiling losses (very sit-dependent) - etc. However a study has been performed on a great number of PVsyst sudies during several years by different engineers: ANALYSIS OF HISTORICAL ENERGY ESTIMATES FOR 235 PV SYSTEMS INSTALLED FROM 2007 TO 2011 IN THE USA Joe Philip, Anastasios Golnas SunEdison 27th European Photovoltaic Solar Energy Conference and Exhibition, Frankfurt, September 2013.

I don't understand well what you mean, and why you need a number of hours. And which threshold we should put for the beam component. For which use ???

I think I have defined these functions. You have a button "Set modules" and "Set all modules". And "Match this table" / "Match all tables". When you resize a table it asks for resizing all identical tables. And when attributing the strings "Distribute one Table" and "Distribute all". Perhaps I have forgotten a parameter ?

When defining an amorphous modules, the parameters (specific to the PVsyst model) are not easy to determine. The best way is to let PVsyst choose all parameters at their default value (Rshunt, Rserie, d2muTau). The temperature coefficient muPmpp should be specified according to the datasheets (negative value). Please pass and check the default checkboxes several times until stabilization, as these parameters are highly interdependent (especially d2MuTau <=> reserie). This is a delicate choice. If you have real difficulties you can send me the datasheets and I will analyse the situation.

You are right. This is explained in detail in the FAQ Why sometimes the oberload losses increase significantly without reason ?

And in the version 6, these limit angles are defined within the project (button "Albedo - Settings"). In the version 6, you have a tool for analysing the spread of orientations in Helios3D constructions, and the program will choose the orientation average as calculation basis.

Sorry, in the present time this configuration cannot be calculated by PVsyst. Although it is authorized by the SolarEdge architecture, PVsyst cannot compute configurations with modules of a same string in different orientations. I will perhaps develop this in a future version.

Not in the present time. Using this in the simulation would only be possible outdoor (otherwise we have to estimate the room temperature). It would imply 2 additional parameters : - The internal temperature increase as function of the instantaneous power - The PMax power derate as function of the internal inverter temperature. Did you ever see these parameters in the inverter datasheets ?

In the version 6, the models have in principle not been significantly changed. However several modifications of default values may explain significant differences in the final results: Defaults values Transposition model In the previous versions (up to Version 5), PVsyst proposed the Hay transposition model as default as it was judged more "robust" than the Perez model. In a recent study, Pierre Ineichen found that the Perez model is giving slightly better results (in terms of RMSD of hourly values) in any case (see "Global irradiance on tilted and oriented planes: model validations", P. Ineichen, 2011). Therefore the Perez model is proposed as default in the version 6. The Perez model gives yearly values significantly higher than the Hay model, of the order of 0% to +2% depending on the climate and the plane tilt. PV module: Rserie parameter Up to Version 5, the default Rserie value was chosen in order to obtain a gamma value (Diode ideality factor) of 1.30 for mono- and 1.35 for poly-crystalline modules, according to our first measurements on some modules. This leads to underestimated low-light performances. But: - By comparison with the Sandia model (obtained by outdoor measurements with dozens of modules), we observed that Gamma should rather be of the order of 1.1 to 1.15. - The low-light data, measured indoor (flash-test) by different independent laboratories, are compatible with still lower Gamma values of the order of 0.9 to 1. We still do not understand quite well this discrepancy between indoor and outdoor measurements. However in the version 6, we fixed the default Gamma value to 1.1, which significantly decreases the irradiance losses of previous simulation (by 2-3% depending on modules and climate). This will affect all modules for which the Rseries was not specified in the database by the manufacturers. When manufacturers propose enhanced Rseries resistances, we require that they provide independent low-light measurements for assessing the proposed values. See What explains the difference of yield between different modules? The default gamma value is specified in the Hidden parameters, topic "PV modules". You can change it even in the version 5 if desired. Module quality and Mismatch losses In the previous versions the default "Module quality loss" was chosen as the medium value between the lower tolerance and 0. In the version 6, the database also mentions the higher tolerance limit for modules. The default "Module quality loss" is now defined as the quarter between the lower and the higher tolerance. This doesn't change anything for symmetrically defined tolerances, but will provide a negative loss factor (gain) for positive sorted modules (for example -0.75 for a -0/+3% module). The mismatch loss parameter was previously proposed by default as 2%, corresponding to PV module samples with an Isc dispersion of the order of 5%. Nowadays the PV modules are specified with narrower tolerance limits, and the delivered samples for a given project are often with 2-3% dispersion. Therefore we diminished this mismatch default loss to 1%. Simulation differences Losses with derate factors (Module quality, Mismatch, Soiling) In the version 5, some loss parameters (derate factors) were specified by respect to the STC power, when the result was evaluated as a percentage of the "previous" energy. This gave a discrepancy in the final results, which were higher (by about 10%] than their parameter. In the version 6 the derate loss factors are specified by respect to the "actual" energy and the results are identical to the parameters. Array Energy calculation In the simulations of the version 5, the electrical behaviour calculation was done globally for the whole sub-array. Therefore if you had, for example, 9 strings on 2 MPPT inputs, the calculation was equivalent to 2 inputs of 4 1/2 strings. In the version 6 the calculation is performed for each inverter separately (one with 4 and one with 5 strings). This may induce difference in case of overpower conditions.

Wiring (ohmic) losses: Remember that the ohmic loss goes with the square of the current, therefore of the Power ! The basic loss parameter is the resistance of the wiring: Pwirloss = Rw * I² [W or kW] However in PVsyst the loss parameter may also be expressed as a loss percentage when running at STC. Therefore: as an example, if we admit a system of 10 kW with a loss of 2% at STC (i.e. under 1000 W/m²): - Under 1000 W/m2, the loss will be R * Istc² = 20 W (2 % of 10'000 W) - Under 500 W/m2, the current will be half, the loss will be R * (Istc / 2)² = R * Istc/4 = 5 W, i.e. 1% of 5000 W In other words, with 2% loss at STC, when running at half the power (under 500 W/m²), the relative loss will be 1% and under 250 W/m2 it will be 0.5%. The loss has to be evaluated at each simulation time step according to the actual power, and the cumulated loss over the year will be of the order of 60% of the specified value in % of STC (depending on climate). Transfo iron loss: The Iron loss is a permanent loss (as soon as the transformer is connected to the grid). It is a 24/24H loss (or eventually about half of this time if you switch OFF the line connexion by night). The iron loss only depends on the grid voltage, therefore it is constant. Only the Ohmic part of the transfo loss is related to the yield, and obeys the rule described above. Overload loss: During the sizing time, the overload estimation results of a very quick and coarse calculation, using the histogram representation of the output of the array along the year. This histogram involves global parameters like an average array temperatures for each power class, and doesn't take into account the inverter's Pnom dependency on the temperature, as well as all array losses. Moreover, it is based on the monthly irradiation values of the project's site, which may not be the same as the Meteo file's values. Therefore, the loss estimation of this sizing tool is not quite accurate, and is often overestimated. The referennce ("exact") value can only be obtained with the detailed hourly simulation. This gives usually lower overload losses, as all the the losses of the array are correctly taken into account. Unavailability: The parameters define an unavailability duration. The unavailabîlity periods (up to 5) may be specified explicitly, or you can ask for a random distribution. Now a failure in winter or in summer, or by clear/covered day, of by night/day, will not have the same consequences on the production of course. Therefore the energy loss is not equal to specified duration. In the present time, it is not possible in PVsyst to specify an unavailability loss with a pre-defined annual value.

You have defined an external transformer. For such a device you have 2 kinds of losses: - Ohmic-like losses: these are proportionnal to the square of the current (or the power as the voltage is constant). - Iron loss: this is proportionnal to the grid voltage, therefore constant. This loss remains of course during thre night. Now in the simulation you have the opportunity of disconnecting the transformer from the grid during not-operating time. Therefore you can chek whether a HV switch would be profitable, i.e. if its price will be compensated by the saved energy price.

When the PV power exceeds the DC power Pnom(dc) corresponding to the inverter Pnom(ac) value, the inverter has to displace the operating point along the P/V curve of the array, in order to just draw the necessary power. This displacement is usually towards higher voltages. The power loss is (Pmpp - Pnom(dc)) for this hour. Overload, usual conditions Now if the voltage corresponding to this Pnom(dc) is over the VmppMax of the inverter, there is no possible operating point with both conditions [Pnom(dc)] and [Vnom(dc) < VmppMax] : the inverter has to stop ! When you come to this situation, the solution is to diminish the number of PV modules in series. Overload with high voltage operating point NB: this behavior arises when the hypothesis of PVsyst are met, i.e. the inverter really stops working above the VmppMax value. This is not necessarily the case in the reality. You should ask the manufacturer for identifying the exact behavior of his inverter. In some cases the real VmppMax is higher than the value specified on the datasheet (we have a case where the specified VmppMax is 800V, and the cut happens at 904V).

In the results panel you have a button for viewing graphs in hourly values. But during the simulation, you can also create a CSV file with a choice among any variable involved in the simulation. This file may then be analysed in a spreadsheet like EXCEL. For this, just before performing the simulation, you have a button "Output File".

The performance ratio is described in the help "Project design > Results > Normalised performance index". As defined namely by the European Communities (JRC/Ispra), in the norm IEC EN 61724, it is computed by PR = E_Grid / (GlobInc * Pnom) where: - E_Grid = the energy delivered to the grid [kWh], - GlobInc = Irradiation in the plane of array [kWh/m2] - Pnom = Array nominal power at STC (nameplate value) [kWp] The product (GlobInc * Pnom) is numerically equivalent to the Energy which would be produced if the system was always running with its nominal efficiency as defined by the nameplate nominal power [kWh]. NB: The PR includes all the array losses mentioned on the Loss diagram (Shadings, IAM, Soiling, PV conversion, mismatch, wiring resistance, etc) and the system losses (inverter efficiency and AC losses in grid-connected, or storage/battery/unused losses in stand-alone, etc). As it is referenced to the Incident irradiance, it is not dependent (or marginally) on the meteo data, location, plane orientation, As it is referenced to the Nominal power, it is not dependent on the module efficiency. Unlike the "Specific energy production" indicator, expressed in [kWh/kWp/year], the PR is related to the system quality, and allows the comparison between installations in different locations and orientations. It is often used as Performance Warranty basis. NB: if you take the values from the arrow-loss diagram, the GlobInc value should be taken just after the transposition (i.e. irradiance losses are included in the PR). The results may be slightly different, as here the Nominal STC Power is referred to the efficiency at MPP calculated by the model (not the nameplate value used for the "official" definition), which may be different. Self-consumption and storage The PR is an indicator of the availability of solar energy for final uses. Therefore, when a part of the energy is used internally (E_Solar), this should obviously be included in the PR evaluation. With systems including a storage, the storing losses (battery charge/discharge inefficiency, DC-AC and AC-DC conversion devices) should also be included in the PR. Therefore in the above formula, the E_Grid should be replaced by E_Grid + E_Solar : PR = (E_Grid + E_Solar) / (GlobInc * PnomPV) Weather-corrected PR For short time analysis (commissioning, one-week tests), a NREL paper proposes a "Weather-corrected Performance ratio". It has been included in the norm IEC 61724-1 as well. The objective is to get rid of the seasonal variations of the PR, mainly due to the varying array temperature. Other contributions varying along the year, like irradiance level, seasonal shadings, varying soiling, etc. are not taken into account in this approach. The proposition is to define an average array temperature, which is an average over all operating hours in the year, weighted by the incident irradiance GlobInc: TArrayAver = Σ hours (GlobInc * TArray) / Σ hours (GlobInc) Then for a specified period, the PR (corr) is defined by the following equation: PR (corr) = E_Grid / ( PNomPV * Σ hours ( GlobInc / GRef * (1 + muPmpp * (Tarray - TArrayAver) ) ) Where : - GlobInc = incident irradiance in hourly values [W/m²] - GRef = 1000 W/m² - muPmpp = Pmpp temperature coefficient of the PV module [%/°C] - TArray = Array (cell) temperature of this hour [°C] - TArrayAver = Array temperature average over the whole year, weighted by GlobInc [°C] In PVsyst the weather-corrected result variable is named PRTemp. You can get it on the report by using "Settings > Report preferences" in the Report editing menu. PR for bifacial systems The definition of the performance ratio should be something like a standard, defined by an official instance, and accepted by everybody. Now I have not yet seen any reference which would define a performance ratio for bi-facial systems. Therefore PVsyst cannot propose any specific value in the present time. The value provided presently with the PVsyst results uses the definition of the Monofacial systems, so that the bi-facial gain comes as an increase of this ratio. NB: The main objective of the PR is to find an indicator for comparing real and simulated data, therefore which may easily be evaluated using simple (and "primary") measured data. However neither the rear side irradiance, nor the part of the bifacial gain is available in usual measurements.

First, please carefully check on you report whether all parameters are identical. Compare also the Loss diagrams. If produced by different versions, you can look for eventual modifications on the historical evolution of the software in the help "Overview > Historical evolution of the software", or on our site http://www.pvsyst.com, "Software / Software development". Now if you start from Meteo data in monthly values, the synthetic hourly data file is constructed using a stochastic process: with 2 different executions you will have completely different years (sequences of days and or hours in a day). This may lead usually to discrepancies of the order 0.5 to 1% in the yearly result. These are indeed unavoidable uncertainties due to the stochastic models used. Therefore if you want to perform a quite identical simulations as a colleague, you have to share the exact hourly meteo file used (*.MET).

PVsyst is not able to give definitive answers when comparing the yield of 2 different modules of same technology. A detailed analysis of the parameters has to be performed for such an assessment. Let's limit this analysis to Crystalline modules (mono or poly). The yield (specific energy production, or Performance Ratio) depends on the STC values, but also on 2 additional parameters Rserie and Rshunt (and also the behaviour of the Rshunt value according to irradiance, i.e. Rsh(0) and Rsh(exp)). These parameters are not mentioned in the Standards and in the usual specifications, but they have a great influence on the Low-light performance, and therefore on the annual yield. In absence of further information, these values are set at default values in PVsyst. If Rshunt can be measured (which is very difficult and unreliable for crystalline technology, when using flash-test I/V curve data), it may be specified. But manipulating the defaults for Rshunt irradiance evolution is not advised, as these values seem to reflect a rather "stable" behaviour. The main effect on the low-light behaviour of the model is the Rserie value, which is not directly measurable (see I can't specify my measured Rserie). When not available, PVsyst chooses a default value which corresponds to a pre-defined Gamma value (diode ideality factor) when solving the one-diode model equations. According to my early outdoor measurements on some modules, this value is presently set to Gamma=1.35 for poly and 1.30 for mono, which leads to poor low-light efficiency performances. After comparisons of the one-diode model with the US Sandia model (based on outdoor measurements) on several modules, I discovered recently that this value should be reduced to about Gamma = 1.10 to 1.15. This gives relative low-light efficiencies (by respect to STC) between -0.5% to 0% under 800 and 600 W/m2, and therefore an increased annual yield (about 2% to 3% higher than the previous case, depending on climate). Now when analysing Low-light efficiency data provided by the manufacturers (measured with flash-tests by 3rd-party institutes ), it appears that these efficiencies are still higher, usually around +0.1 to +0.4% for 800 and 600 W/m2 by respect to STC. This discrepancy between models established on outdoor and indoor measurements are not well understood. They may be partially attributed to the fact that the flash-test uses full beam component, when the outdoor have a part of diffuse component, depending on the irradiance and suffering of IAM effect. Therefore in the PVsyst database: - either the Rserie/Rshunts are not specified, and established to Default values (i.e. checkbox "default" checked). This gives under-estimated performances in the present version 5, but will be improved in the future version 6, by requiring Gamma values = 1.10 and 1.15. NB: These modified values may already be defined in the version 5 in the "Hidden parameters". - or these parameters are specified by the manufacturers. In this case we don't accept Gamma values below 1.10, unless the manufacturer can provide an assessment using Low-light efficiencies, measured by an independent institute. Other parameters may give deviations between modules: - The "Module quality loss" parameter takes half the lower tolerance as default value. This will induce a difference of 1.5% between modules with +/-3% tolerance, and positive-sorted (-0/+5%) modules. - Some modules are defined with STC values Imp*Vmp higher than the nameplate specification (for taking positive-sorting into account). The simulation will use the Imp*Vmp for calculation, and the PNom for reference, resulting in overestimated indicators like Specific production or Performance Ratio.

We update the database using the requests of the manufacturers, and publish it with each new issue of PVsyst (about every 1-2 months). We can't of course follow all the new products of all manufacturers in the world. Therefore, please ask your provider/manufacturer to take contact with us (support@pvsyst.com), for updating the database. The database of PVsyst holds now (in 2021) about 19'600 PV modules and 5’800 inverters. Nevertheless you can easily create your own components by yourself. The easiest way is to choose a similar existing device in the database, modify its parameters according to the manufacturer's datasheets, and save it under a new name, therefore creating a new file in your database. For that, you have a tutorial on youtube , / Component database NB: We cannot give any warranty on the database. When using a component in the reality, you are advised to always check the component's parameters with recent datasheets . The values are normally specified by the manufacturers, but they may let some errors that we may not detect. On the other hand, the datasheets may be modified by the manufacturers, without notice.