Linda Thoren

Indeed, the bifacial calculation in PVsyst is based on a 2 dimensional representation for regular system layout, thus same orientation, table size and pitch, to calculate how much irradiance is falling between the tables and how much will be scattered up on the back side. You can define individual orientations for each table. Though, since you need a pitch it is not yet possible to simulate a bifacial system with a single row. A possible workaround is therefor to duplicate your 3D scene so that PVsyst can detect a pitch, similar to the example below: Verify that the tables are well aligned so that indeed PVsyst detects the pitch in bifacial window. Note that the amount of tables in the 3D scene will be double what you have defined in the system and this will create a warning. You can increase this limit in the advanced parameters. In the first PVsyst welcome window, click “Settings” and “Edit advanced Parameters” and find the parameter that triggers the error message – “Shadings: absolute maximum shading/field area ratio”. This will allow you to run the simulation Kind regards

With PVsyst version 7, it was an automatic mode for diffuse shading calculations for systems that involve trackers, in version 8 the automatic mode has been removed. Now, users are required to manually define a representative tracker for diffuse shading calculations. You define a representative tracker by clicking “Tools”, “Trackers diffuse shading definition”. In this tool you can choose to calculate the diffuse shading factor for all trackers, or select a representative tracker that will be used to evaluate the diffuse shading factors You can find more details about this update and instructions in the PVsyst Help documentation here: PVsyst Diffuse Losses with Tracking Systems. Indeed, many updates and improvements has been done since version 7.2.16 that especially concerning the near shadings. In general you can find the changes that has been done in the release notes and major changes are discussed in the forum in the links below: https://www.pvsyst.com/help/release-notes/index.html#exec-1--version-801 https://forum.pvsyst.com/forum/29-pvsyst-main-changes/

Hello, This limit that the error message is referring to is in the Project setting, not the advanced parameters. Kind regards

Please verify the Trackers diffuse shading definition in the Tools tab. If you are not using the All trackers option, verify that a representative set of trackers have been chosen.

Hello, In PVsyst version 8 you do not have any limitations of how many orientations you can define. Please update to the newest version. Kind regards

The backtracking is a strategy to avoid mutual shadings. Thus, in the morning and evening when the sun is low, as in your example, the trackers will avoid mutual shadings by tracking "backwards" . If you do not want to have this behavior, deselect the backtracking option.

Please update to the newest version If you must stay at version 7, you can mark all the tables and move the selection using the arrow, or define the height in the tools section:

Indeed, the loss fraction is set for STC (standard test conditions) and the simulation will be done in real conditions that will vary between sites.

Hello, I did a similar test in version 8.0.18 and is seems to work as it should on my side. The zone to the left is places 0.5m above the ground the the zone to the right 5m above the ground. If the issue persist, please describe further how to reproduce it. Kind regards,

Hello, The two locations to define the partitions are equivalent. If you change one, the other will update. The example below is from the DEMO tracking system Annecy with strings of 20 modules in 2P The partition model is intended to represent the stringing configuration. Therefore, if a table contains one string (e.g., 26 modules), you should define a single rectangle in length (Y-direction), since all modules are electrically connected as one string. If a table contains multiple strings, a separate rectangle should be defined for each string. For example, if a table has 52 modules—corresponding to two strings—you should define two rectangles in length.

Yes the number of sheds will have an impact of the performance, considering that the first and the last rows are not accounted for in the same way, since they will not experience the same shading patterns as the tables in the middle of the system. When there are many rows, this difference may be neglected. You can read more about the impact in the following help page: https://www.pvsyst.com/help/project-design/bifacial-systems/bifacial-systems-nbofsheds.html?h=number

Hello, In version 8 you can create multiple field types in the orientations window and assign different bifacial parameters to different sub-systems. Thus, even if the tilt and azimuth are identical, create 2 orientations and assign each orientation to a sub-array in the system window, corresponding to the two sub-systems with different pitch in the 3D scene. You find a similar example in the DEMO tracking system Annecy, variant VC5: 2 fields of Trackers with different pitch Kind regards

Hi, Indeed the custom import process can be a bit tricky. In the upcoming release of version 8.1, we will introduce a new assistant to help guide users more easily through the construction of the .MEF file. When importing sub-hourly data, please ensure that the time step is correctly set to 1 minute rather than the default 60 minutes. The warning message you received indicates that the imported irradiance values are very low compared to the site’s clear-sky model. Is the site correctly defined? If you are importing measured data, it may also be worth checking whether the solarimeter requires calibration or whether the units have been properly specified. Feel free to send us your site and CSV file at support@pvsyst.com so we can take a closer look. Kind regards,

Hello, In the current version you cannot do these manipulations directly in the single line diagram. In the following youtube tutorial you find more information about the single line diagram and the DC and AC cables : The losses in the DC and AC cables can be defined in the detailed losses window as discussed in the following forum posts:

If you have multiple sub-arrays, you can define individual parameters for each sub-array by using the drop down list in the top of the window

For certain scenarios it is not yet implemented, such as for multi orientation daily sharing. In the case in your print screen it is probably because you do not have a multiple between the number of strings and MPPTs in the second sub-array. You should have an orange warning in that sub-array indicating this. You should here create an additional sub-array for the strings of 19 modules, one sub-array with 2 strings and 1 MPPT and a second with 1 string and 1 MPPT. This is further explained in the following youtube video:

Hello, This can be done in the detailed losses window, Ohmic losses tab.

Hello, You can import Measured global on plane (GlPMeas) via the "custom file" tool. You then need to define the Orientation definition and here you can define a tracker. PVsyst will reverse engineer (we use the term reverse-transpose) the GHI and DHI. In the end the discrepancy between the original value and the one in the simulation will differ for a given hour of less than a percent. Over the year the difference should be negligible. You should use the Hay transposition for more robust results with the retro-transposition. This is further explained in the following PVsyst help: https://www.pvsyst.com/help/glossary/solar-geometry/plane-orientation.html

Unfortunately, it’s not possible to import a PVsyst project created in version 8.0.4 into version 7.4.8. PVsyst files are only compatible from lower to higher versions, not the other way around. To open the project, you would need to use PVsyst version 8

Hello, In the current version, PVsyst simulation is hourly based. Thus any sub-hourly phenomenon has to be averaged. Sub-hourly simulation should be available in PVsyst 8.1, but the release date is not yet defined (Normally in the beginning of 2026). Nonetheless, we included a sub-hourly clipping correction in PVsyst 8.0, allowing the simulation to consider sub-hourly irradiance fluctuation for clipping. You can refer to the dedicated section in our help page for more information. The last option is to use the so-called pseudo-subhourly simulation. The idea is to run n hourly simulations (in your case n = 60min/30min -> 2 ) then recombine the results. You can find a PDF tutorial about the whole process in our website: Pseudo sub-hourly Simulation Kind regards

Hello, Indeed the PVsyst simulation is hourly based, so any sub-hourly phenomenon has to be averaged. This includes the weather data or self-consumption. The main reason for this limitation is that we currently consider that Perez’s transposition model is not well calibrated for sub-hourly data (EUPVSEC 2023). Sub-hourly simulation should be available in PVSyst 8.1, but the release date is not yet defined (it will be after 2025). Nonetheless, we included a sub-hourly clipping correction in PVsyst 8.0, allowing the simulation to consider sub-hourly irradiance fluctuation for clipping (EUPVSEC 2024) You can refer to the dedicated section in our help page for more information. The last option is to use the so-called pseudo-subhourly simulation. The idea is to run n hourly simulations (in your case n = 60min/15min -> 4 ) then recombine the results. You can find a PDF tutorial about the whole process in our website: pseudo sub-hourly simulation This process can even be automated if you have a PVsyst CLI licence. You can find an application of pseudo-subhourly simulation using PVsyst CLI in python in the help Please note that pseudo sub-hourly simulation cannot be used with energy storage systems. Best regards,

Hello, The available area in the Pre-sizing help in the System window, serves as a guide for a first order of magnitude of how many panels you can fit on a dedicated surface. This tool take only the size of the panels into consideration (not the spacing between the panels or a pitch). If no 3D scene is defined, no configuration other than what is defined in the system and orientation window is considered (no shadings). Defining a 3D scene with the surrounding shading elements, include electrical shading definition etc. will more accurately simulate the system. You find a tutorial for the 3D tool in the following link: Another potential important parameter for a vertical system would be the reflection on the ground. For a monofacial system, this is discussed in the following forum page:

Hi, Indeed the maximum number of rectangles is limited to 100. However, in most cases—even for large-scale projects—each table typically contains only a few strings, so this limitation normally is not issue. For example, if each table includes four twin half-cell panels arranged in portrait orientation, and each row of panels in the table corresponds to a single string, then the table would require eight rectangles in width (x-direction). Could you please clarify how the system layout is defined in your example? You can find more details about the partition model in the following help page https://www.pvsyst.com/help/project-design/shadings/electrical-shadings-module-strings/index.html?h=partition

Hello, If all the strings have the same length you can indeed use the Power sharing within the inverter. The two options should give the same result.

Hi, Changing these values in the project settings will not affect the simulation results — it will only have an impact in the triggering of the error message. The error message is designed to protect the inverter from potential damage when the absolute maximum input voltage is exceeded. In this situation, there is a real risk of damaging the inverter.