André Mermoud

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.

I don't know exactly what you mean by SAT These tracking options correspond to different physical situations: in one case you have one-axis trackers, and in the second case dual-axis trackers. The dual-axis obviously gives a higher yield if you don't take the mutual shadings into account, as the PV modules are always perpendicular to the sun's rays. But it implies a more sophisticated (and costly) mechanics. Now with mutual shadings (or backtracking) the performances highly depend on the geometry, the situation should be analyzed in detail using simulations with the exact system's configuration. There are no special assumptions in PVsyst: at each time (each sun's position, taken in the middle of the hour during the simulation), the trackers have a given mechanical position and the transposition model is applied to this plane orientation.

PVsyst provides a database of the main components used in PV systems: PV modules, Inverters, Batteries, Pumps, Controllers, etc. The database in PVsyst should be considered as a service for the users of the program. It is also a service provided free of charge to the manufacturers of the components, who can present their products to the potential users. In providing this service, PVsyst SA tries to stay as neutral as possible, without favoring any manufacturer with respect to another one, and always taking care of providing credible information. The database is updated with each release of the software, i.e. about every month, integrating the requests made by the manufacturers. The database contains data provided by the manufacturers, which should be as far as possible consistent with the datasheets. In cases where certain parameters are not available on the datasheets, PVsyst will propose reasonable default values. The manufacturers have also the possibility to provide values that are missing on the datasheets, through measurements performed by independent third-party companies or institutions. In this case, PVsyst SA will request a copy of the original reports. PVsyst SA reserves its right to edit or reject data that seem not reasonable according to our experience. However PVsyst SA cannot be held liable for incorrect data, nor any indirect damage resulting from the use of the database. There may be transcription errors, or the datasheets may have been changed by the manufacturers. When using a component, you are advised to carefully check the data against the most recent datasheets. Practical information for the manufacturers: To introduce PV modules and Inverters into the PVsyst Database, you should fill out the EXCEL PV component form with the data of your products, and provide the corresponding datasheets along with it. The form can be requested from support@pvsyst.com. After the data has been included in the PVsyst database, the form will be returned to the manufacturer with the exact data as present in the database. The form is organized in columns, and each column header contains information about how to fill out the different fields. You can directly copy and paste the component's data between this EXCEL document and the PVsyst program. As a general rule, components will never be removed from the database, as they may have been used in previous projects. For each component in the database, the years of introduction to and removal from the market can be specified. Manufacturers are strongly advised to carefully update the date of removal from the market for the obsolete components in the database.

The "PAN files" hold all the definitions specific for a PV module in the database of PVsyst. These definitions may be either a file (*.PAN), or a CSV string in the EXCEL document representing the PV modules database. NB: this denomination comes from the very beginning of PVsyst in 1992, when the program was written in French (the file extension ".PAN" stands for "Panneau PV" which is the French word for PV module). The main parameters governing the performance of a PV module are: - The PNom value which is the basic definition of the module (nameplate value), - The STC specifications Isc, Voc, Imp, Vmp, normally taken directly from the datasheets, - The temperature coefficients musc (alpha), muVco (beta) and muPmpp (gamma), from the datasheets. - The optical performance, i.e. Incidence Angle Modifier (IAM) which induces a loss for not-normal incidence angles, especially important for the diffuse part. The model of PVsyst requires a set of additional parameters which affect the operating performances: Rshunt Shunt resistance, the inverse of the slope of the I/V curve around V = 0 at STC. RshExp Characteristics of the exponential-like behavior of Rshunt as function of the irradiance, Rsh(0) Intercept of this exponential at Irradiance = 0 Rserie An internal parameter of the one-diode model. Should not be confused with the slope of the I/V curve at I = 0, which is named RserieApp (for apparent) in the software. The Rserie is the main parameter governing the low-light performance. Gamma (diode ideality factor) is closely related to the Rserie value during the calculation of the model parameters, and is not considered as an additional unknown parameter. muGamma is a linear deviation of the Gamma value (diode ideality factor) as function of the temperature. It can be viewed as a correction for getting a specified muPmpp (in PVsyst, mu stands for "temperature coefficient). d2MuTau Specific parameter for the recombination term, only relevant for amorphous and CdTe modules. IAM Incidence angle modifier as a function of the incidence angle. These additional parameters are usually not mentioned on the datasheets, and the difficulty is to find their values according to further information for a given module. Rserie is the most important parameter and has a great impact on the Low-light efficiency. Its determination is crucial for the model. See How should the Rserie value be specified? for details. Rshunt, RshExp, Rsh(0), (and Rserie) Sometimes measurements are performed for a set of different irradiances and temperatures according to IEC-61853-1. Then this data is used to perform a general fit, using all parameters Rserie, Rshunt, Rsh(0), RshExp and muGamma as variables. In such kind of fit, the Rshunt, Rsh(0), RshExp are usually "adjusting" parameters, which may take values very different from their physical observed value, in order to satisfy the fit. Of course the result of a fit (residues) is better when using more parameters. However if the parameters are not well implied in the equations, erratic values may lead to unstable solutions: slightly different measured values may give completely different parameters, leading to erroneous results when applying the parameters to modules with slightly different STC input data. This is the case mainly when we extend the results of the fit to other modules of different powers (i.e. different qualities of manufacturing). This is the reason why we prefer keeping these parameters concerning Rshunt (i.e. Rshunt, RshExp and Rsh(0)) as close as possible to the default values, modifying them only if it is really necessary to reflect direct measurements. And we adjust the Rserie parameter in order to get the measured low-light relative efficiencies at 25°C. We do that identically for all modules of a power series, but we don't have any proof of the validity of this hypothesis as we never got systematic measurements for different power classes of a same module type. As another example, the Temperature behavior of the Pmpp issued from the global fit may be significantly different from the direct measurement at 1000 W/m2 specified on the datasheets. In a general way, we sometimes cannot accept the results of these multi-parameters fits for the database, as we don't have a mean for extending it to other modules of different powers in the same series. The methodology is too different from the standard parameter's choice used by all other manufacturers, and this may lead to irrelevant discrepancies between manufacturers in the simulation results. Incidence Angle Modifier (IAM) function The IAM function represent the additional reflection losses when the irradiance is not perpendicular to the PV module area, with respect to a normal incidence. The IAM profile is specified within the PAN file. The standard behavior in PVsyst is the ASHRAE parametrization with bo = 0.05. If you want to specify a custom profile in the database of PVsyst, we will require a full report of measurements performed indoor by a third party laboratory. Since january 2017, we don't accept outdoor measurements anymore - even if they are performed according to IEC 61853-2 - because the proposed methodology seems not sufficiency reliable. See the post How to deternime the IAM profile ?

The determination of the PAN file parameters, and especially Rserie, have evolved over time according to our progressive understanding of the one-diode model parameters significance and implications. When computing the one-diode model, the Rserie and Gamma value (diode ideality factor) are strongly interrelated variables. At the beginning, we chose to fix the Gamma parameter as default value in the model's calculation, as it was independent of the module size. Rseries and Gamma (diode ideality factor) interrelation in the one-diode model In PVsyst Version 5, according to our long-term outdoor measurements on several modules, we first fixed the default value Gamma to 1.3 for mono-, and to 1.35 for poly-crystalline modules. The practice revealed that this choice was very conservative. NB: This default is specified in the hidden parameters, you can change it, if desired. With the development of PVsyst Version 6, we had the opportunity to analyze a set of measured data, recorded outdoor by the Sandia National Laboratory for about 100 modules (Sandia model). This lead us to change the value of the default Gamma to 1.1 which has become the default since version 6, and up to V 6.25. Gamma value recomputed for the modules of the Sandia database. However, we observe a big discrepancy between outdoor measurements and the usual indoor measurements performed by flash-tests. When low-light measurements are available, we adjust the Rserie accordingly. In most of the recently reported measurements, the relative efficiency lies between 0.5 and a maximum of 1% in the 600-800 W/m2 range, and is around -3% for 200 W/m2. When data overcome these values we are extremely careful when checking the reported measured data. It seems that the most recent modules, and some special technologies, may show very good low-light performances that overcome these averages. Low-light performance for different hypothesis (Rseries choices) Now we got many independently measured values at different irradiances, according to the new IEC-61853-1 norm for recent modules (indoor measurement). We observe on these data that the the low-light performance are rather comparable for all modules, with a relative efficiency drop of about 3% or less (up to 1%) at 200 W/m2. Therefore since the version 6.26, the default Rserie value is fixed in order to get a -3% relative efficiency at 200 W/m2. Otherwise in the database, when the manufacturer provides low-light efficiencies, we use to set the Rserie in order to get the low-light performances approaching the measurements at best (although we don't know the evolution of the low-light performance according to the power of then module within the series, i.e. its quality). Effect on the yiels We can mention that an increase of 1% on the 600-800 W/m2 region represents an increase of about 1% for the annual yield. This is not very dependent on the climate. Effect of Rseries or Ganna choice on the yield NB:The indoor performance reported by manufacturers usually corresponds to very low Gamma values, often below 1 and down to 0.9. Remember that from the physics point of view, the one-diode model is a simplification of the two-diodes model, with Gamma=1 for the diode describing the diffusion loss, and Gamma=2 for the diode describing the recombination. The Gamma value in the single diode model should represent a mix of these 2 diodes, so that its value should lie between one and two. The discrepancy between outdoor and indoor measurements is not fully understood. Probably the unavoidable diffuse component in the outdoor measurements is higher at low irradiances, and is subject to higher IAM losses. Furthermore, the module sample measured at Sandia is rather old, and the low-light performance may have increased in recent technologies. Recent measurements performed by research teams seem indicate a better match between indoor and outdoor measurement for a same module. As a side note we mention, that when a manufacturer specifies the Rserie values (and sometimes also modifies the Rshunt, Rsh(0) and RshExp), we always require a measurement of the low-light performance at 200, 400, 600 and 800 W/m2, performed by an independent institute. Even in this cases, it happens that we need to perform a small correction on the submitted values, to ensure a coherent behavior of the modules in the simulation. Representativity of the measured modules The measurements are usually performed using a very limited sample of modules (1 – 3 modules) chosen from the middle or upper part of the power range of a given manufacturing batch. The results are then applied to all modules of the range. Several questions now arise : - How representative is the measured module for the entire batch? - How is accounted the LID degradation? The official measurements are usually performed after LID, when the individual performances measured for each module at the output of the manufacturing line are obviously before. - Will it stay representative for the future productions? - How was the module chosen (most of the times by the manufacturer)? - What is the evolution of the low-light performance within the manufacturing batch? When establishing the parameters in the database, we assume that it stays constant at all powers. But this is really a doubtful hypothesis. To confirm it, one would need a systematic measurement of several modules from the same manufacturing batch, but with different powers (i.e. manufacturing quality). We never saw any publication nor got data of this kind.

In his documentation and advertising, a manufacturer presents PVsyst simulation comparisons with modules of other manufacturers, and claims that according to the PVsyst simulations, their modules behave better than those of competitors. PVsyst SA cannot endorse this claim! The one-diode model as implemented in PVsyst is well established, and confirmed by long-term outdoor measurements. However the parameters used as input to the model are not part of the official specifications of the modules, and they are not always known or set with perfect accuracy. Therefore it is not possible to perform meaningful comparisons of PV module performances with the PVsyst simulation, without first making sure that the sensitive parameters (Rserie, Rshunt, IAM) have been established with the same methodology. When taking module data directly from the database, such an assumption cannot be made straight away. It is not legitimate and unfair to use PVsyst for comparing and publishing explicitly the performances of competitor's products without showing that the input parameters for the models have the same degree of accuracy. The default values that PVsyst uses in the case of lacking measured parameters, are deliberately conservative, and they tend to underestimate the real performance of the modules. Namely, for the particular case in question, we note: Rserie For some modules of the comparison, the Rserie value has not been specified by the manufacturer, so that the default value of PVsyst was used. This default Rs value was particularly conservative in the version 5. It was improved in the version 6, and tends to usual manufacturer's low-light data since the version 6.26 (see the"possible yield differences betwenn version": Special IAM definition In this particular case, the definition of the IAM behavior has been significantly enhanced for the modules of this manufacturerin the PVsyst database, which gives an advantage of the order of 1.3 to 1.9% in yield with respect to the IAM default function (ASHRAE with bo = 0.05) as used for all the other modules. The IAM behavior has been measured for 2 modules of this manufacturer, by an independent laboratory, following the new IEC 61853-2 standard (draft). This measurement gives results which are much higher than the ASHRAE standard model used as default by PVsyst, especially in the range 45° to 70° of incidence. This raises several questions: - Is the glass used in these modules so special, that it can explain such an enhanced behavior ? According to this manufacturer, it is an anti-reflecting coating. deposited on the exterior face before or after the glass tempering operation (depending on the glass manufacturer). - If so, are all the modules of this manufacturer equipped with this special glass? According to this manufacturer, recent poly modules with Pnom >= 250 Wp are equipped with this glass. But some other modules in lower ranges have also been specified with this IAM correction in the database. - Is the standard ASHRAE model really too conservative for the commonly used glasses? (The few measurements we know of are rather contradictory). In this case the PVsyst default should perhaps be revised. - Which kind of glass is used in the other modules for which the IAM has not been measured? Are they significantly different? See also How to establish the "PAN files ?.

Sorry, this information is not available in the Meteonorm program implemented in PVsyst (as provided by the Meteonorm team).

The opportunity of defining chosen *.VCi in the batch mode for reruning all of them at a time is available since the version 6.26.

Formally, you are quite right. I will correct this for a next version. However the error is not very important: if we take Alpha = 0.9 and Effic = 15%, the error (1-Alpha) * Effic = 1.5%. This is a correction on the U-value, which is usually not known with a better accuracy than perhaps 10 % or more. The only cases when this U-value may be well known is when you fit it on your measured data. But in this case, if you fit it with this erroneous equation, the simulation result will be coherent with your measurement !

When in the batch mode definitions, you tick the box "Create Hourly Files", you will be prompted to define the variables to be listed in the hourly file. Then, in the parameter specification list in EXCEL, you should have a column "Create Hourly File" / "File name". In this column, you should define a filename for each desired hourly file (usually with CSV or TXT extension for an easy reading in EXCEL).

I can't give a definitive explanation if I don't reproduce the problem by myself. It is not clear what are the conditions between your two runs, if it is with the same version of the calculation version, etc. Some hidden parameters may have been changed. In the Parameter's part, the Imp/Vmp values are computed from the model at 50°C. The data of this module have not been changed in the database since 2012. However the reference temperature may have changed. There are many calculations by successive approximations in PVsyst. Usually they give stable results, but there may be exceptions. Now please admit that a discrepancy of 0.012 % is not really worrying...

In the 3D scene, the orientation of the modules is not dependent onorientation of the building. However if you have to put your modules not perpendiculary and to define rows of different lengths, you have indeed to define each row independently. If the rows have the same width, you can define a lateral shift from row to row ("misalign" parameter).

It is a usual belief to think that systems with string inverters have a better yield than centralized ones. I am not sure of this, if there is a differece, it is probably very low. How can this be taken into account in PVsyst ? - The main implication I can identify is the electrical mismatch losses under partial shadings. This graph shows that with one only string on one MPPT,the loss is limited (blue line); but as soon as you have two strings or more in parallel on one MPPT, the electrical yield for beam becomes null as soon as you have 1/3 of the submodules shaded (i.e. the case of sheds, with the bottom cell's row shaded). See also How to evaluate the effect of by-pass diodes in shaded arrays?. Electrical Shading loss acc. to number of strings on the MPPT This diagram shows that the configuration of "One only string per MPPT" will indeed have a lower electrical loss. Equivalently, if you put all bottom strings of different tables on a same MPPT input, you will get the same result. This configuration should be preferred with string inverters with few MPPT inputs. - The wire length variations - and therefore wiring voltage drops - are obviously higher for centralized systems. A new tool of PVsyst will show that the mismatch between strings of different voltages is extremely low. As an example: for a 500 kW array and 4mm² string wires, one central inverter would have 0.17% mismatch loss, when distributed string inverters with 2 strings per MPPT would have 0.05%. - The number of MPPT (centralized or distributed systems) may have consequences on the wiring layout. It is your job to define and optimize the wiring and therefore to calculate the wiring resistance of the PV array or the full system. - Big inverters may have a higher MPP tracking inefficiency (due to response time). PVsyst doesn't define this inefficiency: it assumes that it is included in the inverter's efficiency profile. However very few manufacturers give information about this inefficiency. - With big systems we can imagine a mismatch effect because of inhomogeneities due to clouds passages. These are transient phenomenons, not really significant on the hourly accumulations of the simulation. By the way the mismatch loss between strings of inequal irradiances is usually very low. - Finally, an inverter failure will be easily managed with string inverters, when it penalizese the running of the full centralized systems. This could be taken into account when specifying unavailability losses. Besides these arguments, I can't see any significant difference between centralized and distributed systems, which could be taken into account by the simulation.

Once more: If PVsyst applies a correction, it is because the data are not correct, or not correctly imported due to a time shift. This has implications on the calculations during the simulation, and should be corrected. The errors usually arise when importing POA measurements, and are due to the fact that if the retro-transposed Global or Beam horizontal values are higher than the clear day model (by a significant amount which is specified in the hidden parameters), PVsyst will limit it. This will arise either in morning or in evening hours, when the sun is low on the horizon (low sin(HSol) varying quickly with the time). With even little time shifts you can easily get Normal beam components of 3000 to 5000 W/m² at the sunrise or sunset. How PVsyst will manage this during the simulation ? However I don't understand well your assessment that you have differences with Ghi/Dhi, as in this case there are no calculations during the import. Except if for some hours your Diffuse part is greater than the global part: this doesn't make sense and the simulation will not understand that !!!

The backtracking strategy requires complex geometric calculations. In PVsyst, it is not developed for any situation. There are several limitations, for which I did not find the suitable algorithm. The backtracking is based on a given collector width and pitch between trackers. Therefore it is only defined for a set of trackers specified as one sub-field in the 3D geometry. These parameters cannot be different for different sub-fields in a same system (or the backtracking will be established on the less favourable sub-field). Single axis systems: - The backtracking works well with horizontal axis systems. - For tilted axis systems, it works well with usual configurations. But it cannot be defined if the azimuth of the axes within the sub-array is not null (i.e. if the trackers are shifted with respect to each other). However it is possible if the whole sub-array is not south-oriented (azimuth of the whole 3D object). - It is not possible to define backtracking between trackers of different altitudes, because you cannot (in the present time) specify an east-west slope for a tracking sub-field. - For Vertical axis, the backtracking is not implemented as I couldn't find an algorithm. Two-axis systems - For usual two-axis systems, there are several possible backtracking strategies. The only one implemented in PVsyst in the present time is by following the sun height: the azimuth is then adjusted for avoiding the neighbour tracker's shades. This strategy alone is not very efficient, especially at lower latitudes where the east-west sun position is preponderant. When the azimuth is big (east-west directions), the system should adopt another strategy: following the sun azimuth and applying the backtracking to the tilt. This is not implemented yet. The backtracking from one row to the next one would require to define the Tracker's nord-south pitch and shift (i.e. between 2 different rows), and would apply to the tracker's tilt. Moreover it would be correlated to the backtracking of the row (either in azimuth or in tilt). As for the previous case, I didn't find the algorithms for the general case, and this is not yet implemented in PVsyst. Therefore backtracking strategy is not really useable for two-axis systems. For Tracking frames, the backtracking is implemented between trackers within the frame, but not from frame to frame. If analytical or geometrical algorithms are too difficult, I will probably try to approach the problem by successive approximations in a future version.

There is no formal limit to the system size in PVsyst. However for very big systems (dozens of MW), the calculation time may be prohibitive, and even the management dialog of the system may become unworkable. There are several bottlenecks: - When near shadings are used: the calculation of the shading factor requires to compare basically each elementary surface to each table (goes with the square of the number of elements). Therefore you should define "tables" (areas for receiving a set of modules) as big as possible in order to limit their number. In the version 6 there is an optimization which may gain a factor of ten. Please check that for your simulation, this optimization is effectively active (in the 3D editor, menu "Tools" / "Optimized shading calculation" checked). - This calculation time for the shading factor is especially penalizing when establishing the shading factor table (prior the simulation) , which involves a calculation for 190 positions, and may spend several hours. - A significant time may also be due to the pre-calculations for the optimization of the shading factor calculation, or the check that each table should not interpenetrate any other table or objects. - When using "Module layout" for electrical mismatch effects, defining more than 1000-1500 modules becomes impraticable. And this results in very long simulation time. For very big systems, you should perform a simulation with Module Layout on a reasonable subsystem, which will give you an electrical loss value. Then you can use the simulation on the full system with the option "According to strings of modules", and adjust the "Fraction for electrical effect" in such a way that you get the same electrical loss. - With string inverters, the simulation is performed for each inverter input, which significantly increases the simulation time. We are working on the improvement of the calculation performances, by optimizing the algorithms. We will also develop a parallel calculation for a better use of multicore processors, which should be available soon.

The effect of the IAM on the diffuse component is calculated assuming an isotropic diffuse distribution. It results of the integral of the IAM loss over all directions of the sky "seen" by the PV module. As this value is independent of the sun's position, it is constant over the year, and applied to the diffuse component at each step of the simulation. The same stands for the Albedo component. NB: This integral is indeed performed simultaneously with the shading factors if horizon or near shadings are defined. Sorry, I discover that this part of the help is incomplete and rather old: I have updated it for the next version 6.26

The horizon is considered as significant only when some values overcome 2°.