André Mermoud

Yes sorry, this is a stupid bug in the version 6.73, which will obviously be corrected in the V 6.74. In the meanwhile, the only way for correctly defining this parameter is to revert to the previous version 6.72.

If you are licensed, you can get any old version of PVsyst from our web site www.pvsyst.com. You can install several versions of PVsyst in parallel on a same machine. All of them will use the same license, and may be run independently without interactions. But be careful: if you try to read a file created by a newer version, the file may be unreadable with older versions.

Yes sorry, this is a stupid but in the version 6.73, which will obviously be corrected in the V 6.74. In the meanwhile, the only way for correctly defining this parameter is to revert to the previous version 6.72.

For importibng your meteo data you should use "Databases > Import ASCII Meteo files". For the calculation of GTI (usually named POA, or GlobInc in PVsyst), you can use "Databases > Meteo Tables and Graphs". Here you can get tables in hourly, daily or monthly values, with the GlobInc values ("Global Tilted Plane").

For the orientations definitions in PVsyst, please see the FAQ PVsyst will not redfefine the azimuth you have chosen of course.

For limiting the power, you have to redefine your inverter ".OND file with a new PNom value. There is no way in PVsyst for limiting the inverter power (as there is probably no way in your physical inverter for artificialy limiting the power !). NB: The simulation doesn't check the output maximum current. If you overcome the specified value, it is probably either because it is not well specified, or your output voltage is too low. PVsyst doesn't manage the grid voltage.

The Rotation limitations are the mechanical constraints. You cannot overcome them of course. The "Phi limits" is the value for which the backtracking begins to be operational (i.e. when the mutual shadings begin). At any time, the Phi value will obviously be limited by the lower of these 2 limits. Now when the sun continues to go down, the backtracking angle will come back below 60°. You can visualize this behavior as function of the sun's position, in the "Orientation" part, "Horiz. axis Unlimited trackers".

This is not so simple. Even if some irradiance is reaching the array through the tree, remember that în a string, the weakest cell (lower irradiance) drives the current of the whole string. There is a high probability that one cell in a string is fully shaded, therfore blockîng the full string. In other words, you can have a reduction of the Linear shading losses, but an increase of the electrical mismatch losses. Moreover, you should define the period for which this correction would be applied. We don't intend to introduce such a complex correction in the present time.

With SolarEdge optimizers, the maximum power of a PV module is not defined as the Pnom (STC) nameplate value, as for any other sizing. It is indeed the maximum power delivered by this PV module over the whole year, for this array disposition, in clear sky conditions. This was a reqirement of SolarEdge people when developing the SolarEdge devices in PVsyst.

The integral supposes that the diffuse is isotropic, i.e. that the irradiance is the same whatever the sky direction. Now with a tilted plane, PVsyst executes the integral of the incident rays (for each direction "seen" by the plane", i.e. the orange slice between the plane and the horizon) affected by the IAM function for this incidence angle. This is not the integral of the diffuse, but the integral of the IAM effect (which is a relative loss). The effective results of this integral are indeed not very intuitive. I don't have a clear explanation.

PVsyst uses the one-diode model established from the usual STC data (on front side). When using the bifacial gain, the back-side irradiance is simply added to the GlobEff value on the front side, with a coefficient named the "Bifaciality factor". The increase of ISC current with bifacial irradiance is not relevant. This is an operating condition. When you are using a module at anothe irradiance than 1000 W/m2, you don't take care of the ISC at this irradiance: this is a result of the model.

We don't know this bug. However this arises in an old version, we cannot modify the old versions.

The first and last hours of the day are partial hours (e.g. morming: between sunrise and the full hour). In these cases PVsyst calculates the solar geometry in the middle of the interval (sunrise hour - full hour), not in the middle of the hour.

See the FAQ What is the new loss "Global incident below threshold" in the loss diagram ?

These are marginal points. All these data are at beginning or end of the day. For each one you have a null GlobEff, and a negative yield (night loss). The error of PVsyst is to issue a value for PR in these conditions. We have to check this.

No sorry, this is not possible in the present time. In PVsyst, all the trackers are rectangular.

PVsyst tries to put benchmarks to the imported Meteo data. The aim is to avoid bad data due, for example, to solarimeter calibrations or erroneous imputs. Now this is not quite easy, for some situations the data may be out of our criteria. For e very clear sky locations (low aerosols, low humidity), the data may overcome the clear day model. In your case, the over-irradiance with respect to the model seems rather high (we rarely see more than 10%). But this only concerns winter days. Perhapes there is something unaccurate in the model of the meteo data provider. You can try to find other meteo data for your site (from another source) for comparison. By the way this doesn't prevent you to perform the simulation.

The error limits are defined in the Hidden parameters. Here in the topic "Miscellaneous: Meteo, Simulation, ... ", you should modify the item "Best KtCC days have strongly low values".

The Irradiance loss is related to the low-light efficiency behavior of your PV module. The loss (or eventual gain) is calculated at each step of the simulation. Now the losses will diminish (or even become gains) when: - The climate is extremely sunny (many high irradiance hours) - The low-light performance of the module is high. This performance is related to the Rserie choice. If you are using PAN files from a manufacturer, be aware that some manufacturers may increase the Rserie for increasing this low-light efficiency. See our FAQ How are specified the PAN files in the PVsyst database ?

Your PVsyst program is probably not pointing to the correct Data structure. You can manage the addressing of the working data structure in the main menu "Files > Workspace". Here you can create, import, or switch to an existing structure.

No, IN PVsyst it is not possible to mix 3 orientations on a single MPPT input. As a workaround, you can redefine your central inverter as a multi-MPPT input inverter, and attribute a sub-array (orientation) to each MPPT input. If the powers are not equillibrated, you can use the "Power sharing" option.

It is indeed possible to import hourly or sub-hourly values of meteo data measured on the Plane of Array (POA). But it is not possible to import monthly values measured in the POA. Nobody has any model for transforming them into hourly values (synthetic generation).

You can import almost data in any text file, provided there is one time step on one line. Please open "Databases > Import ASCII meteo files", and here press F1 for the procedure.

PVsyst simulations are based on an hourly time step. Implementing sub-hourly treatment would be a big task (which is on our ToDo list, but not for the next months ...) By the way, with grid-connected systems the production is very linear with the incident GloBinc. The effect on the yearly (or even monthly) performance results will be probably very low, as everything is averaging. The only serious error will come from the non-linear behaviour of the Power cut by the inverter nominal power. There is an additional overload loss which is not accounted in the hourly evaluations. This error increases with highly oversized PV arrays.

This is not possible as the SIT object in the Project's file is not necessarily an exiting file: It may be modified within the project, without a file counterpart.