André Mermoud

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.

In the present time the limitation is applied to the inverter output. Therefore all losses after the inverter are effective losses. Now technically, this is probably a current option in the reality, at least for systems with a single inverter. Clipping the power at the injection point would imply that the power effectively measured at the injection point level would be communicated to the inverter's electronic control for adjusting its exact operating point at each instant. See the previous discussion Grid Power Limitation about this subject.

No, the PVsyst file organization is not customizable. You have to manually remove (or displace) files if you want to avoid them from the componernt's lists.

This file is in your installation location: C:\Program Files (x86)\PVsyst6.2.9\DataRO\ It will be recovered when you will update or reinstall PVsyst.

PVsyst checks that you have defined sufficient area in your 3D scene for placing all the modules you have defined in your "System" part.