André Mermoud

Yes you are right. The term is not well chosen. Here what is named RMS is indeed the standard deviation (sigma) of the gaussian distribution. You have statistically 68% of modules within the interval -Sigma to + sigma.

No, this is not possible, even in the version 8.0.

The value shown on the loss diagram is the Pmpp as calculated from the one-diode model. It may be slightly different than the efficiency calculated from the Nameplate value 8PNom / module area). See our FAQ

The PV loss due to the cell (or array) temperature is related to this temperature in operation. This is controlled by the U-value in the "Detailed losses" parameters. See the help " Project design > Array and system losses > Array Thermal losses"

This is indeed an interesting question. But sorry, PVsyst doesn't provide this calculation. You should do that by yourself, using the suggestions mentione above.

The reasoning is the same for any optimizer. However you will not be able to do such a comparison with SolarEdge, as the inverters of SolarEdge cannot be used without optimizers.

The optimizers are useful for avoiding mismatch losses between PV modules, i.e. mainly when you have shadings and when you have a mismatch due to the differences between modules performances in a same string. However these devices have also their own inefficiency loss. If this loss is greater than the mismatch benefits, the final yield is lower.

Sorry, we cannot understand what you are doing. The images are completely unreadable. Please explain in more detail. On the other hand, if you try to analyze the differences in electrical shading losses, you are advised to analyse this specific loss on the loss diagram. Moreover, when doing such fine comparisons, you should use the full calculation of the shadings ("Slow" shading calculation, more accurate),

Question #1: this is a calculation for one particuler sun position, and by clear day. The fraction for electrical effect is a parameters applied to the shadings along the full year. Question #2: by "regular shades", we consider indeed the bottom shades of the previous sheds in a sheds arrangement. However in your case the sheds are not so regular, as the altitudes seem to be different (you have shades on the 4th shed, but not on the second and the first one). For the evaluation of the "Fraction for electrical loss", you can perform a simulation with Module layout, and a simulation with the shadings "according to strings" with 100%. The ratio between the shading losses of both simulation corresponds indeed to the "fraction for electrical loss" that you have to apply.

The variance of the meteo data multi-year distribution is supposed to be the same for any future year. Therefore the ratio P99/P50 remains the same whatever the year. You can simply calculate P99 (YearN) = P50(YearN) * P99/P50 (Year0)

On this part of the report, the calculated average mentioned on the report is indeed the average of the soiling factors, not the soiling losses. It is not weighted by the effective irradiation. This indeed doesn't have much meaning when the soiling is highly inhomogeneous along the months. However in the simulation, the soiling loss is calculated at each hour, according to the irradiance. It is quite correct.

I really don't understand what you mean. The GlobInc value is the result of the transposition on the tilted plane, it doesn't include the soiling losses. The soiling losses are taken into account in the GlobEff result (effective irradiance on the collectors). NB: The GlobInc is not an average, it is a cumulated energy.

No problem. This is quite well addressed by the PVsyst simulation. You don't mention the order of magnitude of the discrepancies between your blocks, but when the DC:AC ratios are not too high, the overload losses are only slightly dependent on the PV nominal power. You can simply try to simulate a simple system, with your different blocks independently, for the evaluation of the overload loss in each case.

I don't know. The discrepancy is 0.12%, on a bifacial contribution of 5%. I.e. a global discrepancy of 0.006%. This is compltely negligible. This is not necessarily related to the option "according to module strings". We observe sometimes little differences in the simulations, often related to rounding errors. Except in some cases, we usually don't investigate discrepancies lower than 0.1% in yearly simulations.

I don't know. Please send us your whole project, using "Files => Export project" in the main menu. e-mail: support@pvsyst.com.

Sorry, with the bi-facial model presently implemented in PVsyst, you cannot define a bifacial system with several orientations. This will be possible in the next version 8.0.0.

The grid limitation principles are fully explained in the help " Project design > Grid-connected system definition > Grid power limitation" Now I don't have any knowing of the fact that E_Grid exceeds the grid limitation. Please send an example-project. In the previous post, it was not the E_Grid, but the EOutInv value which exceeds the grid limitation.

Yes, this is possible as an approximation, when your system is not too uneven. NB: if you have warnings (for example axis tilt differences too high) you may modify the limits in the advanced parameters.

When you want to evaluated the irradiance on the ground, you will use the Biacial option. In the bifacial system definition, you have this parameter: The ground irradiance calculation will take this parameter into account.

Yes, as soon as you put a component in your workspace, it will appear in the PVsyst lists. In the lists, the components defined externally appear with a grey background.

PVsyst cannot obviously reference all batteries present on the market. You should use a battery with similar characteristics as your battery model. I.e. similar in technology, voltage and capacity. You may also use a "universal" battery, for which you explicitly define the voltage and capacity. NB: the simulation result is not very sensitive to the exact capacity of your battery pack.

These values are a result of the sîmulation. Fixing their value doesn't make sense. When you need energy for feeding your needs during the night, you don't have any solar power at disposal. Your system has to draw this energy from the grid. During the day, your load may need more power than the available PV power at this time: again, the grid will provide the complement. The only way to avoid this would be to store energy in a battery.

Sorry, it is not possible to get such a plot directly from PVsyst. The only way is to create a CSV hourly file during the simulation, including the variable E_Load (or any other desired energy quantity). And then you have to elaborate your plot from these hourly values in EXCEL.

The OND files are meant for internal use within PVsyst. We don't ensure support about them. Exceptionnally, I can say that the Nominal AC power mode (active or apparent) is described by the bit #21 of the flags.

Yes, the DC converters diectly connected to the PV array are not yet implemented in PVsyst. Please have a look on the help " Project design > Grid-connected system definition > Grid systems with storage > Grid storage, system architecture "