André Mermoud

The counties listed in the definition of a geographic site are just a list of the countriesof already defined sites in the database. If you create a new site and don't find your country, you can simply type it in the ComboBox.

I have done a comparison between the different sources of data imported in PVsyst, and available for Europe: we can observe a discrepancy of the order of +/- 10 % (yearly sums) between all these sources, and this is of course the first uncertainty of the PV production forecast. Please see the FAQ What is the accuracy of the different meteo data ? And I agree with Marvin: nobody knows where is the truth (if truth exists) ...

There is necessarily a combination of Time zone definition and time shift which should match the internal time of PVsyst. This is defined as the beginning of the interval (8:00 means the period of 8:00 to 9:00). If you have constructed an hourly file from 5 min data, you can define the hours in this way, and therefore the time shift should be 0 (you have put 30 min). You can also change the time stamps of you data (i.e. just shift the column of hours by one hour - i.e. one cell). You have specified GHI (Global Horizontal) irradiances, when you have defined a plane of 50° tilt: is your irradiance measured with a solarimeter in this plane ? In this case you shoud define GPI (Global plane Irradiance, or POA), and not GHI, so that PVsyst understands that this is an irradiance oin a tilted plane. But this is not the best suited tool for importing your data: the "standard format" of PVsyst is meant for representing a full year of clean data (i.e. from "official" database"). You should use "Tools" / "Import ASCII meteo files" instead, which accepts almost any format of data. When in this tool you press F1 for getting the procedure. This tool will accept your 5-minutes data as such, and gather them into hourly data in a clean way. It will also create a file just matching your data (i.e. one month, up to one day, accepting holes, an so on), without the necessity of defining dummy values. And as you don't avail of temperatures, it will manage the generation of temperatures, on the basis of externally specified monthly values. Please carefully read the Help "Geographical and Meteorological data > Import of hourly data ASCII files" and "Geographical and Meteorological data > Import of custom hourly data ASCII files > Conversion protocol".

You are right: I tried to define your pump and did not succeed. There is a problem in the software with the definition of centrifugal pumps using the efficiency as input parameters, that I have to analyse and correct for a next version of PVsyst.

In the PV module: The area is defined as the gross size of the module: Length x Width. Except with tile-modules, where this is may be defined as the apparent area. This is the reference surface for the determination of the efficiency. Now in the PV module you can also define the area of the cells (sensitive area): this is only used for the evaluation of the cell's efficiency, i.e. a characteristics of the PV module technology. The simulation uses the rough area of the modules for the evaluation of the efficiency. In the 3D shading part: In a first step, the areas are defined independtly of the modules: these are generic surfaces which may receive the installation of modules, whatever their size, disposition, and spacing between them. The shading factor calculation is not very sensitive to the real area. These plane areas may (should) be over-sized in order to be sufficient for receiving the modules. When you exit the 3D editor, PVsyst will check that you have defined sufficient room for placing the modules defined in the System part. This should not be less than the total modules area, but may be largely oversized. In a final step (in the future version 6) the layout of the modules will have to be fully defined on these surfaces, in order to compute the electrical effects of the shadings. After this definition the 3D areas will be readjusted to the real position of the modules and their eventual spacing.

Unlike most 3D programs, the PVsyst shading 3D data are constructed using a very elaborated structure (the "native" data are elementary objects with their sizes and position/orientation, which are reconstructed and repositioned by the program at each execution). This structure is very difficult to reconstruct from not well-organized elementary data in an automatic way. On the other hand, the shading calculation time in PVsyst is strongly dependent on the number of elementary surfaces defined in the scene. As in drawing software this is not a limitation, people create complex scenes with many realistic details, not relevant for the shading calculations. We have to find some algorithms for analysing and suppressing the useless elements. This is a complex task. We are now on the way of developing the import of Sketchup drawings. This should be available within a few months. But the import of Autocad *.DWG files is not possible in the present time. We are studying the possibility of importing some specific objects like terrain descriptions, or 2D roof layouts (chimneys, technical elements).

Solmetric "SunEye" provides an horizon line: this is a list of (Height/Azimuth) points. You can easily import the SunEye data (file "ObstructionElevations.CSV") in PVsyst, option "Horizon", button "Read/Import". Please be aware that the SunEye results are only useable for defining far shadings (i.e. an horizon line). Shading obstacles are considered as "far" when at a given time the full array may be considered shaded or not: the sun is or is not present on the array. As an order of magnitude, when the obstacle is at a distance of, say, 10 times the array size. For near obstacles - which produce partial shades - you must use the "Near shadings" option, i.e. create a 3D representation of your PV field and its environmnet. The SunEye data are completely unuseable for this. NB: Solmetrics had established a specific file for use in PVsyst. Please don't use this file, which was developed for verion 4 and is not satisfactory.

This is a complex problem indeed. In the years 1990 we had passed a full-day seminar on this question with all involved people in Switzerland (including the Meteonorm team), and did not find any satisfactory solution. With our mountains, meteo measurements in Switzerland are especially concerned with this question of course ! With any ground-measured data, the horizon loss of irradiance is already included in the meteo data. This is very difficult to use 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. - 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 in the simulation of course. Therefore in any case (except on-site meteo measurements), the horizon data should ideally be horizon-free and the horizon effect should be computed within PVsyst, using the effective horizon line of the site. There is no simple mean for avoiding the problem. With monthly values, we could generate a full year of hourly values, evaluate the loss (on beam) due to the pre-specified horizon of the site, and then add these losses to the monthly original values and re-generate a synthetic hourly file. This file will have better "free horizon" values on which we can apply the real horizon of the PV system. With hourly values, we should reconstruct the supposed beam component below (and behind) the horizon. 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 did not yet implement this special case in PVsyst.

There is no optimal solution. This is a multicriteria choice resulting in a compromise between several requirements. You have to decide which aspect is to be optimized (maximum installed power on the available area, investment, efficiency, amount of energy yield, price of the energy, simplcity and price of the supports, etc). PVsyst provides a pedagogic tool for the understanding of the performances as function of plane tilt and row pitch (for a given limit shading angle): in the "Orientation" part, choose "Unlimited sheds" / "Show optimization". The graph shows the annual yield (by respect to horizontal) for unshaded plane (in green) and shaded system (irradiance or electrical effect). This tool clearly shows that the optimal tilt angle for unshaded plane is significantly reduced when considering the shaded performances. And this becomes dramatically worse when considering sheds not well oriented toward the south. Further, the power which can be installed on a given area decreases when the tilt increases. With 30° collector tilt, you can in general not put more collectors area than 45-50% of the available area. With low tilt angles (around 3°), this increases to 80% or more. The mechanical structures are much more simple with low tilts (reduced wind sensitivity). But the low tilts may induce cleaning problems with rain. You are advised to use frameless modules. NB: for the final optimization of your system, you are advised to perform the full hourly simulation and vary the parameters. You can easily do that by using the "Batch mode" (version 6 only).

Yes, this is quite normal. When you tilt the baseline of a collector (rotating around the azimuth line), the plane "true" orientation will change. For understanding this: please take a cardboard as collector, and position it at, say, 30°south. Then give a tilt to the base (baseline slope). Now the plane azimuth is defined as the perpendicular to the intersection of your cardboard and the horizontal plane. And the plane tilt is the tilt accounted perpendiculary to this horizontal line (i.e. the angle between the plane of your cardboard and the horizontal plane) At the limit of a vertical base line, the azimuth will be (90°-plane tilt) (by respect to original Azimuth if not south). The calculation of these new orientation angles is not straightforward: it implies 3D rotations matrices. But you can trust the proposition of PVsyst... This arises on a roof when the tables are set perpendicularly to the slope, and also when you put tables on a sloped terrain (hill). In the case of a hill, you have usually many different slopes, and PVsyst performs an average for the incident irradiance calculation. You have a detailed tool for analyzing this situation in the 3D shadings editor, menu "Tools > Edit orientations".

This is not a problem of computer performances. 3D shadings calculation In the 3D tool of old versions, the calculation of the shading factor went with the square of the number of elements; the elaboration time of the shading factor table becomes prohibitive above some few tausends of elements. In the version 6, this calculation has been optimized, with a gain of up to a factor of 10 in speed. For using this feature, make sure that in the menu of the 3D editor, the option "Tools" / "Optimized shading calculation" is checked. Since then Version 6.6, this calculation uses the "OpenGL" tool, and this is no more a problem. In your 3-D shading scene, you should not define one rectangle for each PV module. This is not the right way. The "tables" (sheds or rectangles) of PVsyst are generic surfaces, intended for receiving a set of PV modules. You are advised to define each table as big as possible according to the constraints of your configuration. For example, when you have side-by-side sheds, you can define a big one instead. Calculation on partial systems NB: Since V 6.44, it is possible to specify a representative sub-part of the system (for example the input of one only inverter), and during the simulation the shading calculation will only be performed on this sub-system, but applied to the full system. This concerns the "Linear shadings calculation", and the calculation "According to modules strings". This tool doesn't apply to the "Module layout" calculation. However this is no more really useful as the normal calculation is sufficiently fast now, event with very big systems. Advice: with very big power plants, if the configuration is regular (i.e. with flat ground) you are advised to perform your first simulations (for optimization purpose) using the generic option "Unlimited sheds" in the "Orientation" part. In this case you don't have to define a 3D shadings scene, and the calculation will be straightforward. This is for example useful for optimization analysis of the row-to-row distance and shed tilt Module Layout calculation The detailed calculation of the electrical effect according to the Module layout option is also very time-consuming, without possible optimization. This option is not suited for very big system. For multi-MW systems, you should evaluate the electrical shading loss with the "ModuleLayout" option using a part of the system (say - one inverter, i.e. one MW) and extend this to the whole system. Since version 6.67, PVsyst puts a warning for systems over 1 MW, and prevents the definitions of ModuleLayout for systems bigger than 5 MW. This upper limit may be increased in the hidden parameters, topic "System design parameters, losses, shadings". For evaluating the electrical shading loss in bigger systems, you should: - Define a variant with a representative sub-system of your full big system (for example a sub-array connected to one central inverter, i.e. around 1 MWp). - Define the "Module Layout" for this sub-system, and perform the simulation. You will get an electrical shading loss value. - Recaclulate the Electrical losses with the option "According to Module strings" for this sub-system, with "Fraction for electrical effect" = 100%. - Comparing the results for electrical loss will allow to estimate a "Fraction for electrical effect" leading to a same loss value. - You can now define the option "According to Module strings" for the whole system, and apply this new "Fraction for electrical effect".

Sorry, the bifacial behaviour is not implemented in PVsyst. This would require a reliable evaluation of the reflected irradiance behind the modules. For this, the whole geometry of the modules and their rear configuration should be described in detail, the reflection coefficients should be specified. This is a very complex computation, not possible in a general software like PVsyst. Moreover one can wonder from where the light could come: there is no possibility of beam component (except special cases with spaced cells and reflectors), and reflected diffuse is quasi-impossible to calculate in a simple way, and probably very low. You can try to measure it using a solarimeter on the back side, in different locations of your array. Now we should also emphasize that in a string of modules, the current is driven by the cell of weakest current. Therefore for representing a significant gain, the reflected irradiance should be uniform on the back area of a whole string of modules, which seems quasi-impossible. NB: the only configuration which would eventually be possible to simulate would be vertical modules oriented east-west. In this case you can use "mixed orientations" and define 2 different modules, one for the front and one for the back side of your bifacial modules.

In PVsyst, the evaluation of the "Losses" of a PV array (as for the definition of the normalised performance ratios in Europe, see Help), takes as starting point the energy which would be produced if the system worked always at STC conditions (1000 W/m², 25°C, AM1.5). The first loss evaluated in the simulation process and the loss diagram is the "Irradiance loss", which is the difference between the STC efficiency and the effective efficiency under the instantaneous irradiance, at 25°C (see "How is evaluated the "Low-light" efficiency ?". Low-light efficiencies over STC may be obtained, mainly by the choice of the Rserie value. Values obtained by official flash-tests measurements for crystalline modules usually don't overcome 0.3 to 0.5%. Higher values in the model should be suspected of manipulation of the Rserie parameter. These efficiency performances measured outdoor are lower by 0.5 to 1%, probably due to the diffuse contents of the incident irradiance, which suffers of IAM loss effect. You can also obtain slightly positive irradiance loss in very sunny situations, when the system mainly operates above 400 to 600 W/m2.

The backtracking with axis not facing south is allowed and works if you turn the whole trackers set toward not-south azimuth (i.e. when the alignment basis of each tracker is perpendicular to the axis, misalign parameter=0). For axis with azimuths not perpendicular to the trackers aligment (i.e. not-null "misalign" parameter), the problem is much more complex, and I was not able to find an analytical algorithm for tilted axis. Now for horizontal axis in this situation, the algorithm should be the same as in the Misalign=0 case, but I have indeed not developed this special case.

Sorry, it is indeed an error in the version 5.58, that I have corrected in the version 5.59. It is related to the clipboard contents, and appears when the last selection and "copy" was not a piece of text.

For the temperatures: this is a modification of the format appeared in Firefox 13: see my answer import meteo data from PVgis with firefox 13 For the February error, the Leap Yera information is not well initialized. see my answer in Import Meteo PVGIS bug

You are right, I have forgotten initializing the Leap-year information when importing PVGIS data. Therefore the import process uses sometimes 28 and sometimes 29 days for February. This induces an error of 3.5% on the February data, but less than 0.15% on the yearly sum (for Europe). By the way the real error when considering a simulation as valid for set of years would be 3/4 of this values, as 1 year over 4 is leap... This error is random (depending on the last use of this variable in the program), not specific to Classic or SAF data. It will be corrected for the next issue 5.59 of PVsyst.

You should redefine your SMA inverter as 5 MPPT inputs, and use one SubArray with 5 inverters * 4 strings (MPPT), and another one by 5 inverters * 1 string (MPPT). See the FAQ How to use the inverters with very different MPPT inputs (Tripower of SMA) ?

What you call "Parasitic resistance" is named "Series resistance" in PVsyst. Please observe that the measured Rserie proposed by the manufacturer is not the Rserie as defined in the one-diode model. See ou FAQ I can't specify my measured Rserie. NB: With version 5, the best way of setting a reliable value to the Rserie of the One-diode model, is to try to reproduce the low-light performances if these are provided by the manufacturer. You can analyse this in PVsyst, using the graph "Efficiency as function of Irradiance", and proceed by trys and errors. There is now a tool for performing directly this adjustment in the version 6. Please also see our FAQ What explaind differences of yield between different modules ?

In the version 5, the soiling loss parameter (to be defined in the "Detailed losses" and appearing in the first page of the report) was defined as a percentage of the STC energy value. Now during the simulation, the corresponding energy loss is indeed calculated as a percentage of the STC energy as specified. But the result on the loss diagram is referenced as a percentage of the remaining energy just before the loss, therefore a slightly different percentage value. In the versionn 6, it is accounted in the optical losses, and is a loss by respect to the remaining irradiance (after shading and IAM losses). The value on the loss diagram is identical to the specified parameter.

The format of the data structure obtained by "Copy" has indeed been changed with Firefeox V 13. I will adapt the importing tool in the next version 5.58 of PVsyst. In the mean time you should use another browser.

With near shadings in PVsyst, you can define and perform simulations with 3 kinds of near shadings (to be applied to the beam component): - The shading loss due to the irradiance deficit on the modules (optical loss), which we call "Linear shadings". The shading factor is the ratio of the effective shaded area with respect to the total field area. - The Electrical losses, i.e. the effect of the partial shadings on the electrical response of your PV array. The calculation requires to define the position of each module, and specify its electrical connexion on the inverter input, in order to combine each I/V curve of each sub-module. This is done in the "Module Layout" part. The electrical loss will appear in the Array losses on the loss diagram. - Simplified Electrical losses, which we called shadings "according to module strings": this is intended to the evaluation of the maximum electrical effect on the array production, in a simplified and approximate way. Remember that in a string, the poorer cell determines the current of the whole string. That is, when one cell is shaded, the entire string is affected, and is supposed to become almost inefficient (for the beam component). Therefore in this mode, the array is partitioned into rectangles, each rectangle representing (approximately) the area of a full string of modules (to be defined within the shading scene, icon on the left). Then, when a part of this rectangle is shaded, the whole rectangle is considered inactive. The Global Shading factor is the ratio of the shaded rectangles (grey + yellow) to the total field area. The additional loss represented by the yellow parts (Global - Linear shading factor) gives indeed an evaluation of the upper limit for the electrical loss. Now some part of the string energy is recovered by the by-pass diodes (see How to evaluate the effect of by-pass diodes in shaded arrays?). This is the reason why we have defined the "Fraction for relectrical effect". However when about one third of "sub-modules" in a string are shaded (as for example in rows arrangement), the output for beam irradiance becomes almost null, and this fraction will be near to 100%. This evaluation of electrical losses "according to modules strings" was the only way of estimating the electrical losses up to the version 5. It should still be used with very big systems, when the "Module layout" becomes impracticable due to calculation time. In this case you can evaluate the "Fraction for electrical effect" by comparing the "real" electrical loss calculated by the Module Layout on a reduced sample of your system, to the calculation "according to module strings". And apply this last calculation to the full system.

When you compute shadings with the option "according to module strings", the full rectangle-string is considered electrically inactive as soon as hit by a shade. Nevertheless, some part of the string energy is recovered by the by-pass diodes; this parameter describes which fraction of the string production is really lost. In version 5: The version 5 calculation cannot give a reliable value for this "Fraction for electrical effect" parameter. This is dependent on the shades distribution on the field and the electrical array configuration. For a shed arrangement (where the shades are very "regular" and several sub-modules are shaded), it is near to 100%, because as soon as 1/3 of its sub-modules are shaded, a string doesn't participate to the electrical production anymore. When with more "distributed" shades like Chimneys, far buildings, it could probably be of the order of 60 to 80%, depending on the "regularity" of the shade (a diagonal-like shade has a lower impact as it concerns modules better distributed in the array). In version 6 The realistic calculation of the electrical effect of shadings implies the exact positioning of each module on the geometrical plane, using the "Module Layout" tool, the identification of each electrical string in the array. Coupled to the shading calculation, the "Module layout" tool evaluates the real I/V curve of the PV array (on one MPPT input), and provides a realistic evaluation of the loss due to the electrical mismatch. Now comparing the Electrical loss calculated by this "Module layout" option, and the "Electrical loss" evaluated by the approximated shading mode "according to module strings", you will be able to establish the "Fraction for electrical effect" to be applied in order to match the Module Layout calculation. As an example, if you get 4% electrical loss from the option "according to module strings", and 3% with the Module Layout, the fraction for electrical loss will be 75%.

In tracking arrays mutual shadings may be very important, as the gains are mainly waited when the sun is low on the horizon. The backtracking strategy tries to suppress the mutual shadings by reorienting the modules. But it is an illusion to think that you should obtain a much better yield with Backtracking. When the trackers perform a normal tracking (most perpendicular to sun as possible, with mutual shadings), or perform a Backtracking (deviating from the optimal orientation) they intercept about the same "Light tube" ! In one case you have shading losses, in the other one losses for mis-orientation (cos angle). It is not clear which configuration receives more irradiance: without backtracking, the shadings usually don't affect the full "length" of the modules (=> more "active" area), with backtracking you have additional IAM losses. The only decisive advantage of the backtracking – if any – is to avoid the electrical effect of shadings (i.e. when a part of a string is shaded, the full production of the string is affected). As an example, here is a comparison between "normal tracking" (with shades) and backtracking, for a N/S axis horizontal trackers array in Santiago (Chile). The phi angles limit is +/- 45°. Backtracking and Normal tracking comparison

In the present time the Grid-systems and the Stand-alone systems are quite distinct in PVsyst. Grid systems with a battery storage are more and more used now in the reality. However their simulation is a very difficult problem, not yet implemented in PVsyst. I don't see any possibility for approaching a solution with the existing Grid-connected and Stand-alone systems presently available in the software. The objective of such hybrid systems may be quite different from case to case: - For "purists" of the PV energy, consuming a minimum of energy coming from the grid, whatever the price, - According to consuming and feed-in tariffs, optimizing the costs of electricity, - For the optimization of the grid management, injecting power during the "best" periods of the day, - Grid management: peak shaving, - Grid management: short term grid stabilization (for example for clouds), - In "rich" countries, ensuring a secure back-up in case of (rare) grid failure, - In countries where the grid is weak or intermittent, ensuring electrical availability during the whole day, - Mini-grids for the electrification of whole villages or islands, - etc... Each of these uses of the PV energy will involve different sizings, different constraints, and quite different control strategies. On the one hand, the control will depend on the self-consumption profile and the grid characteristics (availability, overload, etc), On the other hand, when should the PV array charge the batteries? When they are not full ? When the consumers are low? When the foreseen weather of the next day is bad ? And how to optimize the size of the batteries ? As an order of magnitude: for an household consumption of 15 kWh/day (a standard in Europe), storing one only day consumption would represent about 700 Ah for a 24V battery bank, i.e. about 600 kg of Lead-acid batteries. Remember that the price of the stored energy is very high. It can be evaluated by the price of the battery pack, divided by the total energy stored along the battery lifetime, i.e. Capacity (in kWh) x DOD x Max. nb. of cycles. If you assume a full storage/destorage every day, a battery pack of 1'500 cycles should be replaced every 4 years. For household systems connected to the grid, this price of kWh should be compared to the difference between the buying and the selling prices. Now components manufacturers propose a great variety of devices, configurations, usually specifically suited for one or the other of these uses. In this evaluation, we should also define the prices of the injection, consumption, stored energy (taking the limited lifetime in terms of number of cycles into account). Many people ask for such systems and strategies, without understanding that the problematics is very complex and the realization expensive. We intend to study these systems during the next months. We will probably propose simulations for a selection of these kinds of systems, to be extended progressively.