dtarin

Are you modeling it this way in PVsyst (in the shade scene), where 1/3 plant has 5.5m pitch and 2/3 has 4.9m pitch?

Are you comparing production data from two different plants? They should be commissioned with different backtracking parameters to account for the difference in pitch and shading. Have you compared the tracking angles reported from the trackers?

In previous forum replies on the subject, optimizers must come from the manufacturer and they need to coordinate with PVsyst to add to the software.

I believe it is done in order. Given the way the software calculates soiling loss, I dont think the difference is significant. Soiling takes an average monthly loss and applies it equally to each hour. In reality, soiling is more variable and non-uniform (both on module level and plant level). IAM loss also is more complex than how it is implemented in software, given as you said, the reflectivity of the light will be impacted by the material(s) present on the modules. Since the software is only accounting for the reflectivity of the glass and not accounting for reflectivity due to material on the modules, maybe that is why it takes IAM first and then takes soiling. You can output all of the variables and determine what the difference would be if you reversed the order using the global soiling and IAM ratios. In my test (SAT in MD), there is a negligible difference. In default order, total irradiance after soiling is 2001.016 W/m^2 (shading > IAM > soiling). Swapping IAM and soiling, total irradiance is 2001.017 W/m^2 (shading > soiling > IAM). Maybe for a fixed tilt system and depending on location, you could get a higher discrepancy, but mathematically, I don't think it is significant in most cases.

On an hourly basis, no. Shading losses vary hourly and seasonally. Soiling cannot mimic this. On a yearly basis, if you want to apply an additional n% loss, you can use a number of ways. Increasing soiling according to the season and doing a trial an error approach to achieve your target is one way. A higher additional loss in winter compared to summer would capture some of the seasonality.

It will depend on your weather file. If you are using a standard TMY file (CPR, SolarGIS, etc), it will be a P50 result.

Hello, It would be helpful under the backtracking management menu in the shading tools if the tilt was shown for each tracker, and off to the left, the average tilt for the entire system. It would save some steps by eliminating the need to export the data to excel to calculate the average, and then spend time trying to find a tracker that matches by clicking one at a time to see the tilt.

I had the same observation when 7.0 first released. https://forum.pvsyst.com/viewtopic.php?f=4&t=4936&hilit=import+project

Select Report > Tables > E_Grid hourly averages Select on the right: Values - Hourly averages

Only shows for beam component.

There is also an IAM loss accounted for in GlobBak.

Is the surface you are placing them on flat? Is there sufficient spacing between modules so they dont overlap? you can place them on a flat surface, then move them over and onto the roof.

Backtracking is based on sun height/angle for the site's location. It does not backtrack according to terrain conditions. Check your results with irradiance optimization checked under orientation menu to see if that helps.

It works in 7.2.6.

You can open multiple instances of PVsyst. I wouldnt work on the same variant you have running, but other variants and projects work just fine.

Manually calculate PR and include the rear-side irradiance with the front-side irradiance.

+1 Sub-hourly clipping is missing from PVsyst estimates, which can be non-trivial

Tilt 90 Azimuth -90 to face east, 90 to face west Collector bandwidth is length of module Not sure on rear side shading losses

I assume you are modeling them four in height? So 4x20, 4x10, 4x5? This is one misalignment between PVsyst and PV plant design; PVsyst doesnt have a way to model fixed tilt with terrain or as-built table sizes and proper partition sizing, leading to an underestimation of electrical shading losses. In your case, I would model as follows: 4x20 Table - 4 h x 1 w partition 4x10 Table - 2 h x 1 w partition 4x5 Table - 1 h x 1 w partition If half-cell module, 100% electrical effect; if full-cell, maybe less than 100% (when oriented landscape). PVsyst should really work on this shortcoming in the software, as it has been present for years. Allowing and calculating for fractional partitions could be a short term fix.

Hi Scott, I would recommend to first search the forum, as there are years of questions already answered that may be the same as yours. The PVsyst youtube account also has some basic, introductory content. https://www.youtube.com/c/PVsystTutos/videos

There is already a thread on this topic.

Create the zone and populate the modules in one direction, unclick the zone icon, select all of the modules, copy them, then paste next to the existing modules, press control + G to change their tilt/azimuth at same time to orient them to new direction. See Your table length/partition should be defined based on your string size as close as possible.

New versions are backwards compatible. It's the reverse that is not (old to new). Most manufacturers, third party labs, etc. will make sure their files are compatible with PVsyst.

The variable name in PVsyst is GlobBak and it is the rear irradiance after shading, before the bifaciality factor is applied. The shading loss on rear side has its own output variable.

Correct. You can use a weighted average of the N-S slopes to capture overall N-S slope, which may be a gain or loss.