André Mermoud

There is no limit, the calculating time will simply increase, perhaps becoming prohibitive. And this doesn't depend on the total Power of the system, but on the number of "tables" (elementary mecanical rectangles receiving PV modules). For a 5 MW plant and reasonable tables sizes, there should not be problems with the version 6, where the shading factor calculation has been optimized.

There are indeed several "new" performance reports about the IAM. However this measurement is rather difficult to perform with accuracy, and there are high discrepancies between the results of different laboratories. I can just propose my own theoretical calculations, according to the Fresnel's laws, for a standard flat glass without Anti Reflective dispositives. IAM Fresnel calculation taking 2 reflexions into account, compared to ASHRAE parametrization. I took 2 reflexions into account, i.e. the first Air-glass interface, the reflexion on the bottom of the glass side (against the PV cells), and the secondary refraction from glass to air. The next contributions are completely negligible.

For the first problem of disposition: Putting modules in several orientations on a same shading object is really not easy to do, and we decided not to allow this. This is a relatively rare case, and it doesn't justify the big amount of development. However you can always redefine your planes as independent rectangular areas, for portrait and for landscape modules dispositions. For the area calculation error: I will check in the program For the third problem of deformation: This is only a display problem, the filed area itself is not affected. We will also check this for a next version. By the way we are just elaborating a tool for the direct positioning of modules during the 3D shading development stage. It will become possible to redefine the polygonal field as the envilope of the real modules, positioned by mouse.

The far shading losses are indeed depending on plane tilt. When the modules are at low tilt, the losses arise with a higher incident angle, and the loss applies to a lower beam irradiance amount (due to cosine effect). With a high tilt, the shades apply with a lower incidence angle, when the sun's rays are more perpendicular. For understanding this intuitively, you can take the exrtreme cases of an horizontal plane (which "sees" the horizon line quite marginally) and a vertical plane, which will be affected by low sun's height, when it should be very well irradiated.

Thank you for the suggestion. This is indeed on our ToDo list since a long time. But not at the top, sorry ... In the present time you can - export (copy/paste) the Tables of monthly values in EXCEL, with your chosen output values, and compare them in EXCEL. - use the "Batch Mode", which allows to perform several simulations with different parameters in one operation, and directly compare the results in EXCEL.

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