Michele Oliosi

Okay, this seems to be a new bug. We will take a thorough look into this. Could you send us your project at support@pvsyst.com? This would be extremely valuable to fix the issue as quickly as possible.

You should check the following window : 3D scene > Tools > Tracker diffuse shadings definition. There you can check whether the representative tracker has shading masks (neighbors), if the loss is zero it probably is not identifying masks properly. You can switch to "all trackers" which is slower but is more accurate and robust. Let us know if that fixes the issue.

Thank you ! This may or may not be the reason, but now it is important to go through all the sub-arrays in the system window, to make sure the different bifacial models are active and well-defined. Indeed, there is a bifacial model per orientation now, to allow for different sets of bifacial parameters.

Indeed, the process is only manual for now. At some point we will get a tool to quickly assign orientations. PVsyst CLI will help with automatizing the "simulation" step, but for now no other steps, so it won't help here. By the way, what is your case, i.e., do you have more than two orientations in parallel electrically ?

Hi, yes that is technically possible, to associate each tracker to a different orientation. The basic TF losses are then obtained orientation by orientation so that works as well. The module layout will help in terms of shadings. One possibly missing feature is if you have more than two strings in parallel on the same MPPT and these are on more than two orientations, it is not possible to define that properly in the System part. Currently, string-to-string mismatch is possible to evaluate only for two different orientations connected in parallel. Finally, moving in the territory of custom tracker movement is more complicated. Indeed, you can apply a backtracking algorithm to each tracker movement, but that does not depend on the relative height. At the moment, only the ideal algorithm that avoids shades on a regular array of trackers is applied. Of course, we are working on a solution for custom movement, but that will take several updates before its release.

@FredrikRH it should calculate the bifacial gain for all orientations. Could you send your project over at support@pvsyst.com ? This would be extremely valuable to root out this bug.

Thanks @Maruyama. Indeed, this is the way to go. We need to give better guidance on this point including in the UI side of the software. We will be working on this.

@dtarin yes there are actually plans to completely rewrite the weather data import, to address these two issues and others in one go.

If you import sub-hourly data you can then use that as an enhanced MET file in your simulations. Here is a help page that breaks it down: https://www.pvsyst.com/help/physical-models-used/grid-inverter/subhourly-clipping-correction.html

Generally, smaller (rooftop) installations are more complex in terms of shading than large, regular ground mounted systems. In the latter case, strings are usually distributed on one or two large tables, and this pattern repeats, which makes it possible to use the “partition model” which is a simplified model to estimate electrical shadings. In the former, smaller rooftop case, it is best to use the most detailed modeling of electrical shadings. This is the module layout option, which necessitates to determine exactly which module 3D model is connected to which string. Even though your system is simple electrically, given the 3D scene, shadings will have a non-trivial aspect and necessitate this more advanced calculation. You can see one such complex shading pattern in your first screenshot.

It is partially solved in version 8, which should release (really) soon. You will be able to define separate bifacial models, one for each fixed tilt or tracker orientation. However, dome configurations are not yet covered by this update. We will work on it for a future minor release…

Hello, the forum language is English, but if you send your query to support@pvsyst.com we will happily reply in French. If this period is continuous within the interval of January 1st to December 31st, then you can use the following tool. From the project window, go to “Advanced simulation”. There you can change the start and end date of the simulation. If you then run the simulation by clicking on the “Run simulation” button in the “Advanced simulation” window directly, the correct dates will be set. However, the method you suggest will also work, i.e., importing weather data that covers a shorter period (possibly with holes).

Hi, not sure what you mean by using a CSV to build the 3D scene. Could you send your project at support@pvsyst.com? We would then be able to look at the 3D scene. In any case, take a look at 3D scene → Tools → Backtracking management. There you can verify the backtracking parameters.

Hi ! Actually, you do not need to have an "array of tables" in the 3D scene to apply the bifacial model, but there are a few regularity requirements that have to be met: https://www.pvsyst.com/help/bifacial-conditions.htm However, it cannot be expected that you modify the pitch of your plant just to run the simulation. For that reason, it is possible to modify the threshold for the activation of this error. Since this error stems from the evaluation of the standard deviation on the pitch distribution, the threshold can be changed in the advanced parameters : Home window > Settings > Edit advanced parameters: Please be aware that while this won't modify the results of the simulation, it will allow you to simulate a situation in which the bifacial model (which is a regular idealization using the average pitch and table size values) will not fully represent the complexity of the 3D scene. However, usually, unless you have a very strange setup, the error from this discrepancy is minimal.

There is a problem with the trackers created by zones. These end up having +-90° of maximum and minimum rotation angles. To correct this, once you created all trackers, you can either go to Tools > List and management of objects, or simply press CTRL+G in the 3D scene. There, you can find the column with the min / max phi and edit them to be compatible with the orientation.

@Loïs Masson Yes it is possible to use partitions with a non-rectangular PV table. Honestly, with non-conventionally wired modules such as the voltec ones, there are no other solutions with the current PVsyst version. Finding equivalent modules, to run the module layout calculation, and using that to adjust the results of the partition calculation, as suggested at the beginning of the thread, seems like a reasonable idea.

In all three cases, you should put X = 2, Y = 1. Indeed, you have at most one string per table. Y, for NS-axis trackers, should be the number of strings longitudinally. If there is a fraction of a string (such as in the case of half- or quarter-strings), you can leave Y = 1 as well.

yes you got it, x = 2 (because half-cut) and y = 3 (# of strings)

Can you also share the voltec module references ?

The partition tool is not really adapted to this kind of situation either. For irregular shadings, it tends to overestimate the losses. I would suggest changing the parameter "Fraction for electrical effect" to about 20 %. This will reduce the electrical shading loss so that it has about the same magnitude as the jinko modules. I did not go as far as setting a 10% fraction because it is better to be very conservative in this case.

This is normal, since PR is defined normalized by the front-side POA irradiance (GlobInc) but bifacial modules can also capture light from the back. The PR of bifacial projects is oftentimes > 1. There are more details on this help page: https://www.pvsyst.com/help/performance_ratio.htm Regarding the negative Global Incident, this is also normal, because it accounts for the front side irradiance relative to the horizontal plane. If you just look at the front-side, there is more irradiance on a horizontal plane than on a vertical plane. This is of course more than compensated by the backside irradiance part of the loss diagram.

The Global incident will be negative if the orientation is worse than the horizontal fixed plane. I am not sure why, just from your text. Indeed, in principle, trackers should have a better transposition than a fixed plane. It is difficult to answer just from the loss diagram and 3D screenshots. Could you export your project and send it to support@pvsyst.com ?

Did you try other distances? I don't see a problem because you show just two instances. At 4 meters there may be still a lot of impact from mutual shadings.

In your top question, the shadings are not exactly the same. Are you using the fast (relying on interpolations, which are sensitive to tiny rounding differences) or slow method ?

EW trackers here can follow the sun closely in the morning and evening. Instead, fixed tilt does not have a good orientation in the morning and evening.