André Mermoud

The Global incident is computed from the Horizontal Global and Diffuse irradiances in hourly values, using a model (Perez or Hay model, may be chosen in the "Preferences"). It depends on the solar geometry, therefore on the geographical coordinates of course. It is the full irradiance as received ("viewed") by the tilted plane. We define the "Transposition factor" as the ratio GlobInc/GlobHor.

Please see the Description of the P50-P90 treatment in the FAQ. This new tool was developed in the version 6.11. It is not available in versions 5.

Yes it is exactly this idea. The "Linear shadings" loss corresponds to the Irradiance deficit on the modules. Therefore it is reported as an Irradiance loss. The "Electrical effect" is the electrical shading loss due to mismatch. It may be computed either using the "Module layout" option ("exact" calculation), or approximated by the old "shading loss according to module strings" (which gives an upper limit to the electrical shading effect); in the latter case it is the difference between the full loss "according to strings" and the linear loss (weighted by the "Fraction for electrical effect" parameter). This loss is related to the array electrical behaviour, and is therefore accounted in the Array losses. In the version 5, these 2 contributions were gathered in the Irradiation loss. The "Module layout" calculation gives the opportunity of evaluating the "Fraction for electrical effect" parameter, which was just like a rabbit pulled out of the hat in version 5.

What I mentioned was for a "massive" safety fence (for example on the border of a roof): you can approximate it as one or two long horizontal parallelepipeds (e.g. 5x5 cm2, 200 m long), and neglect the vertical parts (you can increase the parallelepipeds size for an average). I don't have an exact solution for a wire fence. Probably you can also approximate it as 2-3 long horizontal paralelepipeds. Choose the diameters as an equivalent of the wires diameters on the concerned fence area. And for the electrical effect (shading factor according to module strings), you can define these parallelepipeds as "thin objects", and specify the electrical effect ratio to a rather low value (or even a null value). The objective is to avoid the "normal" shading effect on the string.

The computation has probably entered an infinite loop. For the simulation of such a long fence, you are advised to represent your fence just by one (or two) long parallelepiped, and neglect the vertical parts. The shading calculations sometimes give errors with "holes" in closed shapes.

It is simply the result of the transposition of the irradiance from horizontal to the plane of the array. The transposition is computed either by the Hay or by the Perez model.

Yes. As the PAN files of the version 6 hold additional parameters, these cannot be "recognized" by the reading procedure of the previous versions 5. But files of the version 5 can be read in the version 6 of course. This is a general rule in PVsyst: if a file format is modified in a given version (usually for adding parameters or data), it cannot be read by older versions anymore. Allowing a general reading with older versions would imply that we update all older versions, which is absurd. This is what is named "upwards compatibility".

There is no direct mean for defining a ground within PVsyst at the moment, except by using normal objects for approximating it. You can also simply define different altitudes for your rows, without drawing the terrain. However there is another software named Helios3D, in which you can draw a terrain from Autocad references, draw and study you whole PV system, and then import this into PVsyst for the shadings analysis and the simulation.

This is possible since the version 6.11, button "Miscellaneous tools" in the project's dialog.

This is not a bug. This is an update of the shading loss calculation. Even with backtracking (where you don't have any shading losses for beam component), you can have shading losses on the diffuse as well as on the albedo. This is now taken into account since the version 6.10. The previous calculations were not quite correct. See the FAQ How is calculated the Shading loss on Diffuse for tracking systems? And also the post Additional Tracker shading loss in 6.10

In the version 6 the shading factor calculation has been optimized, so that the calculation time is quite reasonable if you define correctly the sheds (or rows, or "tables"), as geometric areas receiving the modules (not one "table" per module !!!).

I have corrected this problem in the latest version 6.12. However PVsyst cannot generate hourly wind velocities: I don't know any model for performing such a generation. Therefore the hourly values will be the monthly average in the hourly data file.

In the version 6, this parameter has been moved to the project's parameters, a more suited place (button "Albedo-Settings"). The value of the hidden parameters is used as initial default for new projects.

You can display the temperature hourly values in "Meteo tables and Graphs" / page "Tables". However you will not be able to compare anything. When genetating hourly values from monthly ones, the series of days and hours is constructed randomly: each generation will give you a completely different time series. The only meaningful temperature comparison is in monthly values. NB: the NASA-SSE usually gives significantly lower values than other sources, for 2 reasons: - the temperature is defined for 10 m altitude (not 2m as any meteo data), - the temperature is the average over the whole area of 1°x 1° (1° latitude = 111 km). If you are in montaneous regions, the temperature is taken at the average altitude, which may be much higher than the "living" altitude.

Thank you for this detailed report of the problem, and the logs. However this is an error that I can't understand from the LOG information. Please tell me: - Doest this problem arise at each of your tryings, or just once ? - try to do the same with another battery model (from de database), - Please send me the whole project, using "Files" / "Export projects/components" in the main menu, in order to ensure that all involved files are present. My address: andre.mermoud@pvsyst.com

PVsyst never mentions "current voltage", but "nominal current" or "nominal voltage". The nominal current, voltage or power of a PV module is the corresponding value delivered by the module, as specified by the manufacturer at STC (named Imp, Vmp, Pmp). The nominal current of the array is the Module's nominal current * Number of strings, The nominal voltage of the array is the Module's nominal voltage * Number of modules in series, The nominal power of the array is the Module's nominal power * Number of modules.

You can establish the main system sizing using the option "Preliminary Design" / "Stand Alone". You have to choose the location and the plane orientation. Then you define your load, the desired autonomy and the acceptable time during which you accept a lack of energy ("PLOL: Probability of Loss of Load"). And PVsyst will propose a battery pack and a PV array size. The detailed study and full simulation of your system (with specified PV module, batteries, controller, etc) will be done in the "Project Design" part.

The "Module Layout" list of subfield did not renew when you are asking an update from the 3D scene. A solution was to restart the Module definition from scratch (i.e. button "Erase Def.") This problem has been solved in the version 6.12. The program now updates from a modified 3D scene, and keeps what it can from previous definitions.

Thank you for the suggestion, it is really very interesting. We will study such kind of possibilities, when the Import from Sketchup will be quite ready and released...

The "Module Layout" tool, where you have to specify the position and the electrical wiring of each of your modules, is not practically useable for big installations (of, say, more than 500-1000 kWp). On the one hand the positioning and attribution of all modules in the system may be tedious, and on the other hand the calculation time of the simulation will become prohibitive. PVsyst advises a "reasonable" limit of 1 MW, and prevents to develop the ModuleLayout option for systems upper to 5 MW. However you can modify this limit in the Hidden parameters, topic "System Design Parameters, losses, shadings", item "Power limit for Module Layout error". If you have a very big system, you are advised to perform your shading studies with the module layout option on a reduced representative part of your system. This will give namely an electrical shading loss reference result. After that, you can perform the calculation on the full system using the shading option "according to module strings", which is easy to define and fast. This will give you another estimation of the electrical loss. With "Fraction for electrical losses" = 100%, this should represent an upper limit to this loss. Finally, comparing with the loss obtained with your reduced system, you can adjust a realistic value for the "Fraction for electrical losses" parameter, in order to get the same relative loss. With sheds (row) arrangement, the "Fraction for electrical losses" is usually 100%, even with by-pass diodes; because as soon as 30% of the submodules are shaded, the concerned string doesn't produce any more for beam component. See How to evaluate the effect of by-pass diodes in shaded arrays? Therefore both calculations should give give close electrical shading loss results.

I have fixed this problem in the version 6.12, to be released on 23/09/13. However I see that you have defined a system with 8'500 PV modules. The "Module layout" construction is really not suited for such a big system. It is really useable for systems up to, say, 100 kWp. You should use the option "According to Module strings" for this study. With your disposition in sheds, the results of this option - with a 100% electrical loss - are quite reliable. See our FAQ How to use the "Module layout" with very big plants?

I have fixed this problem for the version 6.12, to be released on 23/06/13

These differences are due to the PV module parameters. The version 6 uses different Default values as version 5, especially for the Rserie, which has effects on the low-light efficiency. Please see our FAQ What explains the difference in yield between different modules?.

OK, this was am error in recognizning Year 2000 as Leap year (only in special cases). Corrected for the next version 6.12.

Yes you are right. Thank you for pointing this out. I have corrected this for the next versions 6.12 and 5.71, to be released on 23/09/13