André Mermoud

The use of Y-connectors is not involved in PVsyst in any way. With some inverter, the number of input connectors is specified. But this is not used by PVsyst. The only relevant information is the number of strings effectively connected to the input of each MPPT input. PVsyst doesn't check if this matches the number of connectors. For the use of the option "Use multi-MPPT feature", please read the Help "Project design > Grid-connected system definition > Multi-MPPT inverters: power sharing"

The mismatch effect is calculated by adding the I/V curves: - In the string (modules in series) we add the Voltages - In the array (several strings in parallel): we add the currents of each string. Now the result of the mismatch loss is the difference of the Pmpp of the complete array curve with respect to the Pmpp of identical modules. The position of the Pmpp (voltage or current) on the curve is "unpredictable". Sometimes you can have 2 different maxima on the P/V curve. This is deeply explained in the tool "Project's dialog > Detailed losses", page "Module quality - LID - Mismatch", button "String voltage study > Detailed study". Especially the first option "Mismatch: General principles". Here you can press F1 for an explanation of the mismatch issues.

This is indeed a delicate question. The PR is defined on the basis of the GlobInc value (i.e. irradiance in the collector plane, also named POA for "plane of Array"). Therefore is seems natural that for the PR evaluation, you measure the irradiance in the POA. However be careful to put your solarimeter in front of your installation (on the first shed), or eventually significantly above, otherwise it will not "see" the albedo contribution, and may have some shading on the diffuse from other sheds. NB: Even if the albedo is not "seen" by the sheds behind, it should be part of the "official" GlobInc. This is taken into account in the transposition model and simulation. But it can also be interesting to measure the irradiance in the horizontal plane, with a solarimeter positioned sufficiently high. In this case you have the uncertainty of the transposition model for obtaining the GlobInc value. However this is more comparable with usual Meteorologic data. Moreover this is valid if you have several plane orientations in your system, for which you will have "transpositions" calculations suited for each orientation. For tracking systems, many people use to position the solarimeter on the axis. In this case the mutual shading of trackers (on the diffuse and albedo) are not part of the measurement (i.e. the measurement is affected by this shading), but they are accounted in the simulation process. Therefore this POA value is not really the waited value for the simulation. In the present time PVsyst doesn't give the opportunity of suppressing the mutual shadings calculations (usually a loss of the order of 2-3%). We should do that in a next version for simulating systems from this measured (but erroneous) POA value. Without this correction, when you resimulate your system the E_Grid will be lower, as the Shading loss is accounted twice. Therefore for comparing this E_Grid to the E_Grid provided by your original simulation, you should multiply it by (1 + ShdLoss[%]/100). The PR that you directly calculate from your measured data is PR_meas = EGrid_meas / (PNom*GlobMeas). However for comparing it to the "real" PR originally calculated using GlobInc, you should use PR_meas = EGrid_meas / (PNom * (GlobMeas *(1 + ShdLoss[%]/100) ).

Defining the south at top in the southern hemisphere is a choice of PVsyst. This is natural as the installations (tables) are oriented towards north. In this way you see them from front. If you define the north at top, in the perspective views you will see the PV installation from its rear side.

No, only global values for the whole system are outputted by the simulation.

There is no direct way. If Helioscope can issue files in DAE format, you can import them in PVsyst. But this will only concern the 3D geometry, not the other features of the PV installations defined in Helioscope (like PV modules, wiring, stringing, etc).

Irradiance treatment: circumsolar The treatment of the irradiance has indeed been improved. We now distinguish a new irradiance contribution: the circumsolar (enhanced irradiance in a crown around the sun). This contribution was previously included in the Diffuse component, and treated as such in the shading calculations (i.e. isotropically). It is now evaluated from the Transposition models (i.e. proportional to the beam component) so that we have now 4 irradiance contributions: Beam component, circulmsolar, isotropic diffuse and albedo. In the shading calculations and IAM, the circumsolar is now treated in the same way as the beam (i.e. coming from the direction of the sun). This means that the Shading loss on isotropic diffuse is lower, and the shading loss on beam + circulsolar is higher. For the linear losses, these loss contributions approximately compensate each other. But the Electrical shading losses are only related to the beam, and are therefore increased. NB: These improvements are not so important in usual systems. They become crucial in vertical bi-facial systems modelling, for the evaluation of the back side irradiance. This explains the differences of the simulation, in the optical contributions in the losses (shadings and IAM). Low-light efficiencies: The default values of the Rserie and Rshunt PV module parameters is assumed to ensure a low-light relative efficiency of -3%@200 W/m2, with respect to the STC. However in the Version 6, this value was not always attainable (sometimes -4 or -5 %). This may be improved by încreasing the Rshunt, which was not done correctly in the version 6. The new version 7 ensures that the low-light performance is -3%@200 W/m2 in any case.

For the barttery system management, you have - losses of the charging device (AC > DC converter) represented by an efficiency curve as for inverters, - losses of the battery itself (difference Charging / Discharging energy) - losses of the inverter device, - all losses at the output of the inverter may also be specified (AC wiring, transfo losses) in the same way as for a usual system.

Yes you can define a terrain by (X,Y,Z) coordinates. See the help "Project design > Shadings > Near Shadings: Import > CSV Ground data" And you can distribute PV tables on it.

PVsyst doesn't take the MPPT tracking losses into account. This is extremenly dependent on the inverter's technology, and the manufacturers never (or almost never) give information about this performance. If you want to take it into account, you have to include this loss in the inverter's efficiency.

This is the result of the full simulation process, in hourly values during a full year. With models for the irradiance on the PV modules, the production of the PV array, the inverter's behaviour, calculation of losses like shadings and all other losses mentioned on the loss diagram.

Yes sorry, this is a bug that we have just discovered yesterday. If you are using a Version 7.0.0, please install the patch 7.0.1, released today.

This is a property of the inverter. If the PNom is specified as apparent power [kVA], you should define "Inverter PNom defined as Apparent Power" in the Miscellaneous tools of course.

When importing POA data, the aim is to find GlobHor and DiffHor values wich will restitute the exact GlobInc corresponding to your input data (with the same transposition model). Now this calculation (transposition) involves the solar geometry. Therefore the time of your data should match the time at which PVsyst will calculate the solar geometry. You have to specify the TimeShift for getting this match. Please use the tool "Databases > Meteo Tables and Graphs > Check Data quality". And carefully read the help "Meteo Database > Notes on Meteo > Meteonote9_Time shift in imported meteo files". As far as you don't correctly define this match at the import time, your data will be incorrect, and you will have discrepancies either in the morning or in the evening, depending on the sign of the time shift.

Internally, PVsyst dosn't use the Daily Saving Time. As in most of PV softwares, the *.MET files always use the winter time. Now when importing meteo data files which take the DST into account, you have to mention this in detail in the Importing protocol. See the help "Meteo Database > Import custom meteo files > conversion protocol" Most of "official" meteo data don't involve a DST. NB: It is very important that the Time shift is correct all over the year. You should check this using "Databases > Meteo Tables and Graphs > Check Data quality". And press F1 for getting the help "Meteo Database > Notes on Meteo > Meteonote9_Time shift in imported meteo files" The Diffuse model is highly depending on the Time shift, as defined during the importing time: if this is erroneous, the diffuse is false.

Remember that the file format has changed with the version 6.80. Any components created with a version >= 6.80 cannot be read in previous versions ! This is the problem of all questions above.

The UArray is depending on the PV modules temperature. But it is also depending on the operating conditions: in all the hours shown, the system is not working so that the voltage is at Voc. The point for 21/06 at 18:00 is the only one above the operating threshold, therefore with system in operation (UArray = Vmpp).

Yes there is a batch mode. Please use the button "Advanced simulation > Batch simulation", and press F1 for the procedure.

The format has changed with the version 6.80. You cannot read files created with versions greater than 6.80 in versions lower then V6.79.

It depends on which version of PVsyst you are using. For the first question: Defining 1 kW for the grid injection limit is not really the right way, as the process for handling the losses after the inverter is not simple, and may lead to uncertainties if the difference between produced and limited power is too high (because it involves quadratic ohmic losses). For this situation, the best way is to let the energy be delivered to the grid, and consider that the injected energy is indeed unused energy. In the latest versions, you have the option "Allow solar injection into the grid". For the second question: This depends on the version you are using. There was probably a bug concerning this in an previous version, I don't remember well.

I don't know. When you calculate the average efficiency (from the hourly CSV file?), don't forget to weight each houtly point by the EOutInv value.

Thank you for this information, we will check this for the next version.

Please send us the corresponding *.DAM file. We will check what arises with this file. (support@pvsyst.com).

We will check this. I think it is already corrected. In the meanwhile please modify anything else and PVsyst will ask for saving.

Sorry, I did not know the existance of this norm. However, I don't know the effective difference between the bifaciality factor of ISC with respect to the bifaciality factor of Pmpp. No manufacturer has never mentioned this difference, they only specify the factor for the Pmpp (when they specify it... which is not always the case). NB: several datasheets mention a table of power increase for the bi-facial yield, but without mentioning the corresponding irradiance conditions. Therefore these data are completely useless. However they usually give a stable Vmpp voltage for all powers, which indicates that the bifaciality of Pmpp is identical than the bifaciality of Isc. I don't have any information about the LID effect on the bifaciality factor. Please ask the manufacturers.