André Mermoud

In PVsyst, the parameters of all trackers should be identical. So that at a given time, the orientation of all trackers is the same. Therefore it is not possible to distribute trackers on a hill, with axis following the slope. We will develop this feature in a next version. But in this case the backtracking will be totally impossible (either in PVsyst and in the reality).

This depends on the version. In the latest versions you have indeed the item "SAM CSV format - Hourly TMY or time series".

This depends on when you evaluate the solar geometry. In PVsyst, for normal intervals the geometry is computed in the middle of the hour (eventually shifted for some measured data). Now the first interval of the day begins at the sunrise time (say, 6:20). And the solar geometry is evaluated in the middle of this interval (in this case 6:40). I don't know whether the Synthetic generation managed by Meteonorm uses this convention. Please ask the Meteonorm team.

This service has been suppressed by PVGIS in october 2018. It is no more supported. PVsyst can now import CM-SAF data in a new format, as hourly files, directly from the PVGIS site. Please choose the option "PVGIS V5 Hourly time series"

PVsyst can import meteo data from many sources, in many formats, and creates internal *.MET files. But it doesn't create files in external formats.

SolarEdge has very specific and constraining rules. These rules involve specific devices (inverters and optimizers) and their associations. These are implemented in PVsyst according to the requirements of the SolarEdge team. Please ask them. NB: There will be a new implementation of these rules in the next version 6.80, with some new devices.

The irradiation conditions in the nord of Chile are really exceptionnal (due to altitude and very dry weather). You should increase the limit for this warning in the Hidden parameters, topic "Sites and Meteo", item "Upper limit for monthly clearness index"

Perhaps you are using an old version. In the Weak grid definitions you have this option: Group "Operating conditions", checkBox "Allows solar injection into the grid."

Usually no more than 1-2 working days.

There is a short explanation in the help "Project design > Shadings > Near Shadings: Import > Helios 3D" But we should indeed write a complete description of this tool.

Before analyzing the economic evaluation, please analyze first the energy output of your simulation. I don't understand well what you have specified on your CSV file: with CSV reading, PVsyst only accepts hourly consumption values, not daily values. If you want to create a PV system ensuring 100% self-consumption, it should be of sufficiently low power for never exceeding the User's needs, even by clear sky conditions.

For importing PVGIS data, PVsyst now uses a "Web service": it reaches directly the PVGIS site, and downloads the requested data. You don't need to open the PVGIS web site anymore. NB: With this new service, the PVGIS database has been deeply updated. The data are now provided in really measured hourly values, either as real years, or as TMY.

This calculation "according to strings" corresponds to an upper limit of the possible shading for each specified string. A "Fraction for Electrical effect" of 100% means that the full beam component is lost when the rectangle si shaded. A value higher than 100% would mean that more irradiance than the beam would be lost, which doesn't make sense.

The Voc(Tmin) requirement corresponds to a safety requirement. The procedure used in PVsyst for the evaluation of the max. voltage is a universal common practice, adopted by everyone in the PV community (not only PVsyst). We will certainly not modify this procedure. See the FAQ How to adjust the design temperatures ?.

This "Ground reflexion on front side" contribution had to be introduced with the bi-facial mode. It is due to the reflexion of the ground just between each row of collectors. It is mainly dependent on the tilt (low tilts will give lower contributions). This was quite necessary especially for the treatment of vertical bi-facial systems. It is also related to the pitch, as with big pitches, the contributing area in front of the PV table is higher. You can do some trials for this estimation in different situations. NB: This contribution is theoretically also present in usual not-bifacial systems. However it has always been neglected, as the calculation is quite complex, it requires all the hypothesis of the bi-facial systems - definition of the ground albedo, the geometry, etc. We were not aware of it until working on bi-facial systems. I doubt that any other PV simulation software takes this contribution into account and calculates it accurately.

The "Unbalanced" feature is a very special mode, only available for 2 MPPT imputs with very dissymetric inputs. When you have more than 2 MPPT inputs, you cannot define this mode and its very specific behaviour. But you can always define Sub-arrays of different powers on each MPPT. In this case you should use the "Power sharing" option for attributing a given PNom to each MPPT input. See the help "Project design > Grid-connected system definition > Multi-MPPT inverters: power sharing" for further details.

The back-up current is specified for your system, as a property (setting) of the back-up generator. It is specified in the "System" dialog, page "Genset". It is supposed to be constant at any time, when the genset is activated.

Th PNom limitation is applied on the apparent energy, therefore earlier. This is fully explained in the help "Project design > Grid-connected system definition > Power Factor"

The errors are of the order of 0.016% of EApGrid. This is a rounding effect of course (pro^bably on your Cos(Phi) value).

I don't see any difference in the program. Please check that both simulations use the same Transposition model, and exactly the same meteo data file.

The beam is an average irradiance over for the whole hour. Therfore PVsyst calculates the duration for which the sun is below the horizon line, and the duration over. The beam component is accounted for the duration above the horizon.

The albedo involved in the bi-facial calculation is the albedo of the ground surface "seen" by the collectors, just below the installation of course.

The PVGIS old database in monthly values in no more maintained. The owners (JRC) announced that it would be unavailable in November 2018, so that we removed the import from this source. If you want to import these monthly data you have to do that manually in "Databases > Geographic sites". PVsyst has now a powerful tool for importing the new PVGIS databases, for an highly exteded geographic region and in hourly values. Please see the help.

You should ask the manufacturers/providers, and tell them to take contact with us for updating the database. However you can easily create your own components by yourself. The easiest way is to choose a similar existing device in the database, modify its parameters according to the manufacturer's datasheets, and save it under a new name, therefore creating a new file in your database. For Crystalline modules, except Isc, Vco, Impp and Vmpp, nb of cells in series and module sizes, you can let all the other parameters (mainly Rserie, Rshunt, Rsh(0) and RshExp) at their default value. You have a checkbox near to each parameter for retrieving the values proposed by PVsyst.

Our next improvement for Bi-facial will concern the vertical systems, which need to deeply review the Transposition model, especially for the circumsolar component. However this doesn't affect the usual calculations (reasonable tilts < 40°). We don't have any indication that the model has to be revised. Several studies with experimental data are on the way, and don't indicate that the bifacial gains are strongly under-evaluated in the unlimited sheds (or trackers) hypothesis. The treatment of "single sheds" will not be available before several months.