André Mermoud

This loss corresponds to the iron loss of the transformer, it is proportionnal to the voltage applied to the secondary. It occurs during the full time, when the transformer is connected to the High Voltage grid. Now if you have a switch between the output of the inverter and the high-voltage line, which is open during night, you can check this option. Otherwise you shouldn't of course.

Nobody cannot give any explanation if you don't mention the full parameters and data. You don't mention the GlobInc irradiation value of your meteo data. The best tool for analysing such results is to have a look on the Loss diagram.

You have to change the parameter "Limit Overload Loss for Design". In the version 5, in the Hidden parameters "Detailed Simulation Verification Conditions". In the version 6, in the Project's parameters, button "Albedo-Settings". In the FAQ, please see "Can I define a system with very oversized Inverter ? "

I have carefully checked the program and everything seems to be OK. For a tilted single axis system, I have analysed a clear day and a cloudy one, and everything is quite coherent. It is interesting to observe that the albedo loss is of the same order of magnitude than the loss on diffuse, either on the clear day, and in the monthly results. Clear day diffuse and albedo losses for Normal tracking and backtracking systems I also have analysed the monthly and yearly values, and I observe that as expected, the Shading losses on diffuse and albedo, for normal system, are higher than the ones with backrracking. I don't see a higher loss with backtracking, as reported by other users. If you have such data with single-axis projects, please send me the full project. NB: for dual-axis systems, there are several backtracking strategies possible. Depending namely on the nechanical tracking system. In PVsyst only one has been developed in the present time: keeping the tilt according to the sun's height, the backtracking is applied to the azimuth. In this mode (probably far from being optimal) the diffuse and albedo losses may be very high, and there is no reason that they are lower than with not-backtracking systems. Global results for both tracking options. Detailed contributions of all components: Beam, Diffuse and Albedo.

You are right. Diffuse losses over 1.5 to 2% seem quite unrealistic (I did only observe 1% to 1.5% during my development). And getting higher losses with backtracking is not logical. I will carefully check my calculation.

I have corrected this for the version 6.11.

No sorry, in the present time the use of heterogeneous fileds is not possible with stand-alone systems. I intend to deeply modernize the Stand-alone systems management during the next months. I will of course study this possibility.

You are right. The horizon shading is a very difficult problem, also for the interpretation of the results. In PVsyst it is calculated explicitely, and is included in the PR. With measured data, it is not. What is the official definition of the in the norm IEC EN 61724 ? I'm not sure, but I think this uncertainty is not addressed. Please see the FAQ How is treated the Horizon contribution in Meteo data?.

The new version 6.11 should be released within about 2-3 weeks. However with this new development, simulation the backtracking without 3D scene is no more advised, since we found that the shadings on the diffuse are not negligible.

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