André Mermoud

The parameter for the module quality represents a loss. Therefore if it is positive, it will lead to a loss, and if it is negative, it will produce a gain during the simulation. For example for a module specified as (+0 .. +3%) tolerance, the default value will be -0.75%.

The default value for Rseries has changed. This affect modules for which the Rseries has not been specified by the manufacturer. Please see our FAQ How should the Rserie be specified ?

The presizing tool cannot provide "definitive" results, but only evaluations based on weather series. It is based on a random process of synthetic generation, and will give different values at each execution. Please see our FAQ How to size a stand-alone system?

The Voc temperature coefficient is a result of the PV model: you don't need to specify it explicitely. See our FAQ How to adjust the Voc temperature coefficient? If not specified, Rshunt and Rserie will be chosen by PVsyst as default values. See the FAQ How to establish the PAN files ?

The sizing tool for the stand-alone systems works on a random hypothesis. From the monthly meteo data, PVsyst constructs a series of days using the synthetic generation model. And then applies a simplified simulation over all 365 days (taking the daily stored energy balance between your meteo data and your load defintion for each day). This is of course strongly dependent on the random choice of the days series, and can vary from one execution to another one. In a future version the annual evaluation will be performed several times, and a statistical estimation (much more stable) will be provided.

No this is not possible in PVsyst. The only way is to take these values into account in the "Mismatch" loss parameter. NB: By the way this may be useless: if your modules are subject to LID degradation, the original flash-test data (at the output of the factory) are no more valid in the field.

There is indeed a problem here. The Time zone is not included in the SolarGIS monthly data. PVsyst has to set a default value. Up to now the defaut value was just taken as a function of the longitude, which is not correct for everywhere. In the version 6.31, we have introduced the reading of a web service (when available). However it seems that this does't work well in all cases. This will be corrected for the next version 6.32. In the meantime for reading your SolarGIS files you should reinstall the version 6.30 (available from www.pvsyst.com). You can install it in parallel with your version 6.31.

No, there is no way of file input in the present time, except using the format specified for the Helios3D files. However if your "tables" are regular (pitch and spacing) you are advised to use arrangement in sheds. And specifying "long" sheds instead of 10m tables will also strongly reduce the calculation time.

As explained in the FAQ: - At the creation of a calculation version, the Module quality loss is pre-defined at a value according to the module's tolerances. This is a default value. The quarter of the value between Min and Max tolerance is my own choice. - This parameter is at your disposal: you can change this value for taking any other phenomenon into account, according to your requirements or your judgement.

The IAM performance and bo factor are not dependent on the module positioning in any way: this is an intrinsic characteristics on the PV module cover (glass with or without antireflective coating). Now in your situation the orientation of each table will be different due to the base slope (see the FAQ about tilted base slope). In the present time, only the terrain representations provided by the Helios3D software can treat the case of spread orientations, and in an approximate way: PVsyst assumes an average orientation for performing the simulation. We are preparing our own possibility of terrain representation and PV modules covering with adapted baseslopes. This will be available very soon. However this will not give any answer to your question about the performance of centralized or decentralized MPPT. I don't see how to do that with PVsyst.

Yes the horizon of the 3D scene corresponds to a view "height" angle of 0°. This doesn't take the earth curvature into account of course. However the horizon is not implied in the 3D near shading calculations (only in the "Far shadings"). The shadings of 3D objects ("near shadings") are always mutual shadings from nearby objects, and are indeed related to the relative altitudes of the objects. However if you place the origin of your whole scene at -100m or +100 m will not change anything.

The PVsyst simulation works on the basis of the meteo data file used as input. PVsyst doesn't provide any mean for modifying the meteo data, and I really don't know any model for doing this in a representative way. If you want such special data, you should get them from meteo data providers (these will usually be measured data). Now you can have a look on the publication "Global irradiation: average and typical year, and year to year annual variability", Pierre Ineichen, 2011.

The LID loss is only available with Grid systems, and only makes sense for Crystalline modules. I just see that it is not activated for HIT modules, this is a mistake, corrected in the versin 6.31.

The calculation of electrical shading losses (shadings "according to module strings") is based on the hypothesis that when a little part of a string of modules is shaded, the whole string is supposed not to produce anymore electricity (for beam component). Up to version 6.26, the criteria during the simulation was that as soon as the "Linear" shading factor is not null, the electrical effect is accounted (ON/OFF) for the whole string. However with the shading factor table, this created an artefact: if you have a little shading at sun's height = 20°, the "linear shading factor" (which is an interpolation between 20° and 30°) is not null up to 30°, so that the electrical shading is activated for the whole interval. When comparing with the analytical calculation "Unlimited sheds", this gave overestimations of the electrical effect of about 2-3% for one module in landscape (less for 2, 3, 4 strings in the width of the shed). Therefore since V 6.27, the electrical effect is only activated when the "Linear shading" calculation exceeds a threshold. This threshold was established by comparing the results with the "Unlimited sheds", which is supposed to be much more reliable as it is an analytical calculation. This threshold depends on the number of strings in the width of the shed. It also takes into account the fact that when the first bottom row of cells is partially shaded the electrical loss of the string is partial. However this new strategy may have unexpected effects: for example if you have HV lines over your plant, the "Linear shading" factore may be insufficient (below the threshold), so that the "Thin objects" electrical calculation is not activated. In the present time we don't have an automatic solution for addressing this problem. NB: You can modify or suppress the threshold (for example in the latter case) in the hidden parameters, topic "Miscellaneous: meteo, simulation", item "Threshold shading factor from table for module activation" if you are using the table calculation, or "Threshold shading factor from calculation for module activation" if you are using the calculation within the simulation ("Slow" option).

You are right. I will check this. However this parameter governs the reverse characteristics of one cell (the current for a given reverse voltage). It is not involved in the simulation process (or very very slightly in the Module Layout shading calculations, when only one corner is shaded). Its effect is visible in the pedagogic tools for the understanding the reverse characteristics of a cell/module.

This is quite normal. Evaluating the average irradiance over the whole day (including beam, diffuse and even albedo) is not intuitive ! As an example, in summer at these latitudes, the sun goes far beyond east in the morning and west in the evening: with planes as tilted as 30°, the sun is behind the plane or at very high incidences. This is a significant loss by respect to the horizontal irradiance, which is not affected. Using "Tools" / "Meteo tables and Graphs", you can plot the meteo data (Global horizontal, and Global on 30° plane), in hourly values. Please observe a clear day in June: you will see that the Global plane is slightly higher around midday, but significantly lower during the morning and the evening. And not very different for cloudy days.

I have just found a routine which is executed very often for a same calculation during the simulation. I never suspected this routine as it is a very simple one. This expecially affects the simulation of systems where the numerous tables are not grouped into arrays ("fields"), like in the Helios3D scenes. Correcting this substantially reduces the execution time of the simulation when using the Shading factor table. This correction will be included in the next version 6.31, to be released soon.

The cable diameters is only a "help" (or additional information) for the calculation of wiring resistive losses. The relevant parameter is the wiring resistance. This is the only parameter used for the wiring loss calculation. For big or complex systems you are advised to calculate it by your usual calculation methods, without relying on the PVsyst propositions.

Defining such a number of slaves doesn't make much sense. With 2 inverters in Master/Slave, you gain a little bit because of the better efficiency at low powers (less than 1 to 2% with bad inverters) With 3 inverters, the gain is imperceptible. Beyond this number it is completely useless. Using Master/Slave configuration is not harmless: it forces to connect all concerned sub-arrays in parallel. This is not necessarily a good idea. NB: In your case you can define 2 x 6 inverters in master/slave if you want: the simulation result will be exactly the same.

I don't remember when I had done this correction (probably in an earlier version). Please try to update. If this error persists, I don't have an explanation. Please send me your full project, using "Files" / "Export projects" in the main menu. However such a discrepancy on only a very few of hours should not produce a big error.

Yes, I have just discovered an error in the interpretation of the UT when importing some Helioclim data files. This will be corrected in the next version 6.31. In the mean time you can send me the original Helioclim file, and I will create your MET file (send it to support@pvsyst.com).

I have increased the number of decimals for the settings of the muPmpp value. However I don't intend to allow the explicit specification of muGamma as it is not a "physical" parameter.

No I did not yet perform this correction. However its effect should be very little. But I don't understand what you are trying to calculate: the U value is an input parameter. On which data are you calculating it (i.e. which Tarray are you using ? ). PVsyst doesn't make a difference between Tcell and TArray: if there is any, it will be included in the U-value. If you have TArray measurements, you can plot (TArray(meas) - Tamb) as a function of GlobInc. Then you can obtain the U value by a linear fit on your data, and by identification of the slope to the energy balance equation: Uc = Alpha * (1-EffArr) / Slope

Yes, if your module has not an explicit specification of the Rserie in the database, this is certainly the effect of the new default choice for Rs, according to the relative efficiency instead of the diode quality factor. The value of Rserie may also have an effect on the temperature behavior if muPmpp is not explicitely specified. Try to resimulate with a same fixed Rserie.

Your calculation seems to be correct. I can't understand that this is depending on the pitch of the modules: it is completely unrelated. However for the sunrise and sunset hours, the solar geometry is not calculated in the middle of the hour, but the middle of the interval between sunrise and the next hour. This may be the cause of your difference.