Robin Vincent

Optimizers Release note : Optimizer efficiency is now applied after module related losses The operating point at the optimizers input was previously computed before some losses that were purely module related. With this correction, all the usual array losses (except for the ohmic losses) are now applied before the optimizer. It may slightly change the input voltage, current and power, leading to a different optimizer efficiency and/or clipping losses. It will also be visible on the loss diagram, with the optimizer related losses now applied just before the ohmic losses. Release note : Optimizer: Power clipping is now better handled. When the optimizer(s) operating point at MPP is outside its nominal current or power, it must be shifted along the input IV curve. Before PVsyst 8.0.15, this shift was simplistic. For an overpower situation, the new power was set to nominal optimizer power, the voltage stayed the same and the current was reduced accordingly. A similar method was used for an overcurrent situation. For small overpower or overcurrent, the operating point shift is small enough that most collateral effect can be neglected. But for larger values, it may lead to unrealistic operating points at module and inverter level. The new algorithm is now similar to what is done with inverters. When clipping occurs, a new module operating point is selected on the IV curve, and the subsequent losses are recomputed. The consequences for most systems should remain small, but it will impact most projects using optimizers. Release note : Optimizers, SolarEdge: it is now possible to define subarrays with heterogeneous strings. When designing a subarray with SolarEdge optimizers, it is possible to have a string of optimizers in which all but one of them are connected to 2 modules. This so-called "heterogeneous string" is now possible to model in PVsyst. In a subarray with SolarEdge optimizers, if there are exactly two modules in series at the optimizer input, a checkbox will appear: When checked, the last optimizer of the string will be set with only one module, while all the other ones will have 2. In this example, one can see that there are 6 optimizers in series, for a total of 11 modules per string. Storage Release note : Grid storage: revision of battery operation calculations The battery control strategy has been reworked, leading to a more accurate implementation of the deratings at low and high SOC. This update may impact projects using a battery that often reaches its min or maximal SOC. Shadings Release note : 3D scene: small width changes in PV table dimensions (<3cm) now modify the total sensitive width/height The PV table dimensions (PV module + inter-module spacing + inactive band) were saved individually in the 3D scene, however small changes in the different components (below 3cm) did not trigger the computation of the total combined width or length. When opening old projects affected by this bug, the total "sensitive" width/length of PV tables will be recomputed. This can have a small impact on the shading computation. Release note : Trackers, diffuse shadings: "central tracker" and "custom tracker" modes now offer the choice of including shading objects in the calculation For trackers, diffuse shadings can be sped up by computing shadings only on a single (representative) tracker. The options "central tracker" and "custom tracker", which implement this choice, can be selected in the 3D scene > Tools > Trackers diffuse shadings definition window. In these two cases, shading masks (i.e., objects that cast shadows on the representative tracker) are selected by PVsyst. Up to version 8.0.14, only neighbouring trackers with the same orientation could act as shading masks. From version 8.0.15, by default, shading objects in the scene are also used as shading masks. A checkbox permits the exclusion of shading objects, effectively reverting to how 8.0.14 functioned. This choice is written in the simulation report. More information on this feature will be available on the help page https://www.pvsyst.com/help/project-design/shadings/calculation-and-model/diffuse-losses-with-tracking-systems.html

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 :