André Mermoud

You are probably using an old version of PVsyst. I have corrected this since a long time. Please update.

The only way is to update your PVsyst to a newer version. Or ask the provider to create the file with the option "compatibility with old versions".

I have tried your configuration and everything is OK (Global Inverter's power = 72 kW, and PNom ratio = 1.22). Now I observe on your picture that your inverter is not from the PVsyst database (grey background). Please check its parameters (namely the PNom AC value).

There are still very few bi-facial modules in the database. Only one or 2 manufacturers have proposed such modules up to now. For your first tests, you can open any usual module, and transform it as a bifacial module by defining a not null bifaciality factor (in the PV module dialog, page "Size and technology").

If you don't explain what "is not good" in the data, I can not say much. Probably the recording time is not the same as the time of PVsyst. You should apply the "Time shift" correction as advised by PVsyst (in "Databases > Meteo Tables and Graphs", page "Check Data quality"). With 1-minute data, you can also shift the dates column in your source file, in order to match the time of PVsyst (add or suppress some minute cells at the beginning of the column)

On request of SolarEdge, the reference Power for the evaluation of the maximum power is not the STC, but the maximum power attainable on the concerned site and for the concerned orientation. Therefore the maximum number of Optimizers is not an absolute, it may be different from project to project.

Yes, the presizing tool in not suited for such a calculation. It is a quick tool for "usual" stand-alone sytems, where the normal autonomy is of some few days. The error is that this specification is allowed.

The old tool concerns mismatch between individual modules. For the current, the mismatch is mainly due to the worst current module in each string. For the voltage, the differences in voltage add-up for each module, this means that if you have a given RMS distribution for all modules, the voltage difference for a full string will statistically be RMS / sqrt(n), where n is the number of modules in series. So the mismatch in voltage between strings is much lower. The new tool aims to evaluate the mismatch in voltage between strings. When dealing with string voltages, the average power loss due to the mismatch is the difference between the sum of the MPP powers of each string, and the effective resulting voltage when mixing the I/V curves. Here no effect of the "worst" string: the mismatch loss is much lower. These voltage mismatches may be due to: - RMS values of individual modules (evaluated in the previous tool), - Array temperature differences, - Wiring resistances of different string lengths. This tool tries to give ways for the evaluation of realistic wiring resistances according to the tables layout and inverters position.

The cell temperature is equivalent to the array temperature, the variable is named "TArray". During the simulation the TArray is evaluated at each hour using the Energy balance described in the help " Project design > Array and system losses > Array Thermal losses"

You can indeed create a Meteo file (*MET) of clear days for your simulations. In "Databases > Import Meteo Data", the last data source is the creation of such a file.

I don't know such problems when setting the SOC values in the Controller's parameters and saving it as a new component. Remember that you can specify the controller's thresholds either as Voltage or as SOC. However with the Voltage specification, the corresponding SOC will depend on the Battery voltage model. Please explain exactly: - with which version of PVsyst, - how you modify/save this component, and which component ? - what is not correct. NB: The SOC thresholds of the controller are used during the hourly simulation. The pre-sizing tool uses a specific value for the disconnect SOC threshold, which is specified in the Hidden parameters, page "Stand-alone System Pre-sizing", item "SOC minimum threshold".

This should represent the energy effectively removed from the PV modules (cell), i.e. the efficiency after irradiance and temperature losses. Now as I previously said, little difference don't have any impact in the expression.

This is indeed the result of this Mismatch calculation: such a low discrepancy in modules provides extremely low mismatch (it is not linear). Now what is the reality ? 0.3% RMS means 0.9Wp for a module of 300 Wp. This is a "sub-class" of the usual class powers (0..5Wp). The PV modules are indeed measured at the factory output, and "sorted" in order to get the sample with measurement results (on the paper) as narrow as possible. But what is the meaning of these measurements: - According to all Flash-test manufacturers, the accuracy of these instruments cannot be ensured with a better accuracy of +/- 3 % (for usual accuracy classes), - Probably all the modules don't degrade quite uniformly with the LID. Therefore I really doubt that the real performance (not the Flash-test result) of each module can be ensured to stay within RMS = 0.3% when installed in the system ! This is the reason why PVsyst proposes a default value of 1% (many other people/software propose 2%). Probably nobody knows the exact reality.

This problem has indeed been corrected for the next version 6.65, to be released soon.

See our FAQ How to interprete the warranty curve of the manufacturers?

This is a question of definition. I don't know if there is an official answer, but due to the difficulty of evaluating the rear side irradiance, I really doubt that this is a good idea.

Yes, I just discovered two errors in the SolarEdge new treatment with ageing: - The Module parameters ageing dispersion cannot be null, as fixed as default for optimizers. Please fix a little value (0.1% sufficient). - With very high electrical shading losses, the long-term shading evaluation (ModuleLayout) is overestimated.

In some applications outside of the simulation, this is a "standard" value (in the hidden parameters). During the simulation, PVsyst estimates the efficiency of the module with an initial efficiency, and then uses it in this expression (one iteration). By the way this value has a very low impact in the U evaluation: a difference of 1% (in efficiency) will give a difference of 1% on the U-value or the Temperature difference, i.e. 0.35°C if you have a DT of 35°C. The U-value has a very high uncertainty (5 to 10% or more if not really measured).

There is a new very detailed tool in the version 6.64, which addresses these questions of Mismatch between strings ("Detailed Losses > Module Quality - LID - Mismatch", button "Detailed Study"). The main conclusion is that the mismatch between strings of different currents (but comparable voltages) is really very low.

No, this is not possible in PVsyst.

There will be a detailed tool for this determination in the next version 6.65.

Yes it is correct. As mentioned in the dialog, the connexions between Boxes and Inverters should be counted as twice the distance (i.e. the total wire length).

The limit for the lower temperature is defined in the Hidden parameters, topic "Miscellaneous: Meteo, Simulation, ... ", item "Lower limit for monthly temperatures".

This is quite normal. The produced energy at the output of the inverter is the Active energy. The treatment of the Power factor is explained in detail in the Help, or in the FAQ Can I define a Power Factor in PVsyst ?

The data files of PVsyst are now text files. But they are not meant for a "public" use: the structure is managed by PVsyst, and may change according to conditions and data availability.