André Mermoud

PVsyst doesn't allow using the Unbalanced inverters with only one input. And one string of 5.17 kW on the secondary input is indeed strongly oversized for this input. You could define this configuration by increasing the allowed "Overpower loss" in the project's parameters (button "Albedo-Setting). But the simpler way is to redefine the inverter as a device with one only MPPT input.

Therefore this is a bug, that I don't know (and I cannot reproduce). Please send me your whole project, using "Files" / "Export project" in the main menu. Send it to support@pvsyst.com.

The "primary key" of the component's databases in PVsyst is the file name. Now if you modify a component and save it with the same filename as in the database, your customized component will "Hide" the component of the PVsyst original database. After a new installation, PVsyst asks whether you want to keep this masking component, and gives the opportunity of suppressing it. When you personnalize a component of the database, you are advised to give it a different filename.

Which version of PVsyst are you using ? I think I had corrected such a bug some months ago.

You are probably using a SMA central inverter. The manufacturer has changed the specifications about the nominal output power in the database. It is now depending on the ambient temperature, and comprised between PNom and PMax.

In the "Orientation" part, you can choose "Seasonal tilt adjustment".

This behavior is exactly what we want. For the IAM: the manufacturer may change the default IAM value in the his PV module defintions. Now the user has the choice of using the IAM proposed by the manufacturer or not, without changing the PV module definitions. And if the IAM is not specified, the user can specify a customized IAM. The IAM values used by the simulation are reported in the final report. In the same way, this is the case for other parameters like the LID (this parameter is rarely specified, the user may want to use it or not when comparing different modules). And for other parameters like the Auxiliaries of an inverter, etc. The definitive choice for the simulation is always the user's specification in the "Detailed losses".

Yes you are right: the Pmpp calculated at STC influences the Performance Ratio. Please see the discussion about this problem in our FAQ Why is the MPP of my module diferent than the PNom value?.

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.