André Mermoud

I already answered: you have to use the tracking frame, with a fixed tilt for the tracker. Now there is no differences in the algorithms, it is always the Transposition model (Hay or Perez). But the "physical" plane orientation is different in both cases.

This is not yet possible. The losses defined in stand-alone systems are restricted in the present time. I will update this treatment during the next few months.

You can have a look on our FAQ How is defined the plane orientation?

SMA has not proposed the data for the OND files corresponding to this model for the PVsyst cdatabase.

Nothing has been changed since the beginning of version 6. The update works quite well. However the problem may be some change in your web access. Some proxies or special web access right restrictions may affect the AutoUpdate possibility.

The simulation button is grayed because you have a red warning in the sizing form ("The array is strongly oversized"). Please see the FAQ Can I define a system with highly undersized inverter ?

Sorry, PVsyst only works with Hourly data. It is not able to perform simulations on sub-hourly intervals.

These values are the same if you don't specify Soiling losses. The soiling losses will also be taken into account in the GlobEff value (it is the effective irradiance in the PV modules).

The axis labels of this plot are indeed not correct. I was not aware of that, and will correct for the next version 6.27. The horizontal axis is the instantaneous output power (i.e. for a given hour). The bins accumulate all the energies registered for this power along the full year (or simulation period). I.e. the sum of all hourly energies for which the output power was in this bin range.

The algorithms used in PVsyst are probably a little bit simpler than those of this NREL publication. But the results should nt differ by more than 1-2 minutes. However I will not give all of them here. Perhaps we will give an extended description in the help in the future. In PVsyst, the hourly values are averages over one hour. The time stamp 8:00 concerns accumulations (averages) of instantaneous values from 8:00 to 9:00. Therefore it is natural to compute the solar geometry at the middle of this interval.

OK, done for the next version 6.27.

According to the measurements reported by the specialized laboratories, the maximum power point Pmpp behaves very linearly with the temperature. The muPmpp parameter specified by the manufacturers is the slope of this linear dependence. Now the Pmpp temperature dependency as calculated by the one-diode model is not exactly linear. Until Version 6.25, PVsyst adjusted the slope for getting the correct slope at 25°C (i.e. a tangent adjustment). In these conditions the derive is around -0.03% at 35°C, -0.12% at 45°C and -0.28% at 55°C by respect to the linear hypothesis. The graphics shows that this "error" is almost imperceptible: Pmpp differences (linear - model) acc. to temperature From version 6.26, the slope is adjusted in order to get the measured (linear) value at 25°C and 45°C (i.e. a secant adjustment). This improves the accuracy of the model at the operating temperatures, and results in a diminution of the temperature loss of about -0.1 to -0.2% (of annual yield) with usual PV systems (depending on the climate and the thermal U-factor) The graph shows the zoomed differences: Differences between Pmpp temperature models NB1: The temperature behavior is normally a result of the one-diode model, close to the specifications. However for an exact adjustment of this value PVsyst introduces a slight linear correction of the Gamma value (diode ideality factor) as function of the temperature. NB2: If you are designing plants in very hot climates, you can choose another secant point than 45°C in the Hidden parameters, topic "PV modules", item "Upper temperature reference for muPmpp default". This point should be in the middle range of your operating temperatures along the year, not the highest ! NB2: In some places of the program - e.g. in the specification dialog ("Model parameters" / "Temper. coeff.") - the muPmpp value corresponds to the Manufacturer's requirement (i.e. secant). And in other places (page "Basic data", application of the model), it is the real derivative for a given temperature. Therefore there may be some differences when showing this value.

The program PVsyst is continuously evolving, therefore it is quite unavoidable to get sometimes yield differences between versions. We try to list some of them here (not exhaustive). Version 6.33 with respect to 6.32 Module Layout calculations: - When operating below the VmppMin inverter value, the simulation chooses the second maximum (instead of the voltage limit). - For shed arrangement, the linear shading calculation has been refined, which affects the electrical loss calculation. Version 6.27 with respect to 6.26 - The electrical shading loss calculation has been modified for shed arrangement: there is now a threshold in the shading factor for activating it. - The AC ohmic losses after the inverter (wiring, transfo) are now affected by the power factor (divided by cos(phi)**2). Version 6.26 with respect to 6.25 There were 3 modifications affecting the yield in this version: - The interpretation of the muPmpp value as specified by the manufacturer: see Temperature behavior of the one-diode model . This induces a slight diminution of the temperature loss (around 0.1 or 0.2%). - Concerning crystalline PV modules of the database for which the Rs is not specified by the manufacturer: the default Rs value was previously based on a fixed Gamma value of 1.10. It is now fixed by asking a relative efficiency of -3% at 200 W/m2. This induces a decrease of irradiance losses. - The metal resistivity (copper and alu) have been slightly revised (unperceptibly diminishes the wiring losses). Version 6.09 The shading factor for diffuse now calculated for different tracking positions. => Slight modification with normal systems with shades, but addition of a significant shading loss for Backtracking strategy (see How is calculated the shading loss on diffuse with tracking systems ? Version 6 by respect to V 5 The differences are listed on another post.

Yes, it is the desired behavior. If you have several variants to save, they will obviously create new VCi files. We judged that overwriting the original file would be confusing. However if you "resimulate" a set of old variants (new feature in V 6.26), you have the opportunity of choosing whether you want to create new files or overwrite the existing ones.

It should not recalculate the table if this has already been calculated and nothing has been changed in the shading scene. I will check in the program.

Yes, the simulation with the usual parameters is valid for the first year. In you want to take a degradation into account you can specify it in the parameter "Module Quality Loss". NB: You can specify a degradation rate in the "Financial Balance" tool, which deals with the financial balance over several years, after defining the economical evaluation (inverstment).

In the Hidden parameters, topic "Miscellaneous", you can adjust this limit.

I don't see how to do that in PVsyst. I have developed the treatment of optimizers at the module level, for 2 different products: not trivial. This will be available in a next issue of PVsyst (probably within one month).

The performance ratio is referenced to the GlobInc (irradiance in the collector plane without optical losses), not GlobEff which includes the shading, IAM and soiling losses. See How is calculated the PR ?

If you define the P50/P90 parameters in the tool behind the button "Miscellaneous Tools" (at lease define the "kind of data"), the analysis will appear in the report. In the printer dialog, you have the opportunity of printing it or not.

I can't understand that. Please send your whole project, using "Files" / "Export project" in the main menu, to support@pvsyst.com.

I don't know the model used in this article. In PVsyst, the IAM calculation may be dependent on the meteo data as you pointed out (especially the diffuse component or the transposition model used), an on the plane orientation. I have done a little correction on the calculation for the albedo some months ago (effect less than 0.1 or 0.2% if I remember well).

Scaling the tracking rows (by a same factor for the tracker's width and pitch) is indeed a very good idea, that I adviced for sheds since a long time. However: - there may be errors due to edge effects at the extremities: if you also scale the tracker lenghth (i.e. diminish the number of trackers) I think the simulation should be quite representative. - if you use shadings "according to strings", you should also scale the string's sizes (i.e. a string rectangle will represent several strings). - this is not correct for the electrical losses calculated with the "module layout", which are based on the module's sizes.

This is indeed a very old text in the help, which has not been updated for the new developments. Sorry. The statement is rather that you should not use "Unlimited sheds". You can use fixed or several orientations. Yes it should be used,for taking the mutual shadings of trackers into account in any case. With backtracking, it is necessary for the calculation of the mutual shadings on the diffuse part, even if there is no loss on the beam component (table with null everywhere). See How is calculated the Shading Loss on diffuse with tracking systems ? Since a very long time (but I can't remember when), there is a generic calculation of the electrical losses in the "Unlimited sheds": as soon as the bottom cell is shaded the string becomes inactive. You have to define the number of strings in width in the row. There is no formal limitation on the number of sheds. If you define too much in the 3D tool, the calculation time may become prohibitive (see our FAQ With my big power plant the calculation time becomes prohibitive) There were already a significant optimization with the version 6, we are working on further ones. For beam component, the zero shading factor is by definition of the Backtracking mode. The shading factor on diffuse or albedo calculated from this table of moving orientations are not relevant (PVsyst should not show them). The shading for diffuse has to be computed for each position of the trackers, using a shading factor table calculated for a fixed plane at this orientation. This is done for some positions, and interpolated. When using backtracking, the plane orientation is no more optimal in backtracking situation: the shadings for beam component disappear, but not the shadings for diffuse and albedo. As the yield is less for very low sun's heights, the relative horizon loss may indeed be lower. The IAM increases as in backtracking situation the sun has an increased incidence angle.

Of course, if you had explained your acronym SAT and what you meant by a "saw-tooth type tracker", the answer would have been more accurate. In this case indeed, you can use the Frame with North/south axis, and fix the tilt within the frame by defining "Min/Max tilt on the frame" = 10°. Depending on the latitude and the chosen spacing, there may be mutual shadings from element to element in the tracker.