André Mermoud

This sentence is meant for the irradiation, as the PR is referenced to GlobInc. The PR is obviously related to the temperature. But this is a second-order variation when comparing systems in different locations (same region) or different orientations.

You can use a not-null longitude value. Remember that 1 minute represents less than 2 km. This is completely negligible for the use of PVGIS values.

Yes you can import POA measured values in PVsyst. Please use "Databases > Import ASCII meteo Files", and press F1 for the procedure. The format protocol includes the possibility of reading Global Incident values and PVsyst will perform a retro-transposition.

The difference between Central and distributed inverters is not quite clear. An eventual cloud effect difference is probably completely negligible, as the mismatch between strings under different irradiances (different currents) is very low. In the present time, PVsyst doesn't show any difference between these 2 options, except if you carefully specify the DC wiring losses in each configuration. A difference may perhaps occur because of a mismatch due to the string's lengths in central configuration. This problem is under investigation.

It is no more possible to create a site for your project from the Project's dialog (button "Site and Meteo"). PVsyst now requires that you create and save your Project's site within the database ("Database > Geographical site").

This error message "The shading table has not been computed" appears here by mistake. In fact the shading table is correctly computed at the beginning of the simulation, which arises after this check. This should be corrected in the next versions.

This is quite normal. If you have a grid limitation, the inverter works more often in the lower part of the powers, where the efficiency is different. When analyzing your hourly values, you will see that hours without power limitation have the same efficiency.

This is indeed a limitation of PVsyst. You can only define a sub-array with Mixed orientations for the Orientation #1 and #2. I don't see any workaround except trying to avoid the use of mixing on a third orientation, by distributing the strings differently on your MPPT inputs.

When creating a new calculation version, the voltage drop in the series diode is initialized at a null value. The default value of 0.7 V only appears if you ask for this (click the checkbox). In old installations people used to include a blocking diode in series with each string, for avoiding reverse current from neighbour strings in case of mismatch. However this is useless as even when a string is almost completely shaded, its voltage remains close to Voc. Moreover, these diodes were subject to failures, which were not always detected. To my knowledge, nobody uses such diodes anymore nowadays. These diodes have nothing to do with the by-pass diodes, which are quite necessary for the protection of modules against Hot-spots. All crystalline modules do have such diodes. These diodes are completely inactive in absence of serious mismatch conditions (partial shadings).

You can use the Batch Mode, and perform a simulation with different Site and Meteo data files. However, it is not possible to start a simulation just by specifying the Latitude/Longitude. You have to explicitly construct each geographic Site and each Hourly Meteo file in the database.

The data specified at the beginning of the loss diagram is the Irradiation on the Horizontal plane. This is taken from your Meteo hourly file *.MET The data in the orientation of the optimizing tool is the Irradiation in the plane of the array. It is normally different. But in this particular case the plane is horizontal, so that it should be identical. For technical reasons, the Meteo data used for this optimization tool are taken from the Meteo data of the site you have specified in your project. As I understand you have imported data from Meteonorm and from NASA. Probably the Project's site data are from one source, and the meteo file *.MET is from the other. NB: the values provided by the orientation optimizing tool are marginal in the software: they are just here for an estimation of your orientation with respect to the optimal, not for an absolute irradiation evaluation.

I didn's say that the transformer loss is not significant of course. What I meant is that the choice of the STC PnomAC has not a significant effect on the evaluation of the transformer loss.

This is not yet implemented. See our FAQ Can I include a battery in a Grid-connected system ?

As you pointed out, when not present in the data the DHI is evaluated using the Erbs model. For the very high zenith angles (low sun height on the horizon), the DNI is indeed not well defined. If its value becomes too high from the GHI/DHI values, it is limited to the clear day model. This is especially the case when importing POA values. If the time definition of the data doesn't correspond to the time used for the calculation of the solar geometry, we can have very high uncertainties in the morning or the evening. This is the reason of the "Time shift" correction in PVsyst.

This was indeed an error in the version 6.46 (only this version), which has been corrected in the next versions.

Yes if you want. But this has a very weak significance: the STC PnomAC value is just here for a definition of a Reference Power.

You are right. By definition, with backtracking there is no mutual shadings for the beam component. Therefore the "Linear shading loss" will be 0 for the beam component, and defining Electrical losses is not necessary.

In PVsyst, a sub-array concerns one (or several) MPPT inputs. Each sub-array is supposed to be "homogeneous", i.e. same PV module, same number of modules in each string. Therefore you cannot simulate these situations in detail and rigorously with PVsyst. For the mix of different modules, you can eventually define an "average" module with the STC characteristics (Pmpp) corresponding to a weighted average of your modules distributions. Or you can also redefine your inverters as several "dummy" Multi-MPPT inverters, to be attributed to different sub-arrays with different kinds of modules. If you have 10 inverters, you can simply define different sub-arrays, each with an "homogeneous" set of modules. NB: mixing strings of not too different modules in parallel should not induce significant mismatch losses. The mismatch loss in voltage (parallel strings) is usually very low.

The PVsyst simulation only works in hourly values. If you have sub-hourly meteo data, you can import them in PVsyst (using "Tools > Import ASCII meteo files"), but they will be converted into hourly values.

For the Batch mode, each parameter should be explicitely specified in the programming. We did not implement this for monthly soiling. This is not really easy in this case, as this represents not one, but twelve parameters to adjust.

You cannot do that. The efficiency is a "little" correction to the Thermal energy balance. The U-value is a rough estimation of the themal balance, with a high uncertainty. If you try to estimate the efficiency from the temperatures, the uncertainties on the U-value - and the temperature instantaneous values - will give completely erratic efficiency values.

No sorry. This is not possible in the present time with PVsyst. The "Tools > Tables and graphs of Solar parameters" don't include tracking angles yet.

The overpower temperature dependency is referred to the inverter temperature. Now you can specify the inverter temperature behavior during the simulation (ambient temperature, ambient with shift, fixed room temperature) in the "Miscellaneous tools", page "Inverter temperature"

The main differences between these different runs probably come from the Diffuse part in these data. The transposition (i.e. the GlobInc/GlobHor ratio) is highly dependent on the Diffuse fraction, whatever the model used.

All the versions of PVsyst are compatible with Windows 10.