André Mermoud

OK, the diffuse renormalization didn't work properly. I have corrected this for the next version 6.08. And I also suppressed the Meteonorm Wind velocities, which appear "by accident" in the Monthly values associated with the site (but not in the houlry values themeselves). PVsyst uses now the Synthetic Generation algorithm of the Meteonorm program, and I was not aware that these values were added by default.

Please see the FAQ "Can I defined a Power feactor in PVsyst?"

The energy E_grid calculated by the PVsyst simulation is the active (or real) energy, expressed in [kWh]. Now the grid manager may require to produce some reactive energy for compensating the unbalances of the other users (expressed in [kVARh]). The Apparent energy is the product U * I expressed in [kVAh]. If the voltage is sinusoidal, the real energy is U * I * cos(phi) [kWh], where phi is the phase shift between current and voltage. The Power Factor is the ratio of the Active energy to the Apparent energy. In the sinusoïdal case, it is cos(phi). The phase shift of inverters is sometimes expressed as Tan(phi), positive for reactive power generation (capacitive) and negative for reactive power absorption (inductive). Therefore we have E_GridApp [kVAh] = E_Grid [kWh] / Cos(Phi) Technically, producing Reactive energy should be programmed in the inverter device. This is fixed for a given time. Now a question arises with the overload conditions. There are 2 possibilities: - either the Pnom specified by the inverter's manufacturer corresponds to an active power. In this case the usual simulation takes correctly the overpower conditions into account. - or the Pnom specified by the inverter's manufacturer is an apparent power. In this case the power limitation should occur for PnomApp [kVA] = Pnom [kW] / cosPhi. Therefore the simulation has to adjust the Pnom specified in the inverter's definition, by dividing it by the required CosPhi. NB: the limitation on the Apparent power is sometimes specified as a current limitation. At a given time this depends on the output voltage, i.e. the grid voltage. However during the simulation the grid voltage evolution is not known ; therefore the power limitation cannot be applied by using this current criteria. In PVsyst, since Version 6.11 the Power factor may be specified by pressing the "Miscellaneous" button, either as Cos(phi) or as Tan(phi). It may also be specified in monthly values. This will act on the inverter Pnom limitation if specified as Apparent power limit, and the apparent energy is mentioned on the loss diagram.

This was indeed a bug with the calculation "According to modules". I have fixed this problem for the next version 5.68, to be released by the end of June.

For the first question, manufacturers define Pnom = "Nominal power", valid for any temperature conditions, and Pmax = "Maximum power", attainable in some conditions (not always well defined, usually an operating period). To my understanding and after discussion with some manufacturers, this seems to correspond to a device internal temperature limitation: Pnom and PMax according to temperature Now for the Array temperature increase when power decreases: this is evident from the energy balance used for the evaluation of the module's temperature: Tarray - Tamb = ( Alpha · Ginc · (1 - Effic)) / U where Alpha = absorption coeff., Ginc = incident irradiance and Effic = module efficiency. However with Alpha = 0.9, Ginc = 1000 W/m2, U = 29 W/m²K, the cell temperature increase is 26.4°C for effic = 15% and 31°C for effic = 0 (open circuit). Yes the array temperature is slightly higher, but at this time the array doesn't have to produce anything !!! (or works at reduced power).

The "partition in module chains" doesn't always provide an accurate calculation, it is just an approximation for estimating an upper limit of the electrical loss. In such complex layouts it is indeed not well suited. In this particular case you should perhaps define 3 (or 4) rectangles vertically. The accurate calculation for such a complex case can be done in the version 6, option "Module Layout", where you can specify the position of each module of each chain.

The meteonorm program (included in PVsyst) holds measured meteo data (10-30 years averages) for about 1'200 sites in the world, named "Stations". But it allows also to get meteo data for any location on the earth, either by interpolation (between the 3 nearest stations) or on the basis of satellite data. The "native" database of PVsyst is based on these 1'200 Meteonorm "stations". However in the PVsyst "Geographical sites" option, you can choose any location on a google map, and get meteo data for this location either from Meteonorm or from the NASA-SSE database. Now you have tools in the software for easily importing data from many well-known irradiation databases (Meteonorm, Satellight, PVGIS, Nasa-SSE, Soda-Helioclim, Retscreen, TMY3 or SolarAnywhere(SUNY) in the US, EPW in Canada, etc). For this, please open "Tools" / "Import Meteo Data", and press F1 for more details, a description of each source and the procedure for importing them. For California, you can probably find a TMY3 file near to your location, or SolarAnywhere satellite data for your exact location and for about the 10 past years.

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.