Bruno Wittmer

Hi Ravi, Up to PVsyst V7.3.1 one could only specify the total cell area. In V7.3.2 it became possible to introduce cell width and height. Together with this, there is a mechanism that automatically determines part of the dimensions, based on standard PV cell sizes. This only works for standard crystalline silicon cells, and gives these error messages if you use cell sizes that are not very common, like yours. We will fix this for PVsyst V7.3.3, where it will be possible to freely choose the cell dimensions.

It is the first case in the question of the user that is correct. You import each of the 60 sets of minute-level data as if it were hourly data. You therefore need to use the correct time shift, and since the data will be interpreted as hourly values, you need to specify a multiplier in the conversion format if the data is in energy units. PVsyst will run the simulation as a normal hourly-steps simulation, therefore you need to do a renormalization of the energy variables in the results to get the equivalent of a minute-level simulation. Please note, that this approach does not take into account the thermal inertia of the PV modules. This leads to overestimated temperature fluctuations in the PV modules. In the PVsyst study this was handled by fixing the module temperature for each full hour to a value obtained with a simulation on aggregated hourly weather data, as explained in the paper.

At the WCPEC8 conference of 2022 in Milan, Italy, PVsyst presented a study on sub-hourly clipping effects.: "A model correcting the effect of sub-hourly irradiance fluctuations on overload clipping losses in hourly simulations", 2022, André Mermoud, Bruno Wittmer, Michele Oliosi, Agnès Bridel, Adrien Villoz. In this study, in order to estimate the clipping on a minute-level, a method was used, where minute-level weather data was split into 60 sets, one for each minute in the hour. Each set was then simulated in hourly steps, and the results of the 60 simulations were aggregated to obtain the equivalent of a minute-level simulation. Concerning this procedure, which is also described in the paper, the following question was asked by a PVsyst user:

There are two ways to achieve this: You can do this by changing the number of inverters or MPPT inputs in the 'System' tab. You can change the inverter in the 'System' tab to one with different capacity. You need to supply the filename of the inverter that you can easily find if you open the inverter in the database. If you would like to explore extreme DC/AC ratios, you might consider to increase the maximal tolerated overload losses in 'Project settings' before running the batch, else you risk to get some empty lines in the batch results.

The inverter nominal and maximal power are defined in the OND files. There is also a parameter called 'Power threshold' which defines from which power on the inverter starts converting DC to AC power.

We have added your request to our ticket system.

In PVsyst, right now the load profile is considered to be entirely active power. All reactive power generated by the inverters, which work at a constant power factor in PVsyst, will go to the grid. This is why in systems with self-consumption and/or storage the power factor at the injection point is not constant but varying in every simulation step.

This is most likely an interference between PVsyst settings, Excel/Windows settings and the variant name: For the output file of PVsyst you can select the column separator, which by default is a semicolon. In Excel and Windows you can define the default list separator, which often is a comma. If both separators are the same, double-clicking on the CSV file will open that file in Excel, and detect properly the columns. If the separators are different, you need to do the 'Text to columns' conversion as explained in the original post. If the variant (or project) name contains once ore more times the separator that is recognized by Excel, you will get additional columns when opening the file, with the subsequent warning message. The solution therefore is either to have the same list separators in PVsyst and Execel/Windows, or to avoid having the Excel/Windows separator character in the variant (and/or projec)t name.

Concerning 1: Relative humidity and the precipitable water column, are variables that are only used in PVsyst when the FirstSolar spectral correction model is activated. If this is the case, they will be available as output variables: Concerning 2: I am not sure if I really understood the suggestion. If you double-click on an extruded polygon, either in the drawing or in the object list, you can edit the height:

The source of the problem has been identified. We did not handle correctly all cases when you add or remove sub-arrays to a system that is already configured for power sharing. As a consequence, it is possible to end up with some of the sub-arrays that are included in the power sharing configurations, but which are not flagged as using power sharing. The power sharing configurations of these sub-arrays will be reset when starting the simulation. As a workaround, you can uncheck and check again the box at the top of the power sharing configuration: This will force all flags in the sub-arrays to their correct state, and the problem will be gone. We will secure the code such that these inconsistent states cannot happen any more.

To export the project, please go to 'Files-> Export projects' in the main window. Select the project and click on 'Export'. This will create a single file with .zip extension, that you can e-mail to us.

This looks indeed strange. The definitions are all correct, but it seems that the information was not propagated to the variant. I have not seen this before, would it be possible to export this project and send it to support@pvsyst.com, so that we can check why this is happening?

This message means does not mean that the inverter doesn't work. But it tells you that the string voltage is very low, and that you risk to hit the current limit of the MPPT input when approaching the nominal AC power. See also the help under 'Physical models used > Grid inverter >Inverter Operating Limits': https://www.pvsyst.com/help/inverter_operating_limits.htm

The inverter losses are explained in the help under the topic 'Physical models used > Grid inverter > Inverter Operating Limits'. There is no exact formula for these losses. The inverters are modeled as explained in the mentioned page, and the arising losses are added up throughout the simulation. The most common loss, apart from the efficiency, is the 'Inverter Loss over nominal inv. power', which corresponds to clipping for overpower. The other losses are normally zero or close to zero. Non-zero values would be an indication of a non-optimal design.

We will fix this in one of the next releases. Thank you for reporting this issue. You can also submit this kind of problems to support@pvsyst.com since this concerns only a small bug fix and does not impact the results of the simulation. The forum is useful for questions that either profit of some discussion and/or help PVsyst users to better understand and handle the program.

This value is indeed calculated for STC, which are meant to be close to plain sun exposure, therefore the wording. This is arbitrary, and one could use the maximum power for the clear sky calculation as well. This figure is there to give a quick feedback on whether the battery size is within a reasonable range. One should not draw precise conclusions from this value, but rather from the simulation results. Please note also, that this is the nominal DC power of the PV modules, so it is the value shown in 'PV array Pnom'. In the simulation the charging power is also limited by the inverter nominal power and the maximum charging power given in the tab 'Self-consumption'. This can potentially lead to much higher charging times.

This parameter is a threshold for the RMS value of the pitch distribution that PVsyst finds in the 3D drawing. The bifacial models in PVsyst are an approximation that is valid for identical long rows with constant pitch (spacing). If the simulation uses a 3D drawing of the PV system, then PVsyst will check if this drawing comes close to this idealization. For this purpose, it will calculate the RMS of the pitch distribution, and if it finds a value larger than the threshold, it will issue an error message, and the simulation will not be possible. The default value of 0.1 m is not based on a specific study. The error message is meant to remind the user that the system which is being simulated, is not fully compatible with the idealized assumptions, and therefore an additional uncertainty of the bifacial contribution in the simulation results is to be expected. So far there is no study that quantifies the increase of uncertainty in the simulation results as a function of the RMS of the pitch distribution. It will become possible to address this, once we have a more sophisticated bifacial model, which will be based on the 3D drawing. This is in work and will still require several months of development.

If you have many DC/AC ratios you would like to simulate, you can also use the 'batch mode', where you can change the number of strings and inverters to get different ratios. The batch mode allows you to run many simulations in one go, and it is described in the help pages in 'Project design > Simulation > Batch mode - Parametric studies'.

For ground mounted E-W structures, which are called 'domes' in PVsyst, you can currently only change the pitch in the 'Optimization Tool' (as well as in the batch mode). We will add the possibility to change also tilt and azimuth in one of the upcoming releases, a corresponding ticket has been added to our development pipeline. There is no precise timeline yet for when this feature will be available.

To allow PV modules with different orientations within the same string, would mean a profound modification in the way PVsyst models the PV arrays. Therefore it is unlikely that this will be implemented sometime soon. The situation might be different for the SolarEdge architecture. These systems are already handled in a special way by the simulation, and here it might be easier to add the complexity of multi-orientation strings. This is a topic that is being discussed within our team, but there is no timeline yet for an implementation.

EArray is the DC power at the inverter input, after the inverter has chosen its operating point on the IV-curve of the PV array. Therefore it will change if you change the Grid AC power limitation, since the inverter clipping will change. EArrayMPP is the maximum DC power before the inverter sets its operating point. This value should stay unchanged when you choose a different grid AC power limitation.

These tools to compare measured data need to be reviewed. We will fix these issues in one of the next releases. We are sorry for the inconvenience.

I am able to reproduce the issue, the tool is indeed not working as expected. We will have a look at it, and fix the error(s). We will also update the respective help page that explains how to use this tool.

I did not manage to reproduce the exact behavior described in the original post. However, I ran into a case where my batch parameter file was reset to one single simulation line. This happened when the file was not closed in Excel and 'Select existing file' was used. When exiting the batch dialog a message comes up saying that the file is blocked. If then the file is closed and I proceed, the parameter file gets overwritten by a file with a single simulation, like if it was created for the first time. We will review the code that handles the existing batch parameter files, and secure it against this type of data loss. Thank you for reporting the issue!

Dear Arnaud, Currently it is not possible to change the horizon with the batch mode. A request for adding this functionality exists already, but there is no timeline yet on when this will be implemented.