André Mermoud

You can try to import this device from PHOTON if it is existing there ("Databases > Inverters > button "Import from PHOTON"). You can also create a new component from scratch, using the infomation of datasheets. But the easiest way is to open an existing similar device, modify its parameters according to the datasheets, and save it under a new file name.

This is a basic EXCEL functionnality. EXCEL is not able to recognize the separator by itself in a text file. Please use the function "Data > Convert" in EXCEL, and choose "Semicolon".

We have already done this in the "Optimization" tool, which makes use of the batch mode. We will think about such a possibility for usual batchs.

Do you really think that after developing PVsyst during 25 years, I am so debutant in programming techniques for accessing the meteo file at each hour ??? The files are accessed once for each run, but this time is completely negligible with respect to the simulation duration. We have recently discovered that our calculation time problems with complex shading scenes are essentially related to the creation/destruction of many little objects (like 3D points, rectangles, etc) during the process. In the next version 6.40, we will propose a new calculation of the shading factor with a significant improvement of the calculation time.

You have defined an area for positioning you modules, which is far greater than the PV modules themselves. Therefore the shading calculation - which is referenced on the sensitive area - may not be accurate. You can overcome this warning (or error) in the Hidden parameters, topic "Detailed Simulation Verification Conditions", item "Shadings: Absolute Maximum Shading/Field area Ratio".

The light soaking appears after some time of operation (otherwise it would be included in the STC performance). So that these 2 different "loss" contribution are independent. Therefore they are cumulative. If you assume +0.8% of "Module quality loss" for positive sorting, and +2% of Light soaking, the global gain after some months of operation will be +2.8%.

In the transposition models used by PVsyst, the albedo contribution on a plane corresponds to a reflexion of the terrain areas far from the installation. The very near albedo is probably negligible, and indeed not taken into account explicitely in the model. Therefore the height of the PV array is not really significant.

In the mixed arrays (heterogeneous fields in version 5), the calculation of Pmpp is indeed very different than for a single array: we have to establish 2 I/V curves, mix them and identify the Pmpp of this resulting mixed I/V curve (approximation). In practice, when mixing different I/V curves with different currents (but about the same voltage), as this arises with mixed orientation, we observe that the result is very close to the sum of both Pmpp. That is, at comparable voltages the mismatch loss is quite negligible (this appears in the loss diagram of the version 6, and is always almost null). Therefore a little discrepancy (error) in the calculation approximations may indeed lead to a better performance - but not significant - in mixed orientation.

For comparing results of different runs, please use the "Array loss diagram". This usually immediately indicates where is the discrepancy. As I saw on your data, there is indeed a problem with the calculation of the SolarEdge configuration in the version 6.34. We were not aware of this error up to now, and I don't know the cause. However this doesn't happen anymore in the version 6.39.

Sorry, I don't see where you find this information in the simulation report. This may indeed appear under the "Shading table" and the "Isoshading" diagram. For fixed orientation systems, the shading factor for Diffuse and Albedo are fixed values (result of the integral of the Shading factor for all sky directions), and calculated from the Shading Factor Table. The problem with tracking systems, is that this integral should be calculated for each plane orientation. That is, the Shading table should be established for each orientation. This is done within PVsyst for some few orientations (7 with tilted axis) , and the simulation will interpolate between these attenuation values according to the tracker's orientation. But this is not shown as a result. The Attenuation factor for diffuse and albedo calculated from the shading table (with rotating trackers) doesn't have any signification. We should not show these values.

In the "Orientation" part, you have to choose "Tracking, tilted or Horiz. N-S axis", and set the axis tilt = 0. And you should define corresponding Tracker arrays in the 3D shading scene.

You should in principle not change the Rshunt value. The default value of PVsyst is rather realistic. For the Rserie, which is closely related to the low-light performance: if you avail of Low-light efficiency reliable measurement you can adjust the Rserie accordingly. Otherwise you are advidsed to keep the PVsyst default values (checkbox on the right of the edit box). Please see How should the Rserie value be specified? in the FAQ.

The values were indeed random in the version 5, with the algorithm of PVsyst. This resulted in a variation of about 0.5% to 1% annually with grid-connected systems (may be more with stand-alone systems, where non-linearities are higher). Now PVsyst uses the algorithm from the Meteonorm DLL. In this tool they have chosen to always take the same initial number for the random generator. We have asked them for the possibility of changing the random generator initialization. However we did not yet implement this in PVsyst.

There is probably some point of the efficiency curve which overcomes the limit. In the Hidden Parameters, topic "Regulators and converters", you can adjust the "maximum value of the Max. Efficiency". However the actual value of 99.5% is already very high. I have some difficulties of imagining attaining better performances.

Nothing has been removed. I just checked and everything is OK with these results. Please make sure that you have effectively defined shading losses in your simulation.

Sorry, I don't find this inverter in the database of PVsyst. There is probably a too hig efficiency point in their data. In the Hidden parameters, topic "Regulators and converters", you can adjust the "Maximum value of the Max efficiency".

There is no limit to the number of tables. However with systems overcoming dozens of MW, the calculation may become very long. I don't know which modfications you have done in the Helios3D scene, and which kind of crash you had. Perhaps it was just a very long calculation time. For each modification, PVsyst has to perform some checks which may take a prohibitive time with very big systems. One workaround could be to check the option "Tools > Ignore Interpenetrations of PV fields" in the menu of the 3D editor.

I don't understand what you mean. In the version 5, as in the version 6, the maximum power of the inverter is obviously taken into account in the simulation process: the excess energy will appear as "Overload Loss". Plese see Can I define a system with Highly undersized inverter ?

This tool is only a guide for helping you when choosing an orientation. It is based on a very quick and rough calculation from monthly meteo values. I don't know why you have such a difference: perhaps before the simulation the calculation was based on the Project's site, and after on the Meteo hourly file (according to its availability at the calculation time). Or perhaps you have changed the transposition model from Hay to Perez. By the way these rough values are not involved in the simulation process in any way. They are only indicative. If you want a better orientation optimization tool, please use "Tools > Transposition factor" which provides a detailed calculation based on a hourly meteo file. However if you have shadings (namely in a rows arrangement), please remember that these optimizations are no longer valid. In the case of rows, you should use the button "Optimization tool" just before the simulation.

We consider that defining the angles with 0.1° accuracy doesn't make much sense, neither in the reality nor for the simulation results. Did you ever try to position a solarimeter or a module with an accuracy better than the degree in the space ? This is very difficult indeed without sophisticated scientific instruments.

This is not an error. In the "Module Layout" part, where we are interested in filling an available area (called "table") with modules, the Module Layout working area doesn't represent the shading scene. Each table is shown in its own referential, and you can displace these tables as you like for "optimizing" the ease of use of this tool.

You are right. There is an ambuguïty here. Up to version 6.38, the check of the discrepancy between the Imp*Vmp value and the Pnom(STC) was essentially done as a warning, especially for measured modules, when the Gref and Tref are not the STC values. Since the version 6.39, PVsyst applies a "strict" check for avoiding that manufacturers use am increase of the Imp*Vmp value as a way of compensating the positive sorting. Please see Why is the Pmpp of my module different from the specified value ?. This limit of 0.2% is only applied to the modules specified with STC (Gref=1000 W/m2 and Tref = 25°C).

Sorry, this behavior is not implemented in PVsyst. I don't see any way how to do that with the present versions.

When you are in "Tools > PV modules", clicking "Export" will produce a message explaining that from now, you can select several modules at a time (using the Shift key, as usual).

The solution proposed by Jen H is quite correct. You could also define 2 sub-arrays, each with one MPPT input: one with 5 strings and one with 4 strings. This would be the solution if you defined groups of strings with a different number number of modules in series.