Bruno Wittmer

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.

The screen shot from the module layout window does not correspond to the situation on the first screen shot of the 3D editor. You have to set the date and time to the same hour in order to get the corresponding calculations. Please check for which timestamp exactly you get the conditions of the first image, and then set the date and time accordingly in the module layout window. The results in the screen shot of the module layout window seen consistent. The two strings are clearly on separate MPPT inputs, and both strings are partially shaded.

This level of detail is not yet covered in PVsyst. There is only one albedo value to describe the ground properties. Furthermore, the current bifacial view factor models are based on a cross section of the table rows, and don't allow to describe changes of properties along the row. In future PVsyst versions there will be a bifacial model based on the 3D drawing, which might allow the introduction of such varying ground properties. As of the date of this post, there is no timeline yet for when this will be available.

The calculation of the maximum expected voltage at the inverter input is a safety issue, meaning that a single event might already cause damage to the equipment. Therefore, it is necessary to check the worst case scenario for the question:'For my PV system, which is the lowest possible cell temperature with some significant amount of irradiance at the same time?' As your plot nicely shows, the Voc curve is quite flat from 300 W/m2 onward, meaning that already rather low irradiance brings you close to the maximal voltages. If you think of the worst case scenario, there are two points that are not taken into consideration in your argument: It is not advisable to look for the worst case in the meteo data of a typical year, since it is quite likely that the worst case happens rather in an exceptional year. If you would like to take the worst case from measured data instead, you should probably look at decades of measurements, in order to be sure to find a situation coming close to the worst possible case. In any case, I think it is better to just estimate the worst possible conditions, and work with generous safety margins. The worst case scenario is not a stationary situation, where the PV modules are in thermal equilibrium with the surroundings. I think the worst case is on a cold day, when the PV modules are roughly at ambient temperature, because there are many clouds and very little irradiance. If then the clouds open quickly enough, such that the PV modules do not have time to heat up, you will get the highest possible values for the PV module voltages. Please note also, that the calculation uses Voc, which is higher than the normal operating voltage Vmpp. Also here, the idea is to consider the worst case, and not a standard situation. As you can see, the reasoning here is to completely exclude the possibility of the voltages at the inverter input exceeding the safety threshold. For this purpose, we consider it to be reasonable to constrain the lowest possible cell temperature to values of 30°C or lower. If however you think this is too limiting for your simulation, you can still increase the maximum voltages in the OND and PAN files, but be aware that you are working very close to real safety limitations.

If you choose "account as separate loss" for the grid limitation clipping, the simulation itself will not change. Apart from some possible small rounding errors, you should get exactly the same results for the generated energy. The only difference is that the inverter power clipping losses, which were found in the simulation variable IL_Pmax, are now split in two variables: IL_Pmax and EGrdLim. IL_Pmax is the amount of clipping due to the power limitation of the inverter, while EGrdLim is the additional clipping imposed by the grid injection power limitation.

This is a matter of definition. 'Direct Use' in this context just means that the energy did not go through the battery. You can compute the energy that went directly from solar to self-consumption by subtracting E_Grid from this value.