dtarin

LID loss is available as a batch variable and an output variable. You probably have not defined an LID loss in the variant you are running, and so PVsyst will not display the variable. Enter a non zero LID and save the variant. When you run your batch runs with desired LID values, it will override what you have saved in the variant and then will be available in the variable output.

These are shading loss factors, so 1-FShdBm = 0% beam loss. 1-FShdGl = 1-0.9846 = 1.54% global shading loss. The individual shading ratios are not as informative when we dont know the calculation steps PVsyst is taking, but the global shading ratio can be calculated, see screenshot. When there is backtracking and no shading objects or terrain consideration, the beam loss is zero, which is why it is showing a value of 1 for the ratio. So, a value of 1 = 0% loss, a value less than 1 means there is a shading loss contribution for that irradiance component. *There is not a horizon shading loss in this example, but if there were, then it would not be GlobInc in the denominator, but instead GlobHrz (global irradiance after horizon loss)

What this is telling us is that the shading losses are contributed by the diffuse and albedo components. If you refer to the link below , it states that the albedo component is affected by both the size of the plant and by the tilt, and effectively for large plants the albedo is near-zero. I suspect there is a mathematical operation on the albedo shading factor we see in the 8760 before computing the global shade factor. https://forum.pvsyst.com/viewtopic.php?f=30&t=2522

That is an outdated post. It has option to limit at the inverter or the point of interconnection.

Extruded polygons are not included in the object management menu in 7.2.9.

I do not know why parallel installations for subversions was removed, but when installing updates, there is not an option for it. There are bugs in every update, and replacing a current, working version for a bugged version is a waste of time if we need to go back to a previous install. We need to uninstall completely and then reinstall to go back to a previous version (see screenshot). We need to be able to evaluate two or more versions at once thoroughly, and it can take time. If there is some method I am not aware of, please let me know, but I just installed 7.2.9 from 7.2.6, and did not see an option. I downloaded the installer from the website and did not update through the app update screen when the software loads.

When trying to display different variables and factors in the 12x24 format, the results shown are incorrect. Referencing the screenshot below, my site has shading losses and the shading factors should not be equal to 1 for certain hours, yet in the table, it shows 1.00 for all hours. And similarly, it shows there are zero shading losses in W/m^2. Using PVsyst version 7.2.9.

Attached

Edit overload loss restrictions in hidden parameters and/or under project settings.

Set that in hidden parameters, see screenshot below.

From https://forum.pvsyst.com/viewtopic.php?f=30&t=2522,

Verify your IAM loss against a third party test report, and enter manually if necessary under detailed losses. PAN files can have any IAM profile entered into them before you receive it, which may or may not be based on a valid third party test.

You cannot view or model subhourly data. When PVsyst imports subhourly data, it is converted to hourly.

You do not need to use it, but it comes down to your installation and how you want to model. Using the MPPT feature will be dependent on your OND file definition, string size, module. If for example you have 1 inverter with 2 MPPT, you will need to enter "2" where it says Nb of MPPT inputs to equal 1 full inverter. What this does is it then takes the max PV current of the inverter and divides it by the number of MPPT inputs, and models each of these inputs separately from one another. Generally PVsyst prefers an equal number of strings per MPPT input, according to the max current per MPPT input ("balanced"). You will need to consider the current and voltage on each input to be within the inverter's spec to minimize clipping losses. In some cases, the results are the same with or without it if the system is balanced and within the inverter's spec. In other cases, if you have an odd number of strings or unequal strings across the MPPT inputs, you can end up with very high (and possibly unrealistic) clipping losses. For example, say you have 5 strings on 1 inverter with 4 MPPT inputs; you could end up with 10% clipping losses if you model with MPPT enabled. But if you disable this feature, and just model 5 strings on 1 inverter, you would end up with only 2.8% clipping losses. So which is correct? It comes down to your installation. For string inverters, you can have them installed so the MPPT inputs are independent of one another. In this case, you will use the enable MPPT feature. If your inputs are jumpered (connected together internally), they will share the incoming current from all strings, and you will disable MPPT feature. Another use for the MPPT feature is if you have different modules or string sizes connected to one inverter (1 string of 18 modules, 1 string of 17 modules, etc). Generally it is better to not have it enabled, and reflects actual PV plants as they're typically built. In all projects I have modeled that have gone to construction, string inverter inputs are jumpered and not operating independently.

Yes, I get the weird behavior as you are depending on how the trackers were created. If you are using zones to create trackers and then are sending them to custom groups OR just multi-selecting the tables and pressing ctrl+G, you will need to set orientation to landscape and include a Y spacing of .02m; PVsyst will assume this spacing by default, so if you select 0.01 for example, you will end up with 74 modules and 0.02m spacing. If you are importing through PVcase, you will not need to enter the orientation as landscape, and just need to adjust your Y number of modules (including again the 0.02m spacing to reach 75 modules exactly). Edit: 7.2.9 has updated the group management, should solve your issue.

Edit: I think the attenuation factor is something separate from the diffuse shading factor, which is "..independent of the sun's position, and therefore constant over the year...". From how the manual reads, the attenuation factor is something the software calculates when there are shading objects in the shade scene. So if you have trees or buildings (or basically a non-zero beam loss), you will get a non-zero attenuation factor. If you do not have objects, this factor remains zero. "The diffuse attenuation factor should be calculated, by integrating simultaneously the shading factor due to horizon, the near shadings factor according to the table, and the IAM attenuation factors over the visible part of the sky hemisphere. " - We dont know the integrals being performed, but perhaps if near shading (beam) is zero, the result is zero.

Diffuse light, partially or in total. Edit: probably coming from diffuse and albedo light https://forum.pvsyst.com/viewtopic.php?f=30&t=694 https://forum.pvsyst.com/viewtopic.php?f=30&t=2522

Indeed, I would agree as well.

Typically it's best to use the latest manufacturer OND file where possible, and as previously stated, check it against the datasheet. Although less common compared modules, a third-party verified OND file would be most preferable.

If you are using 4.9m pitch as the backtracking, I dont think there should be any shading losses. You will be underpredicting your irradiance gain for the 5.5m block, but you should at least not have any electrical effect losses. I am modeling in 7.2.6 and tested a site in North America to confirm. See attached. You can likely do the same check on your end to see if your results are the same. Set the backtracking pair for each block and run the shading analysis in the shade scene to check if there are any electrical losses.

That is the issue I think. Have you used backtracking management to set the tracker pair which determines the backtracking algorithm? You should model these two blocks separately so each has the appropriate backtracking algorithm, as they will be commissioned this way (or at least they should be). If you insist on modeling together, try using the 4.9m pitch block as the reference for the backtracking algorithm under backtracking management and see what your results are.

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.