André Mermoud

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.

The required temperature (for the one-diode model) is indeed the Tcelll. However this is highly dependent on how you are defining (measuring) this back temperature. You will have a difference between TCell and Tback only if you have a heat flux. If you just glue a temperature sensor to the back side, you will indeed have a heat flux towards the outside medium (convection, radiation). In this case the difference will not be "3°C", as many people think, but a difference which is proportional to the (Tcell - Tair) difference (i.e. the irradiance), according to the heat resistivity of the back side (may be different with a plastic or a glass back coverage). If you cover your sensor with an insulation, you will limit (suppress) this heat flux, and you will effectively measure the cell temperature. Now if you put too much insulation, you will modify the effective equilibrium temperature of the cell at this point. At the University of Geneva, we did a comparison with a special module equipped with a thermocouple within the encapsulation, and several ways of measurement. We found that the best compromise was to cover the sensor with a polystyrene piece of about 7 x 7 x 1 cm. Please see the FAQ How is evaluated the module temperature during simulation ?

No, the SHD files connot be exported to Helios3D (nor any other graphic software).

Yes sorry, this is an known bug in the version 6.64. This will be corrected for the next version. In the meantime, you should use an older version for seing this graph.

For the backtracking calculation, this is not only a lack of PVsyst, but a real problem. The first thing is to think about how to define the backtracking with uneven PV trackers. The backtracking limit will be different for each tracker, and the exact calculation implies an interdependence between the trackers.

These curves show irradiance on the rear side, with respect to GlobInc. These are the result of a full year simulation for your meteo data. NB: We estimate that the Bi-facial model is suited for tilts up to, say, 35 to 40°. We don't know to which extent it remains valid for higher values.

The tracking is not developed in the "Preliminary Design" tool. However please never use this "Preliminary Design" tool for a detailed study of a PV system ! This is a very rough tool, only suited for an architect who wants to evaluate the PV potential during the pre-study of a building.

Are you using backtracking ? There were indeed several issues in the version 6.52, for tracking systems in some special configurations (pairs of 2 trackers, axis orientation). I should have a look on your project to identify the exact reason. But to my knowing the result of the V 6.63 should be correct.