André Mermoud

The default values (mainly of Rserie) is adjusted for being as close as possible to the performances of modern PV modules. In the past (version 5), the default highly underestimated the low-light performances (based on a required gamma value of 1.30 or 1.35). This had been corrected for the version 6, where the required Gamma was reduced to 1.1 (on the basis of Sandia large database). But it appears now that this was not sufficient (at least for the recent modules), and I applied a value in a better accordance with all the Low-light measurements I have gathered from official measurements. However this value is still a little bit conservative. See the FAQ How should the Rserie be specified ?

This option is for the choice of the IEC or UL Maximum voltage parameter of the PV module. For a given PV module, you can have simultaneously an IEC certification (most of the time 1000 V), and a UL certification (usually 600V) for use in the USA. During the design, PVsyst will choose one or the other of these parameters according to your choice. For defining a system operating up to 1500V, you have to find a PV module which is certified for this high voltage. These are still very scarce. No more than perhaps 2-3 models in the database in the present time. Otherwise for being able to perform the simulation, you have to change this parameter in your PV module definition (and save it under another file name). But it is at your own risks in the reality.

Strange indeed. Please send your whole project, using "Files" / "Export projects", to support@pvsyst.com.

As I mentioned in my first answer, the Manufacturer SMA has indeed changed this in the database for the version 6.32. Now we update the database using the requirements of the manufacturers. They very often ask for modifying some parameters of existing devices. We don't maintain an historical logbook of all the modifications. With 10'000 PV modules and 3'000 inverters, this would be a very tedious work, which would double or triple the volume of these databases (and seriously complexify its maintenance, which is already a big task). By the way even "official" Datasheets are never definitive: it is almost always mentioned that they may be changed at any time. I have indeed not yet taken the time of mentioning the Temperature dependance of the inverter in the report. Sorry. I should do that for the next version.

If you are connected to Internet, you have a notification as soon as there is a new version available. Please click here. If not, you can always download the latest version from www.pvsyst.com.

I don't understand. I didn't change anything in the program concerning the Inverter behavior for the version 6.32. Please send your full project (using "Files" / "Export projects") at support@pvsyst.com

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.