André Mermoud

PVsyst proposes a model, established according to well-specified hypothesis, either for the irradiance availability on the ground and for the Form factor. It gives detailed results about the ground availability and the rear side irradiance, along the whole year according to your meteo data. However we don't have any validation. In fact we didn't got any results registered in good conditions with a realistic PV system up to now. Now most of people studying this subject work with one or 2 modules on an "illimited" reflective area. This is the case of both papers you are referencing. Even if the simulation of the Universities of Konstanz and al. are done with 5 rows, you can observe that: - the extreme modules behave better due to the larger"seen" reflective area (on 4 edges) - the chosen inter-row is very large (if modules are 1 m wide, the "pitch" of PVsyst is 1 * cos(25°) + 2.5 m = 3.4 m, so that the GCR is 0.29. - the chosen albedo of 0.5 seems irrealistic in real conditions. Their only measurements are for one pair of module only, at 1.2 m altitude. They don't tell us how they have measured the albedo coefficient taken in the model, therefore it is difficult to have a full confidence in their validation. The PVsyst model tries to represents a realistic PV system, i.e. with the "unlimited sheds" hypothesis. Please see the fig 5 of the publication: with a reasonable (usual pitch (1m between rows, i.e. a GCR of 0.52), the gain is of the order of 8%, not so far from the results of PVsyst before shading and mismatch losses.

You are certainly using a version < 6.40, and trying to read a file (PV module, inverter) created by a version >=6.40.

This is because you have not defined the "rectangles" representing a string correctly. You have defined one rectangle as one submodule. In the option "According to module strings", one rectangle should correspond to one full string.

We could indeed increase the number of decimals here (and in many other places). This would make the reading of the report more heavy, without a significantly better accuracy. For your example, the "reading error" represents perhaps 10% of your wiring resistance loss (because it is very low, probably not realistic), but 0.05% of the system yield ! I doubt that your Rwiring evaluation is much better than this value.

Yes of course. The simulation of PVsyst is based on horizontal meteo data, and evaluates the POA using transposition models. An additional improvement for the accuracy would be to measure also the diffuse component on the horizontal plane.

It is indeed the definition of the Backtracking strategy to avoid mutual shadings. It does that by adjusting the plane tilt (phi angle) according to the sun's position. If you don't have near shadings you don't have electrical shading losses of course. Now I don't know how you evaluate the plane tilt during operation: this will highly depend on the sun's position. However if you construct the same system with fixed tilt, you should have exactly the same shading situation for the same plane tilt and same sun's position.

The nominal power of your inverters may be up to 1155 kW if the temperature around the inverter is less than 35°C. Please explain in detail how you observe an increase of 15 kW with respect to this value.

Importing Sketchup or AutoCAD files (in .DAE or .3DS formats) is now possible since the version 6.60. See the help "Project design > Shadings > Near Shadings: Import > Sketchup and other CAD software"

PVsyst is oriented towards PV systems. It doesn't involve a complex building model for the evaluation of the PV modules temperature, which would require a lot of additional paramewter. However you can import the Array (cell) Temperature in hourly values along with the Meteo data (CSV hourly file). You can therefore create a representative temperature time series using your own models - synchronized with your weather data - in MS EXCEL, for using during the simulation.

With Helios3D scenes on hills, the baseline slope induces an orientation distribution of each table. In this case PVsyst uses an average orientation. See our FAQ "With my installation on a terrain, I have multiple orientations".

In the present time, PVsyst can work with one average orientation. We are preparing (for very soon) the opportunity of defining several average orientations, with tools for the attribution of tables to one or the other orientation. Now please observe that the orientation (and its averaging) only affects the transposition result. A reasonable mis-orientation or dispersion around an average will not have a too big impact on the accuracy. The mutual shadings calculations (shading factors) are only based on the system geometrical configuration. They are taken correctly into account, even with orientation dispersions.

This would require a specific tool for each source of Meteo data, which are all different. For getting many of them, a manual manipulation (on the web) is often necessary. Very few offer an API for a direct import, and the use of such API is not yet implemented in PVsyst.

No sorry. There is no mobile license for PVsyst.

The wiring losses are basically calculated using the resistance Rwiring, which is the basic parameter used in the simulation (and stored as a parameters). Now PVsyst defines an equivalent value expressed as the percentage of the loss under STC conditions (i.e. PNom). This value is more convenient for a first approach of your system development, as the default value is well understandable and doesn't depend on the system nominal power. However in the last steps of your PVsyst system evaluation, you should calculate this Rwiring explicitly according to your real wiring conditions. NB: the specified percentage as function of the STC power will not be your final energy loss. See our FAQ Why the losses in the results are different than those specified ?

Yes, the principle is the same for PNom values different due to the temperature.

The "linear" shading loss is the result when using the first table. The second table is used for computing the Electrical loss (accounted in the Array losses), which results basically of a difference between the two tables. The Module layout tool - which is closely related to the inverter behavior - is indeed not available for Stand-alone systems in the present time.

In PVsyst, the shading losses are the result of a detailed calculation, involving your system configuration and the irradiance distribution. You cannot explicitly specify monthly values of course.

I don't understand what you are doing. A negative pitch doesn't make sense in the calculations. It is so unusual that we even not thought to forbid it in our error messages. By the way, you cannot use the backtracking strategy with a misalignment of the trackers. See the FAQ How is defined the Tracking Axis azimuth ?

I don't know. 15 kW/200MW represents 0.0075%. This may be a rounding error somewhere.

I have never seen that, and I can't reproduce it. This may indeed be related to a Windows setting (in "Internationalization"?) . - Does this arise with all projects ? - Does the date appear correctly in other dialogs (for example in "Tools > Meteo Tables and Graphs", box "Dates") ?

The reading of custom Horizon files is really very restricted. Only the first line may be a comment. The next lines should be values Azimuth; Height; We have indeed to modernize this reading for allowing a more flexible reading.

Sorry, the general treatment of tracking systems have not been developed in the "Tools" part, neither in the "Tables/graphs of Solar parameters" nor in "Monthly meteo computations".

You can convert these files by opening them in a new version (> V6.40), and save them using the option "File compatible with old versions" in the saving dialog. You can also ask the manufacturer for sending files in the old format.

Please check that you have also suppressed the bifacial system use in your other sub-array (LED switched OFF).

You should send your questions relative to errors at support@pvsyst.com