André Mermoud

The diffuse (and albedo) loss evaluation is not straightforward with tracking systems. Calculation up to version 6.08 This was indeed a weakness of PVsyst in the versions before V6.09: the diffuse loss for tracking systems was not computed correctly. For a fixed plane, the Shading factor on diffuse is computed as an integral of the actual shading factor over all space directions. This calculation is a characteristics of the PV system geometry only, it doesn't depend on the sun's position nor the location, so that the shading factor is constant over the year. For tracking systems, we applied the same method, using the usual Shading factor table calculated for different positions of the sun. But in this table the tracker orientation is adjusted for each sun's position ! I was not aware of that problem when developing the diffuse treatment for tracking. Calculation from version 6.10 The right calculation implies computing the whole shading table for each tracker position, and evaluate the diffuse integral over each of these tables (in practice: evaluate the shading factor for some chosen tracker's orientations, and interpolate the shading factor at the simulation time). This was not feasible with the "standard" calculation" due to the significant time for the elaboration of the shading table. Therefore we developed an approximation, which should be quite acceptable in most cases (especially for big systems). The program chooses one significant tracker in the middle of the system, and evaluates the shading factor table for this element only, using the neighbor trackers, but neglecting other eventual shading sources. This allows a fast table calculation, and produces shading factor evaluations for about 12 tracker positions (two-axis) or 8 (one-axis). This doesn't take the "finite" size of the system into account, i.e. the first row (in east or west) doesn't suffer of mutual shading; this may introduce an error of the order of 1/N rows. Consequences The main effect of the errors in the old version was visible with the backtracking strategy: as by definition of backtracking the shading factor is null for any sun's direction (i.e. any element of the shading table), the integral of the shading factor was null. This is not the reality as with a tilted plane, a part of the diffuse (and the albedo) is affected by the neighbor trackers. The new calculation gives indeed a shading factor on the diffuse, which may be of the order of 2 - 3% or even more, on the yearly system yield, depending of course of the system (especially the climate and GCR). Now the same arguments should apply to the non-backtracking systems: the shading factor on diffuse should depend on the instantaneous tilt. However with the old calculation, the existing not-null shading factor gave a not-null value for the shading factor on diffuse. According to our first evaluations, it seems that the result with the new and the old calculations without backtracking are close to each other. This means that the "old" shading factor on diffuse represents rather well an average over the year. This should be verified with different systems, especially different climates and GCR. This structural simulation difference between backtracking and not-backtracking systems affects of course the comparisons between both strategies, and favors the non-backtracking systems by respect to old simulations. NB: These discrepancies are lower in very sunny climates (low diffuse fraction). You can see some comments on our forum Additional Shading Losses in V6.1. See also How to explain the high loss values on diffuse with (back)tracking systems ?

In which tool ? When you import a Meteonorm file using the "Import Meteo Data" tool, you can change the filename as you like, but indeed it doesn't memorize the Site name you have modified. This is a bug to be corrected. However you can change the site name in "Meteo tables and Graphs", and save the .MET file with your new site name.

When you import PVGIS data (monthly values), you are prompted for generating a synthetic hourly file. You are advised to do so as it is useful for the project. When you are choosing the site of your project in the site database (in this case your PVGIS site), PVsyst will automatically associate an hourly file to your site if it finds one in the vicinity (nearer thatn 10 km) in the database. Otherwise it will generate a synthetic houly file from the monthly values of your chosen site. Now if PVsyst has chosen an hourly file that you don't want, it is always possible to choose another one the the hourly meteo database. And if PVsyst has chosen an unwanted file in the vicinity and you want to create a synthetic file from your site, you have a button "Generate".

Many parameters have to be fixed in the program, and are underlaying the behaviour of different models, warnings, etc. These parameters, named "Hidden parameters", are gathered in a PVsyst system file, sorted by categories. You can modify these parameters in case of necessity, and always retrieve the PVsyst value by clicking the Default checkbox. These are available by the main menu "Preferences" / "Edit Hidden Parameters". NB: In the version 6, some of the Hidden parameters, usually related to a given project, are now defined in the project's parameters (button "Albedo-Settings"). The corresponding hidden parameter just acts as a default for any new project. If you don't retrieve the behaviour you had in the version 5 after modifying a given hidden parameter, please have a look on this option.

The Heterogeneous option can be used for treating your case. However with this option, the shading factor is computed only once, and applied on both orientations identically. This may produce errors on the shading losses if the plan angles are too different (as for both opposite roofs). This is the reason why PVsyst puts a limit to the angle difference, and prevents calculation if it is overcome. This limit may be changed: - in the version 5, in the Hidden parameters: "Detailed Simulation Verification Conditions" / "Shadings with heterogeneous fields: max. angle difference". - in the version 6, in the project's definitionm button "Albedo-Settings". You can always perform 2 different simulations (one for each orientation) for analysing the effective error due to this approximate simulation.

Yes PVsyst allows working with Micro inverters, and Enphase inverters are in the database. You can define at most 2 different orientations in a same simulation. However you can do a simulation for each subsystem, i.e. each orientation independently, including a shading analysis. And then simply add the results for your complete system.

This arises sometimes, sorry. The internal Web Browser included in PVsyst (a DELPHI component) sometimes doesn't work well, especially when you have a Proxy, and we did not yet find a solution. However this doesn't prevent to define new sites. This map tool is only here for simplifying your life, by doing the job of, for example, GoogleEarth or GoogleMap. It only allows to get the Latitude, Longitude and Altitude of your given location. These values may be typed in the first page "Geographical coordinates". And after that you will be able to import data from Meteonorm (or eventually NASA-SSE).

Corrected in the version 6.08. As well as the fact that the LID Loss parameter was not written on then Calculation version file (correctly used in the simulation, but "forgotten" when reopeneng the calculation version).

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