André Mermoud

It is not necessary to find your country in the database list. The meteonorm program (included in PVsyst) holds measured meteo data (10-30 years averages) for about 1'200 sites in the world, named "Stations". The "native" database of PVsyst is based on these 1'200 Meteonorm "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. In the PVsyst "Geographical sites" option, you can choose any location on a google map (or by coordinates), 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 "Databases" / "Import Meteo Data", and press F1 for more details, a description of each source and the procedure for importing them. If you can obtain climate data from your Meteorological Service, or if you have your own measured data, you have also a general tool for importing data from almost any ASCII (text) file. There are 3 companies which now distribute Satellite recent data for anywhere on the earth: these are SolarGIS, Helioclim-SoDa and 3Tiers. They avail of recent data in hourly values, but this is for pay. If you ask them in the PVsyst standard format, you can also import these data into PVsyst using "Tools" / "Import Meteo data".

Which shading loss? From which information ? No of course, PVsyst doesn't "guess" any shading losses.

For importing you own meteo data in PVsyst, please open "Databases" / "Import ASCII meteo files", and press F1 for getting the full procedure in the help.

I understand your bewilderment. With the PVsyst simulations, our objective is always to approach the reality at best. But this involves models, and models are never the reality. Now PVsyst is considered by some people as a reference, and many assume that "this is the truth". This situation is quite independent on our willingness. We never pretended to become such a reference, and we cannot assume any responsibility about the full reliability of the results in any case. In particular, this should not prevent us to do modifications in the simulation, if we judge it necessary, even if it is not in accordance with previous simulations. A software which doesn't evolve is dead. In PVsyst, the estimation of the shading effects on the diffuse is a model. It is based on the hypothesis that the diffuse is isotropic, and performs an integral of the irradiance with shading factor over all directions of the sky vault "seen" by the collectors. A similar hypothesis and calculation is applied to the albedo contribution, involved in the transposition models. This model is from my own, implemented in PVsyst since the beginning (1993). I proposed a research project for assessing this hypothesis by an experimental work, but I couldn't obtain financial support: this question didn't have any interest for anybody! I don't know any publication studying the effect of shadings on the diffuse part. I don't know how this question is treated in other software. However this is a crucial question as it usually represents half of the shadings loss (or more) in most cases. If someone has some references, please communicate them to me. The calculation of the tracking systems was introduced in PVsyst more than 10 years ago. The calculation of the shading on diffuse was treated in the same way as for the fixed planes, i.e. by integrating over the shading factor table. This was indeed an erroneous assumption, but I was not aware of that until about one year ago. Correcting this represented a not megligible work, that I just performed for the version 6.1. I could'nt guess that this would imply such a high loss before doing the full calculation (see our FAQ How is calculated the shading loss factor in tracking systems). But this is quite plausible if you have a look on my publication "Optimization of row-arrangement in PV Systems, shading loss evaluations according to module positioning and connexions". This shows that in row arrangement the shading factor on diffuse is proportionnal to the plane tilt; then in tracking systems we have high tracker's tilts in the morning and the evening. Moreover the limit angle is usually rather high (increases with the tilt when the pitch is constant). The situation will still be worse with lower GCR, as when the distance between rows increases, the maximum tilt allowed by the backtracking will also increase. Shading factor on diffuse in row arrangement, as computed with PVsyst hypothesis. It is a geometrical characteristics, independent on the meteo data and site. The loss is also due to the albedo contribution: the transposition model yields an albedo contribution proportionnal to (1 - cosi)/2 (i = tilt angle), with about 1% loss at 30° tilt, increasing more than linearly. This contribution is completely lost in big arrays: only the first row "sees" the albedo contribution. NB: This calculation error appears essentially in the calculation of backtracking systems. The old calculation with "normal" tracking is much less affected: according to my first observations (to be confirmed) the result with the new calculation is rather similar to the old one: the shading factors (global of for each position) compensate each other. NB: This work about shadings with tracking systems was undertaken after the publication "Increased Energy Production of First Solar Horizontal Single-axis Tracking PV Systems without Backtracking", Lauren Ngan and al, First Solar, San Francisco 94105. Now the economical impact of such uncertainties in the simulations essentially acts on the previsions of the financial balance, not in the real yield. PVsyst has never created nor lost any kWh by itself ! This can have some implications on contracts, or technological choices like choosing Backtracking. However the backtracking choice may easily be reverted to "normal operation" without significant costs, if this appears to be better.

You can download and install V6 without perturbating the running of your version 5, and use it during 30 days for evaluation. Both software may run simultaneously without problem (but not on the same data: projects and files issued from the version 5 may be open in the version 6, but the inverse is not true).

You are right, I have forgotten writing this information on the file with the Calculation version. This will be corrected in the next version 6.11.

I have indeed done very deep modifications for the version 6.10 (completely rewritten the shading loss factors on diffuse for tracking, see the FAQ How is calculated the shading loss factor on diffuse with tracking systems ? ). And I have forgotten to treat the case when you define a tracking system, without defining the 3D shading scene. If you create your 3D system and ask for shadings, you will be able to run the simulation. I will of course protect the simulation against this case for the next version. NB: with the previous versions (before 5.10), when using the backtracking strategy the shading factor was null (by definition of the backtracking, for beam component), so that it didn't make much sense to construct the 3D scene. But now you have shading losses on the diffuse component, therefore you cannot avoid to construct the 3D scene anymore.

The determination of these parameters is really not easy, and cannot be evaluated directly from usual standard certifications. Please have a look on the FAQ What explains the difference of Yieldsa between different modules For the PVsyst database I use to filter the values proposed by the manufacturers, when they seem too optimistic by respect to what I know about the model, and usually I ask independent assessment. Now if you use the PAN files directly from the manufacturer, there is no control of course.

This depends on where you are. Reliable meteo data ara available in some regions (Europe, USA), but very scarce in other ones. See the help of PVsyst "Meteorological data > Meteorological data sources". When using your own data, be aware that the annual variation may be of the order of 4-5% RMS from year to year, dending on the climate (less with very sunny climates). And also that own measurements are subject to high unaccuracies when not registered with very high care (namely careful calibration and alignment of the instruments). Now at least in Europe, the climate has changed since the beginning of this century: the irradiance is higher by as much as 5% (or more). See the PVGIS database. I don't know for other regions of the world. You can get reliable recent data for anywhere (for example SolarGIS provide excellent data), but this is for pay.

Please see our FAQ "How is calculated the PR ?". This should give the explanation. Probably the Nominal efficiency of your module is different in the Loss diagram.

For updating to the latest version 5.xx: In PVsyst main menu, you have "Web" / "Check for updates ... " If this doesn't work (sometimes due to firewall or proxy), you can always download the latest version from our web site www.pvsyst.com

Sorry, I don't understand your numbers. For the yield, you are probably speaking of Specific production, expressed in [kWh/kWp]. But such a high productivity is completely out of standards. However the Specific production doesn't depend on the Efficiency of the modules at STC. When you install 1000 kWp of modules, the production will be related to the Nominal power, not the efficiency. With lower efficiency, you will have a greater area, but still 1000 kWp installed ... Now the differences in yield may arise due to the temperature behaviour and low-light sensitivities of the modules. And this is dependent on specific model parameters (namely Rserie), which are not always known with accuracy. See our FAQ What explains the difference in Yield between different modules?

In the version 5, the simulation calculation was done on the whole subfield at a time. In the new version 6, due to the treatment of the elecrical shading mismatch, the calculation has to be done inverter by inverter. This is of course much slower in your case. However we can wonder the pertinence of doing MW-scale systems with micro-inverters. If you want to evaluate the differences, you can simulate you system as a little subsystem.

I don't know what could happen. Please send me your full project, using "Files" / "Export Components/Projects" in the main menu, in order to be sure that all required files are present.

You cannot build a system without a battery, as the sun's production is never guaranteed. Therefore the problem will be reduced to define a stand-alone system. Your problem will be to find an inverter able to drive you motor, including the starting current. This is probably standard in the industry.

In order to facilitate comparisons between several PV installations, JRC (European Joint Research Center) introduced the following Performance Index, which were then included in the IEC EN 61724 norm. These indicators are related to the incident energy in the collector plane, and are normalised by the Pnom = Array nominal installed power at STC, as given by the PV-module manufacturer [kWp]. Therefore they are independent of the array size, the geographic situation and the field orientation. We define the following quantities: - Yr [kWh/kWp] = Reference system Yield. This is the ideal array Yield according to Pnom as defined by manufacturer, without any loss. I.e. the energy produced if the system was always running at the STC efficiency. This can be understood as each incident kWh should ideally produce the Array Nominal Power Pnom during one hour. Yr is numerically equal to the incident energy in the plane of array [POA], expressed in [kWh/m²] (see below). - Ya [kWh/kWp] = Array Yield is the array daily output energy, referred to the nominal power [kWh / KWp]. - Yf [kWh/kWp] = System Yield is the system daily useful energy, referred to the nominal power [kWh / KWp / day]. - Lc = Collection Loss = Yr - Ya, is the array losses, including thermal, wiring, module quality, mismatch and IAM losses, shading, dirt, MPP, regulation losses, as well as all other inefficiencies. - Ls = System Loss = Ya - Yf, include inverter loss in grid-connected systems, or battery inefficiencies in stand-alone. - PR = Performance Ratio = Yf / Yr, is the global system efficiency by respect to the nominal installed power. Important remark about units There is often a unit's confusion with the quantity Yr, which may be understood - either as the incident energy (with units [kWh/m²]) - or as the ideal array Yield according to Pnom (expressed as [kWh / KWp]). 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²], the kWh represent incident irradiance energy (light flux) - in the latter case [kWh/kWp], the kWh mean produced electrical energy !!!

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.