André Mermoud

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.

This tool shows the evolution of the yearly production, as a function of a fixed array voltage kept constant all over the year. It is very specific, when you have some converter with a fixed input voltage, to adjust for using a PV array.

Please check that you have not defined "Unavailability losses" in your project.

Please chack that you have not defined "Unavailability Losses".

The problem with the PVGIS API change has been solved in the latest version 6.87. This version is available for any user who has upgrade rights up to December 17th, 2019.

I don't know. Please send us your whole project, using "Files > Export project" in the main menu. Send it to support@pvsyst.com.

I don't know. It is strange ideed. Perhaps the simulation has been reexecuted between both outputs ?