André Mermoud

Yes of course the row-to-row is calculated in PVsyst. There are two ways: - a direct analytic calculation, in the "orientation" choice, option "Unlimited sheds". This is valid under the hypothesis that your rows are "infinite" in length, that is we can neglect the edge effects. - the elaboration of your system in the 3D near shadings tool. For not too big systems this will allow to use the "Module layout" option for an "explicit" electrical loss effect. For the optimization: see What is the sheds shading optimum?.

1. In version 6 the horizon losses are higher than 5 Nothing has been changed in the Horizon loss calculation. This may be an effect of the Transposition model, which is, by default, the Hay model in version 5 and Perez model in version 6. The shading losses in 6 are smaller than in 5. Same answer as above. There are in principle no differences in the near shading calculations. So, there are no interpolation in time uncertainties in the shading factor table? Yes of course there are interpolation uncertainties. The solar geometry (therfore the sun's position) is calculated in the middle of the hour, and the shading factor in interpolated in the table. However these uncertainties are averaged over the whole yearly calculation. NB: with version 6, you can avoid the interpolation in the shading factor table by asking the Calculation mode: "during the simulation", i.e. the shading factor is fully computed at each simulation step. 3. Also, using the same inverter and PV modules the mismatch losses and the quality losses are in every case for each version the same. See "Which are differences in yield between version 6 and version 5 ?", especially "Losses with derate factors".

PVsyst performs a cubic interpolation between points. That is, for a value situated between point #2 and #3, it adjusts a cubic function on the points #1, #2, #3, #4. This allows to represent quite well a curved profile, especially a smooth one like the IAM behaviour. 9 points are largely sufficient in this case. However in some cases the "external" point (#1 or #4 in my previous example) gives artefacts like in your example. You can avoid this by displacing the point #8 to a higher angle value (and lower IAM value), or suppress one of the points #4 or #5 (which are quasi useless) and add a point between #8 and #9.

I don't know from which source you estimate that the satellite models overestimate the data. They have their own accuracy, with a MBE (mean bias error by respect to ground measurements) which may be either positive or negative. And in hourly values, the RMSE (root mean square difference) is competitive with terrestrial measurements as soon as you are at more than 20 km of the measuring station. Please have a look on the document "Five satellite products deriving beam and global irradiance validation on data from 23 ground stations (IEA)", Pierre Ineichen, 2011, Research report of the Institute for Environmental Sciences, University of Geneva.

The sizes and positions are indeed defined at the cm resolution in the shading scene and the Module layout parts. This can eventually produce discrepancies of some mm by respect to your engineering planes. However this will not have any perceptible impact on the shading calculations.

There is indeed an error here: you should define the inverter's file name, but the corresponding column doesn't appear on the EXCEL table (try with the PV module: it works). I will correct this for the next version 6.13. After this correction, here is an example of how to define the EXCEL parameters document for running PVsyst in 3 simulations, with different inverters. Example of the EXCEL definition with different inverters

If you know all the results of the irradiance and shading calculations in advance, you don't need to use PVsyst. Now I don't understand the fact that the shading drops, and then increases again, and how you obtained this. Please explain. "I also noticed that if you run your report with no near shade model you get a higher KW/H per year than if you were to run a report with the same system with a near shade model". I don't understand well. What is strange here ???

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.