André Mermoud

The easiest way is to open an existing similar inverter, modify the parameters according to the datasheets, and save it as a new filename. For the efficiency, you can simply define a Maximum and a EURO efficiency.

Please explain what you mean by "Default hourly data storage parameters" ? Which list ?

No, very fortunately Meteonorm 7.2 doesn't take an horizon into account. This kind of implementation/correction is very difficult to manage in the simulation. See How is treated the Horizon contribution in Meteo data ? However the Meteonorm Software allows to create an horizon line for your site, that you can import in PVsyst.

This is now obsolete, you should put 0. In old PV systems, it was a common practice (and even a rule in some countries) of putting a diode in series with each string, for avoiding drawing current from one string to anothe weaker one. This is completely useless as the string voltages are quasi-identical, whatever the irradiance or electrical losses. Therefore the diode is never activated.

Yes, it is possible since the version 6.73. Please use "Databases > Import ASCII Meteo files" and press F1 for the procedure.

Sorry, there is indeed a big problem in the version 6.74 with the CSV Hourly files creation. Many variables are null, or are not available in the list. There is no workaround. Before the publication of the version 6.75, the only way for creating relevant Hourlx files is to revert to a preceding version.

This limit is a safety condition for the inverter and system. The principles of the condition is explained in the FAQ "How to adjust the design temperatures ?" This is not an invention of PVsyst, it is mentioned in the IEC norms. Now you can adjust the Tmin value (minimum temperature ever measured at this site) in the project's parameters (button "Project's settings")

Defining the South as 0° azimuth in the northern hemisphere, or the north as 0° azimuth in the southern hemisphere, is a choice, done in most of the software dealing with solar energy (and adopted by many meteo researchers). See our FAQ How is defined the plane orientation ?

The Helios3D systems are usually defined with a baseline slope om a hill. This changes the true orientation of the plane of each table. Please see our FAQ With tilted roofs, PVsyst changes my orientation

Solfocus modules have never been included in the database of PVsyst. For defining a CPV module, we have to closely work with the manufacturer, with very specific tests/measurements. This has only been done with Concentrix/Soitec up to now.

When you perform a study for the forecast of a new installation, you should indeed use an average over many years. The period doesn't have much importance. Now you can get more recent data from private companies, but this will be for pay. Remember that a simulation performed with one only (measured) year - even recent - will be less reliable than an average, due to the annual variability of the meteo data.

Yes sorry, this is a stupid bug in the version 6.73, which will obviously be corrected in the V 6.74. In the meanwhile, the only way for correctly defining this parameter is to revert to the previous version 6.72.

If you are licensed, you can get any old version of PVsyst from our web site www.pvsyst.com. You can install several versions of PVsyst in parallel on a same machine. All of them will use the same license, and may be run independently without interactions. But be careful: if you try to read a file created by a newer version, the file may be unreadable with older versions.

Yes sorry, this is a stupid but in the version 6.73, which will obviously be corrected in the V 6.74. In the meanwhile, the only way for correctly defining this parameter is to revert to the previous version 6.72.

For importibng your meteo data you should use "Databases > Import ASCII Meteo files". For the calculation of GTI (usually named POA, or GlobInc in PVsyst), you can use "Databases > Meteo Tables and Graphs". Here you can get tables in hourly, daily or monthly values, with the GlobInc values ("Global Tilted Plane").

For the orientations definitions in PVsyst, please see the FAQ PVsyst will not redfefine the azimuth you have chosen of course.

For limiting the power, you have to redefine your inverter ".OND file with a new PNom value. There is no way in PVsyst for limiting the inverter power (as there is probably no way in your physical inverter for artificialy limiting the power !). NB: The simulation doesn't check the output maximum current. If you overcome the specified value, it is probably either because it is not well specified, or your output voltage is too low. PVsyst doesn't manage the grid voltage.

The Rotation limitations are the mechanical constraints. You cannot overcome them of course. The "Phi limits" is the value for which the backtracking begins to be operational (i.e. when the mutual shadings begin). At any time, the Phi value will obviously be limited by the lower of these 2 limits. Now when the sun continues to go down, the backtracking angle will come back below 60°. You can visualize this behavior as function of the sun's position, in the "Orientation" part, "Horiz. axis Unlimited trackers".

This is not so simple. Even if some irradiance is reaching the array through the tree, remember that în a string, the weakest cell (lower irradiance) drives the current of the whole string. There is a high probability that one cell in a string is fully shaded, therfore blockîng the full string. In other words, you can have a reduction of the Linear shading losses, but an increase of the electrical mismatch losses. Moreover, you should define the period for which this correction would be applied. We don't intend to introduce such a complex correction in the present time.

With SolarEdge optimizers, the maximum power of a PV module is not defined as the Pnom (STC) nameplate value, as for any other sizing. It is indeed the maximum power delivered by this PV module over the whole year, for this array disposition, in clear sky conditions. This was a reqirement of SolarEdge people when developing the SolarEdge devices in PVsyst.

The integral supposes that the diffuse is isotropic, i.e. that the irradiance is the same whatever the sky direction. Now with a tilted plane, PVsyst executes the integral of the incident rays (for each direction "seen" by the plane", i.e. the orange slice between the plane and the horizon) affected by the IAM function for this incidence angle. This is not the integral of the diffuse, but the integral of the IAM effect (which is a relative loss). The effective results of this integral are indeed not very intuitive. I don't have a clear explanation.

PVsyst uses the one-diode model established from the usual STC data (on front side). When using the bifacial gain, the back-side irradiance is simply added to the GlobEff value on the front side, with a coefficient named the "Bifaciality factor". The increase of ISC current with bifacial irradiance is not relevant. This is an operating condition. When you are using a module at anothe irradiance than 1000 W/m2, you don't take care of the ISC at this irradiance: this is a result of the model.

We don't know this bug. However this arises in an old version, we cannot modify the old versions.

The first and last hours of the day are partial hours (e.g. morming: between sunrise and the full hour). In these cases PVsyst calculates the solar geometry in the middle of the interval (sunrise hour - full hour), not in the middle of the hour.

See the FAQ What is the new loss "Global incident below threshold" in the loss diagram ?