André Mermoud

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.

Yes there was also a big problem (freezing) when you defined SolarEdge inverters along with not-SolarEdge ones in other sub-arrays. There was not a straightforward solution. This has been treated in the version 6.69 by a serious update of the SolarEdge Management.

Meteo data are subject to some "rules". For example, we have a model for the clear sky conditions, with an accuracy of 2-3% towards high values. The meteo data cannot be too high with respect to this model. If so, they are doubtful, you should choose another meteo data source.

I don't know what happens. Please send your full project (using "Files > Export project" in the main menu) to support@pvsyst.com.

On this graph, the resulting I/V curve (String#2, 2 unshaded sub-modules) is not drawn. This is indeed a bug. Except this problem, the graph seems correct.

Yes, this is a problem of scale: the values are correct, but the drawing bars are not based on 0. This is corrected in the new version 6.73.

Yes there is indeed an accidental error in this version 6.73. This will be repaired in the next version. In the meawhile, you should define these values with the version 6.72 (you can always download an old version, and use it in parallel of your usual working installation). In this is already defined and you don't open this dialog (page "wiring losses"), the parameters will stay correct for the simulation.

The array temperature is calculated from the GlobInc (irradiance on the PV plane. Therefore it is quite normal that it is different with different orientations.

This is a generic error. We cannot say anything with just this information. When occuring, you are asked for sending us a bug report. This helps us a lot. Otherwise, please send us the screenshot of your error message (full screen), with a complete description of your problem (what you are doing, etc). Send it to support@pvsyst.com.

Applying the probabilistic evaluation P90 to hourly, daily of even monthly values doesn't make sense. P90 is an annual evaluation. Please see our FAQ "What is the P50-P90 probability production ?". PVsyst only allows mixing the orientation #1 and #2 on a same inverter input. This is a limitation. Now you can define several sub-arrays, with different MPPT inputs, for different orientations. The sub-array - i.e. inverter MPPT input - may only be defined in an homogeneous way (same module, same number of modules in series).

The Minimum voltage for getting Pnom is equivalent to an input current limitation. By defining VminPNom, the minimum voltage for attaining PNom, we have: - Imax = Pnom (DC) / VminPNom, - where Pnom(DC) = PnomAC / Efficiency. If this value is specified in the inverter, it is obviously taken into account in the simulation. Everything is explained in detail in the contextual Help "Physical models used > Grid inverter > Inverter Operating Limits" and other topics.

The relevant parameter is "Limit overload loss for design" in the Prject's definition (button "Project's Settings"). See the FAQ Can I define a system with highly undersized inverter ?

Since V 6.68, there is a new loss named "Global incident below threshold" in the loss diagram. For simulation hours when the GlobInc value is below a given threshold, PVsyst doesn't perform the full simulation: this is considered as a "not significant" hour. This threshold is fixed at 10 W/m2. Remember that by very covered weather conditions, you have still 40 to 50 W/m2 ! Up to now this (little) loss was included in the Near Shading or IAM loss contribution. For balance coherency, this is now accounted independently. This contribution rarely overcomes 0.05% in yearly values.

The procedure is fully described in the help "Project design > Bifacial Systems", and "Project design > Bifacial Systems > Bifacial system: 2-dimensional unlimited sheds/trackers".

No, you cannot do that.