Linda Thoren

Hello, I suggest that you run a simulation with the bifacial parameters and export an hourly output file with all the relevant parameters, such as overload losses etc. This can not be done for individual strings but for the full system. Running several iterations should give you a good estimate of the losses.

Hello, The most straightforward way to evaluate bifacial gain is to run two simulations: one with bifacial parameters activated and one without. While the current itself does not differ between the front and rear sides, the rear side does contribute to the overall energy production. In PVsyst, the results are presented for the entire system and not broken down per string.

Hello, PVsyst is calculating the sun position based on the exact year accounting for leap years, when specific years are simulated. Thus, if you import a specific year that is a leap year though the 29th is missing in the data set, it will be considered as missing data and values will be 0 (similar to as if any other date of the year was missing). So values for February 29th will be zero (e.g., no irradiance), but the date will still be included in the simulation. March 1st will correctly follow as the next day.

Hello, You can read about how to adapt you PVsyst simulation to a floating system in the following post: https://forum.pvsyst.com/topic/1346-how-to-adapt-pvsyst-to-floating-pv-systems/

Hello Tyler, Essentially, the Global incident in the collector plane will be calculated for each sub-array for the assigned orientation (or possibly a mixed orientation). The GlobInc as the total result is an weighted average based on the Pnom PV

Hello, You can use the lasso selection (Ctrl+Shift+L) to mark all the tables that belongs to the concerned orientation and in the "List and management if objects" window (Ctrl+G) you can change the orientation of all the marked tables.

Hello, It seems to be linked to one of the new tolerances put in the new version that when the angle between your average orientation and at least one of your PV table is too high compared to the settings of your projects. To fix this error you need to increase this tolerance. From the main window of your project, click on "Project settings" at the top of the screen: Then you need to select the "Other limitations" tab and increase the value of the "Maximum orientation difference for defining average (spread) orientation" parameter: Once the value has been increased the error should disappear.

Hello, The clearness index will be evaluated and compared with the clear day model for the same time period. Thus having only a few months of data will not be an issue. If you compare the data for 2025 with data for 2024, are they similar or are indeed the values for 2025 much lower?

Hello, Indeed the workflow would be to precisely define the coordinates for where the site, define the MEF file and run the conversion of the data. If PVsyst suggest a time shift, go back to the MEF file and define the indicated time shift and run the conversion again. If the issue persists, please send your data to support@pvsyst.com and we can have a closer look.

Hello, This is possibly by creating two "orientations". Thus create one orientation for each pitch (even though they have the same orientation) and assign the bifacial parameters individually for each orientation.

Hi, you can export an Output File with any relevant parameters through the Advanced simulation window.

The multi-MPPT feature and how to configure different sub-arrays to precisely define your system is explained in the following youtube tutorial:

Hi, For hourly estimation of both the production and the specific losses, you can export an Output File with any relevant parameters through the Advanced simulation window. From the hourly/daily values generated, you can do any analysis in an external tool such as excel.

Hi, There is no specific tool to estimate the tracker tracking error. By conducting a P50-P90 evaluation you can possibly add an additional uncertainty to take into account such errors.

Hello, Per default there are no HV transformer or transmission losses included. You can define transformers in the detailed losses window, ohmic losses tab.

the idea is the same for the limitation of maximum current per MPPT. The graphics in the system window is an approximation, not considering the backside production, though the simulation will.

Hello, The values used in the system sizing serve only as a guideline and provide an order-of-magnitude estimate, considering only the initial front-side production (excluding for instance losses and rear-side generation). For an accurate assessment of overload losses, you should run a simulation.

Among the Generic inverter in the database, you can find examples of central inverters. Here you see that there are no MPPTs. By opening the .OND file, you find this information in the Additional parameters tab.

Indeed, the first row will not have any mutual shadings. For “unlimited” long tables, mutual shading can be applied uniformly across the entire row, allowing edge effects to be neglected. In the two images below, you can see an example, that for long tables, the impact of edge effects is limited to the lower-left corner and is therefore negligible. However, for shorter tables, this assumption becomes less valid.

Hello, In the database we unfortunately do not have a filter to sort out the central inverters from the string inverters. In PVsyst, the difference from a string inverter and a central inverter would be characterized by the fact that the central inverter do not have multiple MPPTs

Hello, PVsyst does not consider any loss due to tracking inaccuracy and there is no general “other losses” parameter, though you could possibly add such a loss as a “soiling loss” for instance. If wind velocity is available in the meteorological data, you can simulate wind stow behavior. You would define a wind speed threshold, and if the wind speed during a particular hour exceeds this threshold, the simulation would be done for the defined wind stow position for that hour. This would normally result in a less optimized tilt angle and thus less production, though it will not directly appear as a loss in the loss diagram.

In general, the denomination of a given time interval in PVsyst is always defined as the beginning of this interval. This is valid for hourly, daily or monthly values. For meteo data, the time stamp is the time interval over which the irradiance measurement (or any other value) is averaged. For example, the time stamp 11:00 corresponds to measurements averaged between 11:00 and 12:00. When using irradiance models, the solar geometry should be calculated for an "average" of the time interval. PVsyst uses the middle of this time interval (in the previous example 11:30). Different weather data providers have their own definition of the timestamp and thus will be adapted to match the one in PVsyst.

Hello, A floating system is rather similar to a conventional PV system. Following forum post describes how you can adapt your simulation to a floating PV system: To start a PVsyst project, we have several tutorials in PDF and on youtube: https://www.pvsyst.com/wp-content/pdf-tutorials/pvsyst-tutorial-v8-grid-connected-en.pdf

Hello, Yes, the zone tool will be improved in a future version. In the meantime, by defining a fixed tilted plane with the all the parameters you wish for your trackers (orientation, pitch, size etc.) and tick the option "Create tracking fields" (as you have done in image 4), the zone will be filled with trackers with the correct definition.

Hello Johann, The simulation and corresponding energy balance are calculated using hourly time steps. To determine how much of the generated solar energy can be self-consumed, the simulation must be run. For example, in the DEMO project “DEMO Commercial Installation at California” (VC3), the report shows: E_User: the total energy delivered to the user (reflecting the self-consumption profile), E_Solar: the portion of E_User that is covered by solar production, EFrGrid: the remaining energy that must be imported from the grid to meet the user's demand, E_Grid: any excess solar energy that is injected into the grid. These values are also illustrated in the annual loss diagram, giving a complete overview of the system’s performance over the year. Best regards