André Mermoud

If I understand well, you have put modules on trackers, with a tilt angle of 6° with respect to the horizontal axis. With this configuration you should use the configuration "Tracking 2 axis, frame NS". And here you have to "fix" the module tilts by defining Min tilt/frame = Max tilt/frame = 6°. NB: Don't use the Backtracking option: it is not suited for that: it concerns the tilt on the frame only.

There is nothing to improve. It is always necessary that the site attached to a project holds full monthly values (I repeat: not used in the simulation). These data are used for some internal models, namely for pre-sizing advices. This doesn't prevent to use meteo files (or DAM files for measured data) with a restricted time period, up to one only day.

No, there was no problem with the ASHRAE standard.

The VMax values for the PV modules in the PVsyst database are specified by the manufacturers themselves, and should correspond to the datasheets. The datasheets still often specify 600V as Max. voltage for use in the US, and I will certainly not change this without the acknowledgement of the manufacturers of course. It is their responsibility to modify this value.

This depends on how the DNI and DHI values are defined in your data. In PVsyst, we have the relation (which is a definition): GHI = DHI + BHI = DHI + DNI / Sin(Hsun) where: DHI = Diffuse on horizontal plane, BHI = Beam on horizontal plane, DNI = Beam (or Direct) normal, Hsun = sun's height, acc. to solar geometry). Therefore for a given GHI, there is a bijective relationship between DHI and DNI: you can calculate one from the other, and there is no possibility of any discrepancy. This is a question of definition, not a model. In other words, the values (measurements) of DHI and DNI are equivalent. NB: The determination of BHI from DNI/sin(Hsun) is very dependent on the Hsun value, especially for low sun heights (in the morning and the evening). That is, the time of the solar geometry is critical: the geometry should be calculated at the middle of the DNI measurement interval. If you observe discrepancies in the morning or the evening you have to carefully adjust the time shift parameter, already at the import stage. Now if you have the same definitions as PVsyst and a correct time definition, discrepancies in your data are necessarily a measurement error. For your simulations, you have to choose either the DNI or the DHI measurement, the one in which you have the best confidence.

Even with backtracking strategy, the simulation shows a shading loss due to the diffuse (and albedo), which is usually between 2 and 3%. See the other post How is calculated the shading loss on diffuse with tracking systems ? People sometimes compare this loss to the loss of row-like (sheds) systems with fixed orientation, which may be much lower, depending on the system. How to explain this ? Please remember that with sheds systems, the shading loss strongly increases with the tilt of the sheds. Now with a tracker system, the tilt may obviously be very high in the morning or the evening, when the sun is low on the horizon. The picture shows the contribution of different irradiance losses in a shed system, as function of the tilt, for a given "limit angle" of 20° (i.e. pitch increasing when the tilt increases). Shading loss contributions as a function of tilt First, we observe that the Albedo contribution is important. The transposition model involves an albedo contribution proportional to (1 - cos(tilt))/2, i.e. low at usual tilts (e.g. 4.7% for tilt=25°), but significant at high tilts (25% at 60°). Then, as only the first tracker "sees" the albedo of the ground in front of the system, the albedo is affected by a shading factor of (n-1)/n, where n = number of sheds. This means that the albedo contribution is almost completely lost in big systems Secondly, the loss on the diffuse (sky masked by the preceding shed) is also significant, and strongly increasing with the tilt. The diffuse shading factor is the result of an integral over the sky vault, of the shaded parts multiplied by the cosine of the incidence angle of each "ray". Therefore a hiding band of the preceding tracker has a much higher effect when the plane (tracker) is at high tilt of 60°, as the cosine of the incidence angle of the bottom of the next shed is higher (cos 30°=0.866). If your plane is 15° tilt (sheds configuration), the plane will "see" the next shed with an incidence angle of the "shaded" rays of the order of 75°, i.e. a cos(75°) = 0.25. With backtracking strategy, the evolution of this shading loss is not varying much as function of the pitch, even for very large pitches. This is explained by the fact that with narrow pitches, the backtracking amplitude is low, when with large pitches, the trackers may take much higher tilts. And also because the loss of the albedo component is the same whatever the pitch between trackers for a given tilt (the albedo is masked as soon as the profile angle is higher than 0°).

In this case you can take the efficiency of the inverter at PNom (i.e. the extremity of the efficiency curve). By the way this value is not critical in the approximate evaluation described in the Help. We are aware that this definition is not quite satisfactory, and we are preparing a new approach using the effective transformer properties.

I don't know. Please send us your full project to: support@pvsyst.com

This loss should indeed be included in the "Auxiliary" losses. Or simply neglected: in your case it represents something like 0.04% of the yield.

There is no really explicit parameter for these losses: these are a result of the simulation. - The irradiance loss is related to the low-light performance of your PV modules. Which is itself dependent mainly on the Rserie defined for this module. Please see our FAQ How should be the Rserie value specified ? - The temperature loss is related to the heat loss factor U (normally 29 W/m2k for a "nude" module, i.e. row arrangement), and the temperature behavior of the PV module (muPmpp factor). You should not modify these values without solid reasons.

I don't know. I just tried such a configuration, and found a loss of 0.02%, which is probably something like a rounding effect in the calculations of the diffuse factor integral. Please save your shading scene (*.SHD file) and send it to us support@pvsyst.com.

This is indeed a difficult point in the PVsyst definitions. Please see our FAQ How is defined the tracking axis azimuth ?

PVsyst doesn't take it on its own. When in the "System" part, you define N PV modules of X area, the total area is N x X. It is not a mystery. Now you have to foresee sufficient area in your 3D shadings scene for positioning all these modules. This seems rather logical. What may be sometimes confusing, is that PVsyst also checks the coherency for each orientation: this check is done for each orientation independently.

I don't understand well what you mean when you ask PVsyst for generating the 2 other curves from the first one. The efficiency profile definitions should be defined by the user, independently for each voltage. These curves are a property of the inverter, there is no "physical" relation between them. If you define 3 identical curves for 3 different voltages you will get the same results as for one only curve of course. This means that your efficiency is not depending on the input voltage.

Please check that the "Power threshold" parameter is not null on the first page, before opening the efficiency page. We have corrected this problem in the next versions.

No. For components (*.PAN and *.OND files) you have to ask the provider for checking the option "File compatible with old versions < 6.40" before saving their components. For other files it is not possible.

We update the database using the requests of the manufacturers, and publish it with each new issue of PVsyst. We can't of course follow all the new products of all manufacturers. It would be very big task, and we don't want to include data without the acknowledgement of the manufacturer. Therefore pleae ask these manufacturers for taking contact with us at support@pvsyst.com.

No, this is quite impossible. There is no model for the retro-transposition to the horizontal plane in monthly values. And no model for the synthetic generation of POA values. Probably nobody knows how to do that.

The albedo is computed by the transposition model, in the same way for each model. Please see the description of the Hay model in the Help "Physical models used > Irradiation models > The Hay transposition model" The Albedo component is the irradiance reflected by the ground "seen" by the plane : AlbInc = ρ * GlobHor * (1 - cos i) / 2 where i = tilt angle. With horizontal plane (i=0), the albedo contribution is null of course. For a"normally" tilted plane, for ex. cos(25°) = 0.906, the contribution is 0.046; for a vertical plane, it is 0.5.

Thank you for the information, we will correct this in the next version.

There was indeed an error when reading the IAM parameters (when defined as a profile) in the version 6.41. This has been corrected in the next versions (since 6.42).

This is the fraction of "information" taken from satellite data (with respect to ground measurements of nearby stations).

As i have already writted in my previous answer, there is no limitation in PVsyst. The limits are in the component's parameters (PV modules and Inverters). In the project's parameter, please read correctly: - IEC (usually 1000V) - UL (usually 600V) This has nothing to do with the simulation, it is an indication of the regulation rules in different countries (UL in the US, IEC for all other countries).

You have probably not read the help "Project design > User's needs ("load") > Load profile: ASCII file definition". This is easily available by typing F1 when you are in the concerned dialog. This gives a detailed explanation of the procedure, and mentions a template for the CSV file within the software. You are strongly advised to use it. Your file is not complete: the line for the unit definition, just after the Colunm's titles, is missing.

I think that using a 64 bits addressing system is not possible with our developing platform DELPHI. But this has to be confirmed with our IT specialists.