André Mermoud

This is an estimation. I have done some "experiments" with the Mismatch tool, using different PV modules distribution values from "out of factory" STC data and usual tolerance. However it is not easy to determine a number valid for any situation. Now most of other software take 2% as default value. You can also ask them why.

The "Back-tracking" strategy and the "shadings" strategy are usually relatively equivalent, as you intercept the same tube of light. What you loose as shadings with the latter case, you loose it as incidence orientation loss with the Backtracking. Now this equivalence is not strict. It may be slightly different according to other parameters (like GCR, axis tilt, number of trackers, etc). I don't understand well your statement. See our FAQ Which gain can I expect from Backtrackintg strategy ?

Nothing prevents you to use a google image for the definition of the horizon, if you can define the "horizontal line" (here the lake) on the photography. Without this reference it would be more difficult. Now if you avail of ground measured data, they already include the horizon effect. If these are hourly data, there is no real problem: you will not take an horizon line into account in the simulation. But if these are monthly values, the hourly data should be created using the synthetic generation, and this model "ignores" the horizon line. Please see our FAQ How to deal with meteo data which include horizon loss ?

This problem appeared in the version 6.43. We have corrected it for the next version 6.44.

I don't know how it could work in the version 6.38, as we never implemented this opportunity. We intend to do so in a rather near future.

The calculations of shadings in PVsyst don't indeed like the "holes" in the shading objects. Therefore you are advised to define fences as 1 or two long parallelepipeds (and define them as thin objects). The result will be the same. The vertical poles of the fences don't contribute significantly.

The PVsyst simulation works in hourly values, i.e. on hourly averages of Irradiance and other variables. The solar geometry is computed in the middle of the hour, for an application on this average.

Most of the models used are explained in the help. See namely the chapter "Physical models used".

You can simply specify one only object of an arbitrary number of trackers, each of any size. For the electrical losses, you are not advised to use the "Module layout" part. The execution time will be prohibitive. But you can use the option "Shadings according to strings". See our FAQ With my big power plant the calculation time is prohibitive.

Your inverter file seems to be completely corrupted. I don't know why, nobody has never reported this problem. Perhaps you have open it in a text editor and saved it ? You should recreate this file from the datasheets.

One string of your modules represents 5.94 kWp. It doesn't make sense to choose an inverter of 30 kWp for an array of only 5.9 kWp. This inverter will have a very bad efficiency. An inverter of 5 kW would be largely sufficient. You can modify this limit in the hidden parameters, topic "Detailed Simulation Verification Conditions". However this would be a very bad idea.

In PVsyst, besides defining arrays of trackers, you can also define independent trackers (i.e. several objects with one only tracker), that you can distribute (in X,Y Z) as you like on your ground. However these trackers have the constraint of having the same tracking parameters (i.e. same axis orientation, same tracking limits, etc). PVsyst will compute the irradiance equally for each tracker (the orientation of all trackers is the same at a given time). Backtracking with not regular systems Now the backtracking strategy is closely related to the relative position between trackers. In PVsyst, you can define it only if you have a set of at least 2 trackers (within a same tracking object) for calculating the backtracking angle with respect to the tracker's width and the pitch. If you have uneven disposition (different pitches and/or altitudes), this backtracking angle will not be valid for the other trackers. Therefore in this situation - and for the restriction of a same orientation for each tracker - the backtracking strategy doesn't make sense. A "normal" tracking system with mutual shadings will usually have better performances. Backtracking calculation limitations The backtracking calculations are a complex geometric calculation. Up to now we have only elaborated the algorithm for specific cases. - With Tilted axis systems, the trackers should be organized in a "rectangular" way (i.e. no shift of one tracher with respect to its neighbour), and at the same altitude. - With Vertical axis, we have not found the right algorithm up to now. - With 2-axis trackers, the algorithm only acts on the azimuth backtracking. In this configuration there are several possible backtracking strategies, we have not implemented them up to now. - The backtracking is correct within the tracking frames, but not from frame to frame.

First of all, please make sure that without backtracking you have well defined the mutual shad8ings in the 3D scene. Now with or without backtracking the result is usually very similar. With backtracking you loose irradiance due to the trackers's onrientations, when without backtracking you have shefing losses. But in both cases you intercept about the same "tube" of light. See our FAQ What can I gain with Backtracking strategy ?

Sorry, it is not possible to use Helios3D data with 2 different "nominal" orientations. The reason is that when accompanying a hill, the orientation of each table is different. With these kinds of scenes PVsyst has to evaluate an "average" orientation for the simulation. Now we did not yet implement the average calculation for 2 different orientations. This would be possible for east-west (domes) as the orientations are clearly different and we can easily define 2 groups of tables. It is much more difficult when the nominal orientations are close to each orther (like for example 2 sides of a hill). if the distributions interpenetrate, how to attribute a given table to one or the other average ?

This option only appears when you have effectively imported the Array temperatures along with your meteo data in the *.MET file.

This is exactly what I said in my first answer to this post. The active energy production will not be affected, until the Pnom limit (in kVA) will be reached. The power factor acts as a diminution of the nominal output power (Pnom) expressed in terms of active energy [kW]. In your example: Pnom (apparent) = 60 kVA => with 85% PF Pnom (active) = 51 [kW] will be applied for limiting E_Grid when running the symulation. PVsyst works in this way of course.

Please send us your Helios3D file (*.h2p) to support@pvsyst.com

You should now define your site in the database ("Databases > Geographical site > New"), and choose a well-defined site for the project.

With single axis tracking systems, the problem of defining a not null axis orientation is indeed not simple and confusing. In the 3D scene definitions, you have 2 ways of defining the axis azimuth: 1. - Either you define the axis orientation in the tracking parameters. In this case the orientation will be defined within the tracker's set object, and you will obtain trackers "shifted" with respect to each others. 2. - Or you define Axis Azimut = 0° in the tracking parameters, and you will have a correct "rectangular" disposition of your trackers within the Trackers set object. Now when including this object in the global scene, you can give an azimuth to this Tracker's object, and finally you will get a tracking axis azimuth with respect to the geographic coordinates. The azimuth specified in the "Orientation" part is indeed the axis orientation within the tracker's object (tracking parameters), it will be not null in the first case and null in the second case. The report will mention the final azimuth, with respect to the Geographic coordinates. NB: the backtracking results of a complex analytic calculation. We established the algorithm for the second case, but we couldn't find a satisfying one for the first case. Therefore the Backtracking is forbidden for the first case.

You can produce a CSV file of hourly values, showing any variable chosen among the >50 variables of the simulation, to be analyzed in EXCEL. For this you have a button "Output file", just before performing the simulation.

The shed-to-shed slope is indeed specified in degrees (this mention has disappeared from the dialog, perhaps hidden behind the up/down control, sorry). Now when you specify a terrain: - either you position the set of sheds as an object on your terrain. In this case the first table will be positioned on the terrrain, and the shed object will be considered as a whole, with its own parameters. - or you specify your system as a set of tables, each table will be positioned on the terrain independently.

If you didn't use the "transfer" function before the crash of your computer (which seems evident...), after reinstalling PVsyst on a new computer (or windows installation) you have to take contact with our administration admin@pvsyst.com.

We have to get instructions from SolarEdge for modifying the installing conditions (which have been established in close collaboration with the manufacturer). We are in touch with them.

First, please be aware that this image is not directly issued from PVsyst. If it is based on a PVsyst configuration, it has been redrawn. Now for reproducing this configuration, you have to know the details of the project (more exactly the calculation version) which was used as the basis of this configuration. There were probably several sub-arrays, with different MPPT inputs and string lengths. Then, you have to reproduce the 3D scene that has been used, i.e. the exact shape of the façade and the holes.

Solaredge has not shared theid latest Guidelines with us. However I don't understand well which limitation you are speaking about. Please give a screenshot of window in error, and the exact error message.