Robin Vincent

If you have only two types of modules in your system, you can still create two orientations. One to be used for all subarrays of the 1st type, the other for the 2nd type. These two orientations can have the same parameters, but it will allow you to setup your bifacial system with two module sizes.

The issue lies in the fact the bifacial model is linked to the subarray orientation, but the modules information are from the subarray. I guess from these messages that you may have two subarrays with different modules sharing the same orientation. One easy workaround would be to define two identical orientations, and set one to each of your subarrays. The main drawback of this solution is that your two subarrays won't cast shadows to each other on their rear sides (since the "unlimited" model used for the rear side is only considering mutual shadings).

To be able to change the number of rows in the batch, you need use the "unlimited model" or to have a fairly regular 3D scene. You'd also need to make sure your system design is compatible with the modified number of rows. If these points are correct on your side and you are still facing issues, please contact the PVsyst support (support@pvsyst.com) with your project.

The SolarEdge SE50KUS uses SolarEdge so-called "synergy technology". It basically makes the inverter behaves as 3 separate inverters. In PVsyst this feature has been modeled by having this inverter set as a 1/3 of the total system. It means that you should always have a multiple of 3 for the total number of SE50KUS inverters if you want to use the whole real system.

Regarding the direction, as Michele mentioned, the best way would be to find a dedicated glare tool. Alternatively, you could compute the direction yourself based on the sun position and the modules orientation. For the quantitative part, you could use the IAM values of your PVmodule, the incidence angle and the incident irradiance to estimate the reflected energy.

This post aims to present the main differences a user can encounter when using PVsyst 8.0.12 compared to PVsyst 8.0.11, including PVsystCLI. New functionalities for PVsyst CLI Three new parameters have been added to the run-simulation command: --batch-params-file (-bpf) --batch-rvt-file (-brf) --recompute-shadingfactors-tables (-rst) The two first will allow running a batch of simulations from CLI, thus enabling automatized parametric studies. An example use case has been added to the page https://www.pvsyst.com/help-cli/use-cases/simulation.html The third option allows choosing whether shading factor tables should be recomputed at the beginning of the simulation. More information on the commands and their usage can be found at https://www.pvsyst.com/help-cli/reference/index.html Correction impacting the modeling of optimizers Release note: Optimizers: Minor update of the optimizers MPP choice under partial shadings with module layout shading model When using the “module layout” shadings model, the MPP tracking algorithm now works better during partial shading conditions. In previous versions, it used to select an MPP at low voltage output, sometimes leading to inverter minimum voltage related losses. This correction may lead to a slight production increase, mostly from a reduction of inverter voltage threshold losses. Other minor corrections in the context of the modeling of optimizers concern Huawei optimizers : Correction of the efficiency computation, leading to a slight increase of the optimizer efficiency losses. With long strings (i.e., when the string voltage at STC is higher than the inverter MPP input maximum voltage), the individual optimizers' operating point selection now takes into account the minimum inverter input voltage. Under low-light conditions, this may improve the inverter efficiency by selecting a higher voltage operating point. Updated Bifacial PR The bifacial PR is now available in the report and in the monthly result tables. Its abbreviation is “PRBifi”. Note that the definition was also updated to now take into account the bifaciality factor. For more information, please check https://www.pvsyst.com/help/project-design/results/performance-ratio-pr.html

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.