André Mermoud

In "Databases > Meteo Tables and graphs" tool, you can create a table in hourly values, and export this table as a CSV file (menu "Export") You can reupload this file using "Databases > Import ASCII meteo files".

This representation is quite correct. The efficiency is defined as the Pout / Pin ratio. Now if the Pout is limited to the PNom value, the efficiency Pout/Pin will obviously diminish above Pout, in the way shown on the graph. Now for the "unreasonable" Overpower loss: - Please remember that the value in the sizing tool is a rough pre-evaluation, just for helping you to design your system. The reliablel value is the result of the simulation. See the FAQ Why the overload loss is not the same at designe time as in the simulation ? - In some conditions (high array voltage), the overpower may significantly increase. See the FAQ Why sometimes the overload losses increase significantly ?

These values are simply the plane tilt and plane azimuth of your tracker, at a given time. I don's see in which way they are erratic: these are calculated from the tracker's position (phi angle, axis tilt and azimuth, depending on the tracking mode) and are quite real angles.

I really don't understand how you got this result. The Sandia model is hard-coded in PVsyst, the values are unmodifiable and give a result very close to the normal Fresnel's model. This curve is probably a user-defined IAM profile, specified in your PV module, with completely erroneous parameters. Sandia model and Fresnel, normal glass and with AR-coating

This is indeed the extra-terrestial irradiance, i.e the irradiance outside of the atmosphere. This is equal to the solar constant (1367 W/m2), which is indeed not a constant, but a yearly average. The extraterrestrial irradiance varies by about +/-3% around this value due to the earth's trajectory ellipticity. This "normal" extraterrestrial irradiance has to be multiplied by the sin(HSol) for representing the Horizontal global. The extraterrestrial value is used for the evaluation of the clearness index Kt, involved in the Transposition and Diffuse models.

The difference is 0.004% (equivalent to 4 cents on a sum of 1'000 euros). This may be a rounding effect, or an edge value in the shading's calculations. Such differences may arise in simulations. We could pass some hours (or dozens of hours) for understanding such "problems", but we have more urgent priorities.

This is very strange indeed. With which version of PVsyst ? Please check that you have defined a reasonable value in the Project's settings parameter: in the project's dialog, button "Project settings", page "Other limitations", item "Discriminating orientation difference between shading planes". The default value is 1°. If this is OK, please send your whole project (using "Files > Export project" in the main menu), to support@pvsyst.com.

This is indeed not possible. PVsyst requires to ask for creating an hourly file explicitly before simulation, for avoiding filling your disk with a lot of dummy files. Now if you have several runs with different parameters for optimizations, you are advised to use the Batch mode. Here you can choose getting the hourly CSV file for each simulation. Your list of parameters is kept with your Variant file, and eventually for the next file you will create/open. You can also save it as a template, for reusing it in any other project.

No, it is not possible. In the present time the bi-facial model is only useable with horizontal trackers. An extended model will not be available in PVsyst before several months.

Yes of course. This is a question of averaging mode. The basic hourly values are TArray. In the "TArray" variable: we average these values over the operating periods, we get an average module temperature which has not a big meaning. In the "TArrWtd" variable, we calculate an average weighted by the GlobInc value. This averaging mode is much more significant, it is required for the evaluation of a weather-correctd PR. Therefore for these variables, only the daily or monthly averaged values are different.

It is sometimes useful to read the Help ... See "Project design > Bifacial Systems > Bifacial systems procedure"

No, when you are using a module with bifacial capability, it is not necessary to define a bifacial simulation. It is always possible to do a simple standard simulation: in the bifacial tool, choose "Don't use in the simulation".

No, you should evaluate this by yourself. The soiling loss parameter is already extremely poorly defined (and not stable in time). Elaborating sophisticated corrections on such values doesn't make much sense.

I don't know such an error, I really doubt that this can still exist in the version 6.74. Please check that your inverter is not defined with a nominal power increase up to PMax, according to the temperature (page "Output parameters").

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.