André Mermoud

The ground object is a new tool, and we did not yet have time for developing all related features, like positioning trackers on it. This will be done for a next version. You can always define trackers at different altitudes. However with such a system the backtracking strategy is not well defined. PVsyst cannot calculate it.

Please have a look on the help : "Meteorological data > Hourly Meteorological data > Hourly meteo data quality check" and " ... > Time shift" The dates are normally read on the file (in a specified format - pay attention to the formatting: MM/DD/YY in the US, DD/MM/YY almost everywhere else). But if you have a TMY file (with diferent periods), you cannot read these dates and you have to choose "Generic year".

If you consider the thermal loss as your decision, and not the result of the simulation, you can of course put the parameter you want for getting this result.

Some SMA inverters have indeed a very large Power factor range. SMA claims that you can even specify Cos(Phi) = 0 (means that the inverter produces reactive energy during the night) but this doesn't make sense for the results of the diurnal simulation. This is the reason why we limited the Cos(Phi) to +/- 0.1. For the parameters in the PVsyst database, they have been specified by SMA people. Please ask them. However you are right: suppose you have a cos(Phi) of 0.1, the apparent power at Pnom = 25 kW (effective) would be 250 kVA, which means a quite irrealistic current ! The PNom limitation is usually corresponding to an output current limitattion, and should indeed be expressed in kVA.

In the Database management, you have a tool for exporting the data as EXCEL lines, for use in the document Components.XLS. Here you can export several components at a time. You will find this file in c:\Program files (x86)\PVsyst6.x.x\DataRO\PVsyst6_Data\UserData\ I don't know any other component database which would provide sufficient information (parameters) for use in PVsyst.

This is not possible directly as standard output of PVsyst. You can manage for getting the relevant values using the Monthly tables (you can get data for any chosen variable of PVsyst). But this will not give the Loss values in percent as on the array loss diagram: you have to calculate them in EXCEL.

Thank you for this information. I have corrected for the next version 6.39.

Sorry, this is not possible in PVsyst: you can only define different orientations for full strings. This is suited for "normal" strings, where current mismatch may be catastrophic. Although such a configuration could be used with the SolarEdge optimizers, it is not implemented in PVsyst in the present time.

The values of the parameters (Rserie and Rshunt) in the database have been set by Sunpower people. Now the SPR-X21-345 module has a very low Rserie = 0.39 ohm, leading to bad low-light performances (relative efficiency -1.1% at 600 W/m2, and -5.4% at 200 W/m2). When the SPR-E20-327 has a higher Rserie = 0.54 ohm, leading to better low-light performances (relative efficiency -0.3% at 600 W/m2, and -3.1% at 200 W/m2). Therefore it is quite normal that the Irradiance losses of the X21 module are higher than the E20 module. By the way, we can observe that these low-light performances (as stated by Sunpower for the PVsyst database) are much lower than the performances of all equivalent modern modules. The new standard of PVsyst for the default value of Rserie is to set -3% at 200 W/m2, and this is a cautious estimation. NB: The temperature coefficient stated for the X21 (-0.30%/°C) is significantly lower than for the E20 (-0.38%/°C). This compensates a part of the Irradiance loss effect.

This depends of course on the geometrical positioning of your installation. You don't tell anything about this.

I don't understand your statement. You don't mention that the irradiance level changes. For the "Mixed orientation" calculation, the I/V curves of both orientations are mixed at each simulation step, and the resultant is used for the Pmpp determination. Mixing strings of different orientations usually doesn't produce much mismatch losses.

Sorry, the Batch mode only concerns simulations, it is not developed for the import of meteo files from other sources.

I don't understand the question. The option "Import ASCII Meteo file" is a button in the "Database" part. You can open it and press F1 for getting the procedure.

According to the PVsyst conventions, in the Northern hemisphere the azimuth is referenced with respect to the south. Therefore at latitude 3.5°N, in winter midday, the sun is situated at Azimuth = 0° (i.e. south). See the FAQ How is defined the plane orientation?

The PR doesn't depend on the STC efficiency of the modules in any way, as it is related to the nominal power PNom. See our FAQ How is calculated the PR? However it may be affected by the low-light relative efficiency, which depends on the parameters chosen for the PV module (namely the Rserie, see the FAQ How should the Rserie be specified?).

Sorry, this was a bug in PVsyst, arising in special conditions (I don't remember which ones), and in one only version (I don't remember which one, probably 6.35). This has been corrected in the next versions. NB: If this behavior persist after updating to a later version, please send your whole project (using "Files > Export projects"), to support@pvsyst.com.

Please send your CSV original data file, along with the Site file (*.SIT) and your ".MEF file, to support@pvsyst.com, for analyzing this problem. You can indeed run a simulation for any time interval (from one day to one year). The simulation is based on the Meteo file (*.MET). The site defined within the project should hold full and valid monthly values for some calculations and presizing tools, but it is not involved in the simulation in any way.

This is a problem of CSV management in EXCEL documents, not PVsyst. Please try to use other suited techniques for establishing your Batch command file. For example: you can try to create your strings "Sim_xx" in another column, and use the function "=" for copying them in the suited column. Or simply you type Sim_1, and then "drag" this into the other cells: the number will increment autmnatically. Or others... this is from your own experience with EXCEL !

Yes it is possible. In the EXCEL document, be sure to specify a filename for each hourly file (with extension .CSV)

When defining the batch mode, you are prompted for defining the variables to be put in your output file. And in the batch definition (EXCEL) you have to define the name of the CSV file to be created.

Very strange. This importing tool with formatting works quite well. How are your data interpreted in the preview when defining the format ? In your definitions, is the comma defined as the separator ? Please send your source data and *.MEF formatting file to support@pvsyst.com

On the I/O diagram, I can't read the variable you have put as y-axis. If it is the EArrMPP, it is not affected by the behavior of the system (i.e. the full battery). However according to the loss diagram, the behavior of you system seems very strange. Please send your whole project (using "Files > Export project") to support@pvsyst.com

The relevant time is the time for the calculation of the solar geometry (should be in the middle of the accumulation interval). Yes indeed, this will have an impact on the diffuse evaluation, and much more on the transposition model.

PVsyst works with hourly meteo data. If there is fog, this will be included in these input data.

I don't know this error. Please send your project to support@pvsyst.com.