André Mermoud

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.

Yes, in the simulation there is a threshold in the incident Irradiance, fixed at 10 W/m2, under which the system is not computed. Please observe that even by a very covered weather, we rarely observe less than 40-50 W/m2. Therefore this threshold is quite reasonable. However this loss should indeed be accounted in the GIncLss variable. It seems this is not the case, I will check in the simulation.

For the first question: this strategy of choosing one tracker in the middle of the array is indeed an approximation suited for "big" tracking arrays; it is used only for the evaluation of the shading factor applied to the diffuse component. The impact of other environmental objects is supposed to be not very significant for the diffuse (which is probably an acceptable assumption). But the calculation of the shading on the beam component takes indeed these objects into account. The backtracking calculation is dependent on the neighbour trackers. This algorithms of this calculation are difficult to establish, and only suited for well delimited conditions like regular tracker arrays. We didn't develop backtracking algorithms for neighbour trackers which are, for example, at different altitudes. This is the reason why PVsyst requires that all tracking arrays are identical and "regular". By the way, if we had different backtracking conditions for different parts of the system, the plane orientation would be different for each of these groups of trackers at a given time. We have not developed such a complexity in the simulation of tracking systems up to now.

In the present time, the "Stand-alone" part is very simplified. It is not possible to define sub-arrays, multi-orientations, and so on. I am completely rewriting this part of the program, which will include most of the new properties developed for the grid-connected systems since the last years. This new version should be available within some few months. However it is not possible yet to define a grid-connected system with storage. See our FAQ Can I include a battery in a Grid-Connected system?

This choice will be available in the next version 6.39, to be released soon.

In monthly values, you can simply redefine manually the values in the "Geographical sites" dialog, and then use the synthetic generation. On hourly values, this doesn't make sense. You cannot average hourly values of 2 different meteo sources; when averaging hourly data of a clear day with a covered day, you will obtain a sequence of "average" hours without meaning.

It is indeed possible to ask for the construction of CSV files of houly results in the batch mode. This will produce one file for each run.

There is no limitation on the energy loss of course. In the daily I/O diagram, the plateau we see in battery systems corresponds to full battery periods, i.e. when the battery is full at the end of the previous day: in this case only the required daily load during 24H may be produced/used by the array. Now in other circumstances, the battery may be empty at the beginning of the day. In these cases the solar array will yield the 24H load and also fill the battery, which corresponds to the points above.