Linda Thoren

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: