André Mermoud

The calculation of electrical shading losses (shadings "according to module strings") is based on the hypothesis that when a little part of a string of modules is shaded, the whole string is supposed not to produce anymore electricity (for beam component). Up to version 6.26, the criteria during the simulation was that as soon as the "Linear" shading factor is not null, the electrical effect is accounted (ON/OFF) for the whole string. However with the shading factor table, this created an artefact: if you have a little shading at sun's height = 20°, the "linear shading factor" (which is an interpolation between 20° and 30°) is not null up to 30°, so that the electrical shading is activated for the whole interval. When comparing with the analytical calculation "Unlimited sheds", this gave overestimations of the electrical effect of about 2-3% for one module in landscape (less for 2, 3, 4 strings in the width of the shed). Therefore since V 6.27, the electrical effect is only activated when the "Linear shading" calculation exceeds a threshold. This threshold was established by comparing the results with the "Unlimited sheds", which is supposed to be much more reliable as it is an analytical calculation. This threshold depends on the number of strings in the width of the shed. It also takes into account the fact that when the first bottom row of cells is partially shaded the electrical loss of the string is partial. However this new strategy may have unexpected effects: for example if you have HV lines over your plant, the "Linear shading" factore may be insufficient (below the threshold), so that the "Thin objects" electrical calculation is not activated. In the present time we don't have an automatic solution for addressing this problem. NB: You can modify or suppress the threshold (for example in the latter case) in the hidden parameters, topic "Miscellaneous: meteo, simulation", item "Threshold shading factor from table for module activation" if you are using the table calculation, or "Threshold shading factor from calculation for module activation" if you are using the calculation within the simulation ("Slow" option).

You are right. I will check this. However this parameter governs the reverse characteristics of one cell (the current for a given reverse voltage). It is not involved in the simulation process (or very very slightly in the Module Layout shading calculations, when only one corner is shaded). Its effect is visible in the pedagogic tools for the understanding the reverse characteristics of a cell/module.

This is quite normal. Evaluating the average irradiance over the whole day (including beam, diffuse and even albedo) is not intuitive ! As an example, in summer at these latitudes, the sun goes far beyond east in the morning and west in the evening: with planes as tilted as 30°, the sun is behind the plane or at very high incidences. This is a significant loss by respect to the horizontal irradiance, which is not affected. Using "Tools" / "Meteo tables and Graphs", you can plot the meteo data (Global horizontal, and Global on 30° plane), in hourly values. Please observe a clear day in June: you will see that the Global plane is slightly higher around midday, but significantly lower during the morning and the evening. And not very different for cloudy days.

I have just found a routine which is executed very often for a same calculation during the simulation. I never suspected this routine as it is a very simple one. This expecially affects the simulation of systems where the numerous tables are not grouped into arrays ("fields"), like in the Helios3D scenes. Correcting this substantially reduces the execution time of the simulation when using the Shading factor table. This correction will be included in the next version 6.31, to be released soon.

The cable diameters is only a "help" (or additional information) for the calculation of wiring resistive losses. The relevant parameter is the wiring resistance. This is the only parameter used for the wiring loss calculation. For big or complex systems you are advised to calculate it by your usual calculation methods, without relying on the PVsyst propositions.

Defining such a number of slaves doesn't make much sense. With 2 inverters in Master/Slave, you gain a little bit because of the better efficiency at low powers (less than 1 to 2% with bad inverters) With 3 inverters, the gain is imperceptible. Beyond this number it is completely useless. Using Master/Slave configuration is not harmless: it forces to connect all concerned sub-arrays in parallel. This is not necessarily a good idea. NB: In your case you can define 2 x 6 inverters in master/slave if you want: the simulation result will be exactly the same.

I don't remember when I had done this correction (probably in an earlier version). Please try to update. If this error persists, I don't have an explanation. Please send me your full project, using "Files" / "Export projects" in the main menu. However such a discrepancy on only a very few of hours should not produce a big error.

Yes, I have just discovered an error in the interpretation of the UT when importing some Helioclim data files. This will be corrected in the next version 6.31. In the mean time you can send me the original Helioclim file, and I will create your MET file (send it to support@pvsyst.com).

I have increased the number of decimals for the settings of the muPmpp value. However I don't intend to allow the explicit specification of muGamma as it is not a "physical" parameter.

No I did not yet perform this correction. However its effect should be very little. But I don't understand what you are trying to calculate: the U value is an input parameter. On which data are you calculating it (i.e. which Tarray are you using ? ). PVsyst doesn't make a difference between Tcell and TArray: if there is any, it will be included in the U-value. If you have TArray measurements, you can plot (TArray(meas) - Tamb) as a function of GlobInc. Then you can obtain the U value by a linear fit on your data, and by identification of the slope to the energy balance equation: Uc = Alpha * (1-EffArr) / Slope

Yes, if your module has not an explicit specification of the Rserie in the database, this is certainly the effect of the new default choice for Rs, according to the relative efficiency instead of the diode quality factor. The value of Rserie may also have an effect on the temperature behavior if muPmpp is not explicitely specified. Try to resimulate with a same fixed Rserie.

Your calculation seems to be correct. I can't understand that this is depending on the pitch of the modules: it is completely unrelated. However for the sunrise and sunset hours, the solar geometry is not calculated in the middle of the hour, but the middle of the interval between sunrise and the next hour. This may be the cause of your difference.

Which version of PVsyst are you using ? I had corrected the little discrepancy (0.7%) - which was due to a calculation artefact - some months ago.

The near shadings strongly depend on the spacing you have specified between your trackers. Please see the animation in the 3D editor for understanding the behavior of your system.

The best way for understanding this and identifying a parameter is to put a big value to this parameter, and observe the effect on the drawings.

I don't know if some modules of this technology are already commercialized. There is noone in the database of PVsyst.

If you have a big system (big shading scene), please check that - You are not using the calculation mode "Slow", which calculates the shading factor at each simulation step. - You are not using the "Module Layout" option, which is not suited for big systems (see Big systems calculation in our FAQ) Please also check that in the 3D editor, the menu option "Tools" / "Optimized calculation" is checked. The simulation may also be slow if you have a very big number of inverters.

Thank you for this remark. I will correct this.

Yes it is taken into account. The PR is based on the E_Grid value.

This is an interpretation of the muPmpp value, as specified on the datasheets (and usually on test reports) and representing a linear behavior. This new interpretation better matches the supposed linear behavior of the Pmpp. I doubt that many manufacturers have optimized this parameter in order to better match the simulations in PVsyst. Now PVsyst is an evolving program. We try to improve the simulation when we discover some weakness. If the results should be always quite stable, there were no more room for improving the simulation and the program would be frozen. NB: If you want to avoid this modification, in the Hidden parameters you can set the parameter "PVModules" / "Upper reference temperature for muPmpp default" = 25°C.

You can follow the Tutorial within the software (just below the help menu).

There is no tool in PVsyst for getting the "average" shades at each position of an area. However in you case, you can run the simulation, with the "Slow" option (calculation of the shading factor at each step, without using the table), and produce a CSV file with the Hourly values of the height and azimuth of the sun, and the shading factor. The hourly Shading factor will give you the number of hours with shadings. In the batch simulations, the only parameters of the 3D scene which may be changed are the pitch between rows and the plane tilt.

We have not yet taken the time to update this. It is a secondary question on our ToDo list.

This should be 1 indeed. There may be some artefacts in the diffuse integral calculation, especially if you have additional shading effects.

Yes of course. In a general way, when I add a functionnality I keep the existing (and pertinent) ones. This will be an additional option in the Grid Power Limitation management.