André Mermoud

I am indeed preparing a multi-orientation option for the next version 6.13 of PVsyst (up to 8 different orientations). With a shading calculation specific for each orientation, without any angular restrictions between planes as previously. "I'm not a programming expert, but I would imagine that a small piece of code would be able to dissicate a 20 orientations project": I'm working on this implementation since more than 2 months. I can confirm that this is not "just a little bit of code". It is a very deep improvement, which involves namely many user dialog issues. It affects all parts of the software (orientation, system, shadings, module layout), and I'm really not sure that this will work perfectly just from the first issue.

The meteo data are the irradiance as measured at ground. They include the cloud losses of course... If you want to evaluate the cloud losses, you have to calculate the "Clear day" model ("Tools" / "Tables/Graphs of solar parameters") and do the difference.

I don't know what happens. Probably a corrupted file. Please check that in your project, the Project's site is well defined (with valid Monthly data). In versions before 6.12, some manipulation could lead to a corrupted project's site. Then, the project's site is used for the orientation optimization in the "Orentation" part. If corrupted, you have to destroy and recreate the project's file *.PRJ. This will not affect the calculation versions already constructed (with the same filename).

Sorry, it is not possible in the present time. Developing this possibility is on my ToDo list.

OK, I will check this in the program. But please admit that this will have a marginal effect...

In PVsyst the final yield is meant as the net energy delivered to the grid (produced - consumed). The not-operating loss (by night) is apparent on the loss diagram as parts of the transformer MV losses and the eventual auxiliaries loss (if arising by night). If we don't include them in the final yield, we should represent them as an input arrow representing an input gain drawn from the grid, which may be confusing. And still more confusing if we consider that these losses arise indeed during the full operating time (not only the night).

Sorry, this has not been completely managed in the PV module definition yet. These values should be used as default inputs for the Module Layout part. The submodule partition indicates how the submodules (sets of cells protected by one by pass diode) will be arranged. For example with a 72 (6 x 12) cells module: - "In length" means that the submodule is divided into 3 longitudinal bands of 2x12 cells, - "In width" means that the submodule is divided into 3 transverse parts of 6x4 cells, - "Mixed" would mean a crossed arrangement (for more diodes or cells). I will probably suppress this unprobable possibility. I will put a little drawing according to the user's choice. For a future version ...

Each point of the graph represents the production of one day. On the x-axis, you have the daily irradiation in the collector plane [kWh/m2/day] On the y-axis, you have the system's production [kWh/day] For Grid-connected systems, this is usually very linear (points below correspond to days with special losses like shadings or system unavailability). You have often a curvature in the upper part, corresponding to higher operating temperatures in summer. For Stand-alone or pumping systems, it is much more instructive: a plateau indicates that the storage is full: if the plateau is low (begins very early), your storage (battery or water tank) is not sufficient: for many days the production is limited by the full filling of the storage. A well-sized storage will give a little plateau in the upper part of the graph.

When you are in the project's definition dialog, you have a button "Albedo-Settings" Pushing this button you have the item "Limit overload loss for design". This defines the amount of overload energy you accept to loose over the year. The help is available from anywhere in the software, by typing F1 (or sometimes little orange questionmarks for more targeted answers).

When you define heterogonous fields, you may define a sub-array in one orientation, a sub-array in the second orientation, and a sub-array "Mixed" in which some strings are in the 1st orientation and other ones in the 2nd orientation. Only the "mixed" sub-array implies a combination of the I/V characteristics observed in both orientations, and the result is according to the total nominal power if the "mixed" sub-array. Now the shading calculations have nothing to do with this. The shading factor is calculated once for the whole system, and applied identically to irradiances in both orientations.

This is normal: even with backtracking you have a shading contribution on the diffuse. Please see the FAQ How is calculated the Shading Loss on diffuse with tracking systems ?

There is nothing to be fixed. It is just a new (enhanced) behavior of the program.

I had fixed this problem in a previous version (I don't remember which one). Please update to the latest one.

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.