Michele Oliosi

Could you send the shading scene at support@pvsyst.com ? We could take a look at it. Indeed, 7% electrical shadings seems like too much. I also don't understand why it's 99% shadings and not 100%. Also are you modeling with which version and which shading model (fast or slow)?

This is not simple, but let's see what we can do. First, mutual shadings tend to happen starting with 20°- 30° angles of sun height. These are the times when backtracking is interesting, but also where it seems you are expecting glare. So you have a double constraint on these low sun angles. Note that at times when backtracking is limited, you will have mutual shading. In these cases, it will be best to use just regular tracking. This is because backtracking is only convenient whenever you are removing most of the mutual shading (and electrical mismatch effects). So once you are in a mutual shading regime, I think it is probable that regular tracking will be best. Based on that, you can run two simulations: one with backtracking and one without. For each of them, you can generate an hourly output file. Then you can process the data, and use the regular tracking one whenever the backtracking rotation angle would be < 20°. The resulting dataset can then be summarized to obtain yearly yields, etc.

This error message was meant to be present in the previous versions of PVsyst but a bug prevented it from appearing. This has been fixed in the latest versions of PVsyst, that’s why you see the error message now. To get rid of the error message, you can go to the Home window > Settings > Edit advanced parameters, search for “spread” and modify the following value: I hope this helps. Note that cases which have a very large tilt spread may induce a certain uncertainty in the transposition calculation.

Since both front and back-face energy contribute to the module conditions (irradiance and temperature) it is not possible to split them. The simulation is not simply additive of back face and front face in that regard. This is shown by the loss diagram for a bifacial system: both contribute to the PV conversion:

Dear Vera, At the moment, there are no miscellaneous losses in PVsyst (it has been requested before). I would advise adding this loss to the mismatch between strings. This is conveniently in the DC side, and is consistent with part of the effect of variable terrain.

The stow position is in Phi (rotation) angle. This means that a negative angle is towards the east (as long as the axis azimuth is between -90 and 90, especially if it is close to 0).

Yes of course. You have TArray among the variables for output files: https://www.pvsyst.com/help/output_file.htm

You are comparing relative differences, but the irradiance is very low in the morning and evening. What does it look like in absolute differences ? Also, you mention a sweep of all the positions, but it is virtually impossible to have all angles. You must be doing an interpolation and sweep the positions with a certain interval? Possibly the interpolation causes some error, which becomes more important as relative values in the morning and evening due to the low irradiance. Just a hypothesis, please let us know. It is an interesting problem. What is the end objective ? A validation?

The output of the batch mode is only a CSV file, i.e., you need to use another tool to generate a histogram. The capacity of the system itself is not a parameter, but you can equivalently change the Number of strings and Number of inverters. This is equivalent to modifying the capacity of the system. If these two options do not appear in the “system parameter” tab, it means that your system has multiple sub-arrays, or some other complexity such as optimizers, etc, that prevents it to be used as a parameter. If you are unsure, please send a screenshot of your system definition, for example.

Hello ! To start with, I would define a variant with an “unlimited sheds” orientation. That is simpler than using a 3D scene, but in the end even for the latter it should work the same. To get the bifacial gain, you should compare the yield (E_Grid) for a simulation with the bifacial model active, and one without: Therefore, you should prepare a variant for each of the options, let's say, VC0 and VC1. In the batch mode, you can alternate between the two variants: You should also vary the parameters tilt and ground albedo. Honestly, in these figures, I see no interest to put the PV system capacity as a parameter. It has no impact on the variables displayed. The small differences that you see in the second plot are probably related to slightly different DC:AC ratios. However you can vary the following system parameters: To adapt the PV capacity.

Hi ! Diffuse shading should be completely independent of electrical shadings. I don't think that can happen.

Hello, we will fix this issue in version 7.4.6, out within a couple of weeks (normally).

As with any trick, you should expect a tradeoff in terms of precision. With this methodology, you are relying on two approximations: Using a single orientation instead of two. In terms of backside irradiance, it is ok if the tilt is not that large, e.g., your 5°. However, the tradeoff is that the transposition and IAM losses are not modeled using the true orientations. This means that the front side irradiance may have some error ! Please compare the front side irradiance values carefully between the variant using two orientations and the variant with the approximation. You are gaining about 1% bifacial gain, as expected for such a system with a high GCR. This is almost equivalent to a monofacial system, because there is almost no light on the backside. This may be well below the increased uncertainty in the front side irradiance, so please be very careful when interpreting these results, especially the final energy yield. Aligning the system with E-W, strictly. This is unnecessary. You can switch to a single orientation by using the 3D scene > Tools > Orientation management. There you can increase the tolerance and identify the orientations anew. This will apply even if the modules are not strictly aligned with the E-W axis.

As was answered many times in the forum, in PVsyst v7 it is not possible to use the bifacial model with multiple orientations. You should simulate the orientations one by one.

This is a very common question in the forum. Please read the following page carefully: https://www.pvsyst.com/help/bifacial-conditions.htm The error message indicates that the bifacial backside irradiance model, which is a simplified 2D model, is not very representative of the 3D scene for some reason. Also, note that the bifacial model can only work in V7 for a single fixed tilt or SAT orientation, in regularly arranged rows. For fixed tilt / SAT, the error will appear if the pitch is not regular in your scene, above a certain threshold. In such a case, you can bypass the error via the advanced parameters. In the case of SAT, the axis tilt is not represented in the bifacial model and also generates a similar error above a certain threshold, which can be also bypassed in the advanced parameters. The advanced parameters are found in the main window > Settings > Edit advanced parameters:

You can see that the main difference between the two variants is the “STC-Wirkungsgrad” (STC efficiency). This means that the modules used in the two simulations must be different in some way, probably. Can you check that the modules are really the same?

Hello ! In any simulation, you can export all simulation variables in a CSV output file: https://www.pvsyst.com/help/output_file.htm When choosing the variables, you can choose the variables GHI RHI GTI.

Not in v8.0. This may come later, but we haven't started the development for this correction yet.

Hi, if the trackers are ungrouped or defined individually, the "Pitch E-W" parameter is not important. What matters is the actual distances in the 3D scene. The backtracking will still work of course.

Hello, “Unlimited” orientations are orientations that allow to bypass the 3D scene, by entering some general geometric specifications (size of tables, number of rows, distance between tables, etc.). With these specifications, we can estimate shading losses. If you are using an unlimited orientation, you should therefore not use the 3D scene. The number of trackers will not be specified, only the number of consecutive rows is important. Instead, if you want to use a 3D scene, please start either by constructing the 3D scene, or choosing your tracker orientation not among the “unlimited” ones. By doing this latter option, when you create a tracker in the 3D scene, it will have the orientation defined in “Orientation”.

The discrepancy is because the area is not the ground anymore, but the module area. With a GCR of about 50%, 1 m^2 of ground is about 0.5 m^2 of module backside area. Proportionally, the energy per unit area is doubled.

Yes they can be different ! For example, if your system is on a roof, you can paint the roof in white. Then the albedo for the bifacial model would be high (white paint), but the surrounding albedo (concrete, grass, anything) would be lower.

Hello, we have a ticket so we will add this copy functionality at some point in the future. These two albedo values are generally different. The one in the project settings is the "far" albedo that usually affects the front side of the front row of tables. The bifacial albedo is the albedo of the ground below the module rows directly.

In PVsyst v7, there is only a single tracker orientation at a time, i.e., all trackers move based on the same backtracking parameters. These are “table size”, “pitch”, and “top and bottom frames”. If the difference in module size impacts the difference in tracker table size, then this may impact the backtracking parameters, depending on your choices in the “Backtracking management” window. However, ultimately, all trackers would still face the same way. In PVsyst v8, you will have several tracker orientations, i.e., you can have some trackers move one way, and other trackers move another way.

When exiting the batch definition window, and before clicking on simulation, you should also define the hourly output file format. If it is not defined and the checkbox “Enable output file” is not checked, then the hourly output may not be generated. Could your issue be due to this?