André Mermoud

PVsyst has to associate each subfield to a given orientation specified in the "Orientation" part. Now when you have a "normal" system, PVsyst has to "identify" the orientations by comparing the subfields. For grouping the subfields in different orientations, PVsyst needs a discriminating criteria which is the "Discriminating orient. difference between shading planes". When you have planes with very close orientations you have sometimes to diminish this parameter (default value = 1°). Now with Heios3D systems, the different slopes of the baselines according to the hill slopes give a "continuous" distribution of orientations. With the preceding criteria PVsyst will find a multitude of different orientations. Therefore when recognizing such systems, PVsyst regroups all the tables of the orientations distribution into one only average orientation, and will calculate the simulation using this average orientation (which is an approximation). Now the parameter "Maximum orient. difference for defining average (spread) orientation" defines limits for this spread. Sometimes you have to extend these limits. In this case you should be aware that you will increase the uncertainties for the transposition model. NB: the mention "Heterogeneous fields: maximum angle difference for shadings" concerns an obsolete limitation in the version 5, where the "Multi-orientation" was not yet available. We have to suppress this from the Help.

Which version are you using ? In the versions 6.40 and 6.41, there was indeed a problem in some specific cases when mixing Near shadings and Horizon shadings. But the error was not so significant than in this example. If you are using another version, please send your full project (using "Files > Import projects" in the main menu), to support@pvsyst.com.

You have tried to open the Formatting file (*.MEF) instead of the HelioClim Data file. This is not correct. The formatting file should be put in the \Meteo\ directory, and chosen using the comboBox "Format protocol file". NB: HelioClim has perhaps changed their format. However it seems that they now distribute their data also in the Standard PVsyst format. Please try to import these data using this option in "Import Meteo Data".

I don't see well your configuration, the shading objects and the disposition of the modules. I find rather strange that you have a shade at 12:00 and no shade at 11:45 or 12:15: please have a look on the shade drawings. Perhaps you have a rather thin shading object, and the shades don't affect the corners of the submodules, which are taken as reference for the shading evaluation in the Module Layout part.

The difference in time shift is really a significant feature, especially 42 minutes. Please correct it for both files, and compare again. By the way, the results may also depend on the hourly distribution of the irradiances.

In this case you should specify PNom = 42 kW (in terms of energy). The Pnom = 47 kVA will be the power attained with a cos(Phi) of 0.9. However this cos(Phi) is not a basic parameter of the inverter, it is an operating parameter (only the limits for Cos(Phi) are a specification of the inverter). Therefore you cannot give a specification like (PnomApp[kVA]), as it will depend on the operating conditions. If the manufacturer specifies a PNom value in terms of Apparent power [kVA], this corresponds indeed to an output current limit. In this case the PnomEff[kW] will range between 42 kW (cosPhi=0.9) to 47 kW(CosPhi=0) NB: The PMax parameter in PVsyst in not related to the Power factor: it is a possible derate of the nominal Pnom value, when the temperature is sufficiently low.

The temperature loss depends on: - The Ambient temperature, - The array temperature, related to the ambient with irradiance and eventual wind velocity, according to your Uc and Uv values. - The PV module temperature behavior (according to the one-diode model). To my knowing, the temperature loss is stable when repeating the simulation. Please explain in what is is not consistent.

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.