André Mermoud

In principle, in recent versions, when you have meteo data created by original POA data, PVsyst doesn't allow to use the Perez model for the next transpositions. Using the Perez model should obviously give different results (not matching your input POA values).

Probably you have not specified the rectangles correctly ? In the option "According to module strings", button "Partitoin in module chains", one rectangle should represent a full string of modules, not one only module !

Yes, PVsyst treats the temperature of arrays according to the irradiance in each orientation. However the mismatch between 2 sub-arrays of different voltages is usually rather low.

The Voc is computed according to the one-diode model. However the temperature coefficient is not quite linear with the temperature. On the other hand, the values of the one-diode model are not necessarily conpliant with the value specified in the datasheets. Please see our FAQ How to adjust the Voc temperature coefficient ?.

Since the version 6.27, it is possible to specify a Maximal Power value (PMax), which may be higher than the PNom value when the inverter's temperature is sufficiently low.

The model doesn't "compute" wind speed of course, but it can use wind speed data if present in the meteo data. This is taken into accout through the parameter Uv in the Heat transfer parameters ("Detailed losses > Thermal parameters"). Now the Wind velocity values may be read in hourly values in your imported data when available (including from Meteonorm). If they are specified only in monthly values, PVsyst is not able to generate synthetic hourly values (we don't know any model for that). In this case de specified monthly values (averages) will be used during the simulation. But sorry, we don't have really reliable values to propose for the Uv parameter.

In the simulation results, you havs always the same "Shading loss factor" in the irradiance losses. This corresponds to what I name "Linear Losses", i.e. the losses due to the irradiance deficit. Now when you define shadings "According to module strings", you have an additional loss named "Shadings: electrical loss according to strings" in the Array losses group. This is the effect of the electrical mismatch.

When using the "NetMetering" option, you should specify the energy user's needs (the self-consumption). You have several way for doing that, including the option "Load values read on ASCII file". Here you can prepare a CSV file (for example in EXCEL) with hourly values. Sorry, in the present time the sub-hourly values (for example values by 15 minutes) are not treated. You have to construct a file (in EXCEL) with corresponding hourly values. This will be available in a next version of PVsyst.

This is indeed the case when you choose "Monthly normalizations": in this case the daily sum should indeed match the pre-specified monthly value. For the monthly sum you should specify the exact waited daily sum (i.e. 12 * 2.77 + 12 * 2.0 kW). Now this will no arise with "seasonal modulation" or "constant over the year, where the daily sum is not predefined.

Getting shading losses for backtracking is quite normal. Please see our FAQ How is calculated the Shading Loss on diffuse with tracking systems ?

The statistical distribution underlying the P50-P90 concept applies to a set of years. If you have a TMY meteo data year, you will get a result corresponding to P50. But you cannot define a P90 value without further information about the statistical distribution of several meteorological years for this site. The Average and Variance for the P90 definition are averages over several years. It has nothing to do with the hourly distribution. Now defining a P50 or P90 value for the year 10 or 20 or any other one doesn't have any meaning. The P90 yield for a given system, means a probability of 90% that the yield of any given year is above this value.

[EDIT] With recent versions of PVsyst you should be able to use your licence the same way. You may just need to synchronize it through the menu "Licence -> Status and activation" after your upgrade.

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.