André Mermoud

Yes the sequence is correct. But at the point 3, the POA modeled should be equal to the input measured POA (within some few permille). If you observe discrepancies (in the morning or evening), this means that you have not imported your data correctly, or the data themselves are not correct. Please check your file in "Databases > Meteo Tables and Graphs > Check Meteo data", and here press F1 for explanations in the help (especially about the Timeshift).

Not directly in the report. The report has a fixed format. But the button "Monthly tables" allows to show (and print) tables of monthly values for any chosen variable among the simulation variables, including the PR.

You can now create a one-year Clear day meteo data (MET file) in "Import Meteo data", datasource "Clear sky model".

In the present time, PVsyst performs an irradiance correction for amorphous modules only. Spoectral effect is usually admitted as rather low in yearly simulations for crystalline modules. We will probably develop a possibility of taking a spectral correction into account in a next version, but not before several months. This is not in our first priorities. By the way such a tool will deal with spectral corrections models (as a function, for example, of the water contents of the amosphere). Now for the use of a reference cell, please see our FAQ For Meteo measurements, should we use a pyranometer or a reference cell ?

Sorry, in the present time PVsyst defines user's needs in terms of global load energy, and doesn't involve inverters. This will be developed in a next version.

No sorry. PVsyst works with one full-year entities or datasets, and never covers several years at a time. However, after importing your meteo data one by one, you can use the batch mode for performing the yearly simulations in a same run.

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.