André Mermoud

No sorry, this is not yet possible in PVsyst. You cannot import POA from a tracking solarimeter. We intend to implement this opportunity in a next version.

I don't understand well the question. The orientation doesn't change during the simulation (during the year). But the Optimal orientation is depending on the period you consider for the optimization. In some situations, you may want to optimize the winter performance, not to get the higher irradiation during the whole year.

No, in PVsyst all the trackers have the same orientation at a given time.

Sorry, this was a limit which seemed reasonable when I wrote this dialog. I have diminished it for the next version 6.44. However this limit is not very significant (only used for sizing conditions).

In any version of PVsyst, you can define pairs of (Azimuth, Height) as you like (not necessarily with identical azimuth steps). Usually points spaced by 5-10° (or following the significant points of your horizon) are largely sufficient. For diffuse calculations, you are advised to define the horizon all around the site (azimuth -180 .. 180°). In the version 4, the number of points was limited. Some software gave horizon with 1 point every degree, which is completely useless. In these cases PVsyst reduced the number of points by performing some averages.

This is not yet implemented. See our FAQ How can i include an inverter in a stand-alone system?

Yes you can only define 2 different orientations for seasonal tilt. It is a limitation of PVsyst. You have to construct your 3D construction with the summer tilt.

The PV module tolerance is used as default value in a project. You can put here any value. Therefore this value is not of big importance: you can choose it as you like. See our FAQ How to define the "Module Qualits Loss" parameter?. At the time of the version 5, most of the modules were specified with -/+ tolerance (usually -/+ 3%). Therefore a loss of half the lower value (1.5%) was pertinent. Positive sorting appeared more recently on the market. This is the reason why this definition had to be updated.

I can't understand that. Please make sure that you have clicked "Show all available meteos".

The unlimited option has not been developed for trackers up to now.

They are not yet implemented yet. This will probably be done in the version 6.45, within some few months. In the mean time, you can define an equivalent pack (in terms of capacity) of existing Lead-acid batteries: the simulation will be very similar.

I don't know the format of the PV*SOL horizon files, but in PVsyst you can simply create a CSV file of (Azimuth, Height) pairs values. See the help for the exact format. Now defining points every degree doesn't make sense. If so, PVsyst will "simplify" the horizon line by eliminating the unnecessary points, in order to get a max. of 120 points.

The EArrRef is the STC energy according to the "nameplate" reference power of the modules. This value is used as reference for the PR calculation. The EArrNom is the result of the one-diode model at STC. It should be the same, but may have a slightly higher value than the EArrRef. It is used as starting point in the Array Loss diagram. See our FAQ Why is the Pmpp of my module different than the specified value ?

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.