Michele Oliosi

This does not seem related to the domes, actually. This type of error usually stems from how the module has been defined. However, the exact cause cannot be known from the message alone. There can be multiple reasons for it. If you could export and send us the project at the email written in the message, it would allow us to take a deeper look and find the underlying cause. Thanks in advance !

GlobBak is not technically weather data, since it depends on the system definition. You should instead run the simulation and create an output file: https://www.pvsyst.com/help/project-design/simulation/create-a-csv-file-of-hourly-daily-values.html So is BackShd. Note that if you have defined an horizon profile, you should rather use GlobHrz, instead of GlobInc, for the frontside POA. Indeed, the horizon also affects the solarimeter.

Right now we are looking at the next minor version of PVsyst (8.1), but that could still change (before or after) of course.

At the moment, changing the parameters programmatically can only be done via PVsyst (by using the batch mode to create and/or simulate new variants). In the future, we will extend the use of CLI so that parameters can be changed programmatically only using PVsystCLI.

I have checked further, and the pitch seems to be effectively changed, even for the backtracking algorithm. This is despite the message saying otherwise. The message seems to stem from a check, before updating the backtracking algorithm. It is therefore not relevant. Note that this does not happen in version 8 anymore, in principle. Have you checked ?

You still have the column "Pitch" in your batch file. Since there are only trackers in the scene, the pitch cannot be changed, which triggers the warning. What matters is the other column, "Trackers pitch EW". I would recommend removing the "Pitch column" and rerunning the batch. Note also that you should be mindful of how the backtracking parameters were set (3D scene > Tools > Backtracking management): Here the mode is manual (automatic unchecked). This means that if the batch mode changes the pitch, the backtracking algorithm will not follow, and the yield may decrease (either from being suboptimally oriented or from shadings). Instead if you choose "Automatic", then the backtracking will adapt to the changes from the batch.

Do you want to have the theoretical plane of array irradiance without shadings, horizon, etc, or the effective irradiance you would measure front side / back side ? The backside POA irradiance (without applying shadings or horizon) is GlobBak + BackShd (GlobBak has had shadings applied, so some irradiance needs to be reintroduced). GlobInc is the POA irradiance on the front side (without applying shadings, etc).

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.