Robin Vincent

I guess, based on your scene the trees are not the major contributors to the shadings. It could be that all your rows don't have the same height, which is not taken into account in the backtracking algorithm. It could also be a bug. At the very least you should try it with the latest PVsyst version to see if you get your expected outcome or is the shadings are still looking similar. But again for this kind of questions you should contact PVsyst support instead of using the forum. There is only so much we can say based on a few screenshots.

Dear User, It is kind of hard to analyse why your scenes yield different shading tables based on screenshots. For questions specific to your projects, please contact PVsyst support directly with your project : support@pvsyst.com. Regarding your first question, the iso-shadings diagrams are not identical (clearly visible on the "40%" line at the bottom which is higher on the left graph). That seems consistent with the shadings losses being higher on the left too. I won't be able to answer the second question without the actual project. Have you tried it with PVsyst 8? For the 3rd question, if the backtracking is enabled it might be possible you don't have mutual shadings at all.

There are two main differences between ReflFrt and AlbInc. AlbInc uses the albedo value defined in the project setting, while ReflFrt uses the albedo defined in the bifacial model. The far albedo is only seen by the 1st row, while ReflFrt is computed for all tables. The computation itself is also slightly different (integral of visible sky portion vs integral of the reflection on several ground points) but this should have a extremely small impact on the final results.

The unavailability period represents the time during which your system won't produce any energy. So yes, if your inverters are in average unavailable 2.5% of the time, you can set it as the unavailability time fraction for your system.

For Huawei optimizers, we are strictly applying the rules requested by Huawei. In this case, they requested between 9 and 12 strings per inverter for the sun5000 series. Please contact Huawei directly if you think a modification to this rule is necessary.

We cannot answer for sure on the sole base of those diagrams. Please send us your project (in 7.4.7) at support@pvsyst.com so we can understand why you have such a difference.

After some archeology, here's a more complete answer : If you were using Unlimited sheds or unlimited trackers, the fraction of unshaded and shaded rear side was correct If you were using trackers on the 3D scene, the fraction of unshaded and shaded rear side was also correct (using the total number of sheds at least). If you were using fixed tilt on the 3D scene, then fraction of shaded rear side was always 2/3, and in that case your analysis is correct. This behavior has been fixed in the 8.0, and improved in the 8.0.6 when you have multiple columns of sheds. In the 8.0.6, you will be able to see and change the number of rows used for the bifacial calculation from the bifacial tool, which should let you try to reproduce the previous behavior if you want to isolate this specific change.

PVsyst V8 development was focused on improving the "orientations" management. This includes several modification that could impact the system you described. I cannot give you an exact list, since I don't know your exact project, but I think this one is very likely to generate changes in your results :

Regarding the bifacial contribution, please see this post : For the azimuth, are you using averaged orientations and/or do you have a specific field topography ? Since most of the reduction seems to come from the bifacial diffuse irradiance contribution, you can try manually setting the number of sheds in the bifacial menu. Setting Number of sheds = 3 should give you a value similar to what you had in V7. I'd suggest not to do so, as the V7.4 results were unrealistically high while results with the V8 should be closer to the reality. But you should be at least be able to validate the reason behind this change.

Update: In the V7, most of the time the number of sheds used for the sky diffuse on the rear side was set to 3. It meant that 2/3 of the sheds were impacted by mutual shadings, regardless of your project. Starting with the v8.0.0, we now use data from the system for this computation, which in most case results in a reduction of the diffuse energy on the rear side (a greater percentage of the sheds are shaded). This value is likely to change again a little in the V8.0.6, as we fixed a minor issue.

As mentioned in the other thread, the only way to mix orientations within a string is to use the averaged orientation option. This also means the transposed irradiance will be the same for all your modules sharing this orientation, so it won't generate any mismatch. Other effects (notably shading) will use the real orientation. But in your case, it should not change anything : string mismatch should not occur with module level optimizers. You can still change that behavior in the detailed losses menu, Power Loss at MPP.

Hi, Please check this tread, as it could contain the answer to your question.

If I understand correctly, you need to mix different orientations in a same string. In that case, the only solution I can think off is to use the "average orientation" option, combining NE + E and SW + W. Based on your layout, the azimuts seem relatively close, so the resulting transposition error should be small. You may find more details here : https://www.pvsyst.com/help/project-design/orientations-in-v8/average-orientation.html?h=average This will allow you to define only two subarrays, each with strings long enough to be connected to a MPPT input. If you still have issues regarding your project, please contact us at support@pvsyst.com with your project attached.

You are correct, it is not possible to define a single subarray with mixed orientation and SolarEdge optimizers in PVsyst. Nevertheless, you can achieve a similar result by creating two separate sub-arrays, one for each orientation, then attribute the strings to the same inverter. To do so, open the "strings configuration" menu in the system definition, then set different sub-arrays to each input of your inverters

Actually, it is even trickier than that. For both values, changes are detected if any of the 1st 4 characters is changed. It usually means 1 digit for module quality (the "-" counts as a character) and 2 digits for the LID. Then, if the value is less than 0.1 point different from the default, it is set to the default value. The final value is then stored and, as you mentioned, only 1 digit is displayed. This is obviously not ideal, and we should harmonize the behaviors and make sur the number of digit displayed matches the number used. Nevertheless, such an accuracy (1/10000) is definitively not necessary in the 1st place.

This issue is due to a bug in the automatic string attribution to each MPPT (triggered when changing something in your system or when clicking on reinitialize inverter list). It should be solved in the 8.0.5. Meanwhile, to be able to simulate your system you can try deleting and adding back each inverter one by one until the error message disappear. Make sure your system is fully defined before doing so, as any modification on the subarrays definition will trigger a new string attribution,which could lead to the issue reappearance.

Yes this is planned for a future version of PVsyst (at least with optimizers), but I cannot give you any timeline for it.

No you cannot set heterogenous strings in PVsyst. The closest workaround would be to have subarrays with strings containing +1 and-1 modules relative to your odd-strings definition, and connect them to the same inverter. It won't be exactly equivalent, and only work if the total number of modules connected to the inverter is even. But at least the total DC power would be correct, and the impact on the different component efficiencies and threshold limited.

Sub-hourly simulation is a simulation with a time step lower than 1 hour. It may be useful to correctly account for non linear phenomenon such as clipping and curtailment. It is currently not directly available in PVsyst, even though workaround exist to run pseudo sub-hourly simulation https://www.pvsyst.com/wp-content/pdf-tutorials/pvsyst-tutorial-v8-pseudo-sub-hourly-simulation-en.pdf or to have a better clipping correction estimation https://www.pvsyst.com/help/physical-models-used/grid-inverter/subhourly-clipping-correction.html?h=clipping. In both case, sub-hourly weather data is necessary.

Please contact the support by email at support@pvsyst.com with your project (project => export project) so we can have a better understanding of what is happening.

The results export is restricted to the same time step as the simulation, which is set to 1 hour. Smaller time steps will be available once the sub-hourly simulation is.

No, the simulation itself is still hourly-based. We only extract additional info from sub-hourly weather data to correct the clipping losses.

With unlimited sheds, pretty much all the parameters you mentioned will impact the near shadings losses. You may be able to find more detailed information in the help page for diffuse losses with tracking systems : https://www.pvsyst.com/help/project-design/shadings/calculation-and-model/diffuse-losses-with-tracking-systems.html#tracker-diffuse-shading-definition-window-from-version-730

This issue must have been fixed by now, in PVsyst 8.0.2.

The backtracking strategy avoids direct mutual shadings, but not the other irradiance components. If you extract the simulation results with all the near shadings variables, you should be able to see that the Beam loss due to near shadings (ShdBLss) are equal to 0, but not the diffuse (ShdDLss) and albedo (ShdALss) components.