Michele Oliosi

Hi, this is a complicated question. The partition model is really ill-fitted to this kind of arrangement. The best is to model this first with the module layout: In this situation (GCR, tilt, climate, inverter layout, type of modules) this gives me about 0.9% electrical shading losses. If I then wanted to replicate this in the partition model, it is best to proceed by trial and error. Here defining 3 partitions in Y and 1 partition in X seems to work best to replicate the same amount of electrical shading losses. I tried first Y = 6, but the electrical shading losses were too small. In summary, it is hard to define how to partition in this kind of situation, and it will depend a lot on many factors. It is best to check with a simplified layout in the module layout to make sure that the partitioning gives a good amount of losses.

Half-cut cell modules in portrait, strung in U (2TU) have: - Partitions in y = 2, partitions in x = 1 For wider tables which are 2 strings across (26 = 2*13) still strung in U: - Partitions in y = 2, partitions in x = 2 https://www.pvsyst.com/help/shadings_partitioninstrings.htm

Please read the highlighted tutorial..

Hi, First, please understand that the partition model is an approximation that is well-defined in the case of simple rows of tables or trackers, with topographies that are quite regular. In the case of other irregular situations, such as your figure 6 and the discussion about figure 4, the usual rules from the help page do not apply. You can choose to use the partition model differently than the intended partitioning, as you did, but this should be done very carefully. I think you are correct in decreasing the number of partitions when shadings are irregular; this is the more conservative approach. Regarding figures 3 and 5, I agree that a partition in X is missing. Indeed, it should be X = 2, to differentiate the different strings. We will correct these images asap. Regarding figure 1, I do not agree with your comment. Indeed, in the case of regular rows, the effects of by-pass diodes and diffuse fraction accounted together are best modeled by Y = 2. Even if there are multiple strings on a given MPPT, as long as they are all shaded in the same way, the effect is the same as having one string by MPPT.

This is not possible directly from a single PVsyst simulation (which is in hourly steps). But you can run multiple simulations to approximate sub-hourly results. In version 7.4.8 we added a tutorial for this procedure because it is a bit technical. You can find this tutorial here:

You have 1% "climate change" this parameter will make P50 and E_Grid(Sim.) differ. It represents the fact that the weather data used for the simulation is not representative for the P50 (e.g., the P50 may change in the future, or has changed since the data was recorded).

If you look at the irradiance on the plane (GlobInc) you can see that it is fairly similar throughout the year. The chosen orientation is giving a push to the production in winter.

This is because clipping is handled by displacing the working point on the input IV curve. This causes the clipping losses. Of course, we do make any needed conversions from inverter nominal power (AC) to the corresponding DC power.

By default, the backtracking algorithm will find the lowest pitch in your scene (hence the highest GCR) as reference for the backtracking motion. This is what is indicated in this message, and it means that some trackers in your scene are slightly closer to each other than the others. This may be due to how the row distance was calculated in your initial layout. In any case, this is not really a problem, but more of an information. You can, if you want, adjust the backtracking settings in 3D scene > Tools > Backtracking management.

Hi, this is actually related to the albedo component. You can check that by setting the project settings albedo to a lower value. This will in principle decrease the near shadings proportionally, if the pitch is large enough for mutual shadings to be negligible. Note that albedo shadings are extrapolated from the shadings at the lowest sun height, so they are very sensitive to having another row, even very far. In the case of a bifacial system, I would not be too worried, because the loss of albedo due to mutual shadings is in principle mostly compensated by the ground reflection on the front side. This latter contribution is present in the case of the bifacial model being activated.

Yes, it is okay to relax the corresponding thresholds. Indeed, there is no alternative, currently. However, please be aware that the uncertainty will depend on how good the “average geometry” is a good approximation. The averaged orientation is currently an average of the axis azimuths and tilts, done separately. This works well for small angle differences, but is not so robust for large differences in either tilt or azimuth. For fixed tilts, the same is true for the plane azimuths and tilts. Modifying the tilt limitations does not increase the uncertainty per se. What increases it is if the 3D scene is a situation that does not match the “average geometry” well. We do not have any general use tools to estimate the increase in uncertainty related to the averaging, at the moment.

Okay, if the power-sharing is defined, the second possible reason is that some sub-arrays do not satisfy the following: The number of strings should be a multiple of the number of MPPTs, for each sub-array. This is easy to fix: for example, instead of defining a single sub-array with 5 MPPT and 6 strings, define one sub-array with 1 MPPT and 2 strings, and another with 4 MPPT and 4 strings. A warning message about this is supposed to show up, but other warnings sometimes mask it.

Each inverter is defined with an efficiency curve (or several): You see that this efficiency depends on the input power. The loss “Inverter loss during operation" represents this efficiency throughout the simulation.

If all the MPPT have strings on the same orientation, then it is possible to use the power-sharing to equalize the nominal DC:AC ratios. This allows covering the case of strings of different sizes / different strings on different MPPTs of the same inverter. For the latter case, you should therefore use the multi-MPPT feature, with power-sharing properly set up. If the losses are much higher in the situation 2), it probably means that the power-sharing was not defined yet. Case 1) can be considered an approximation, since then you have to define only one type of string. The problem with the power-sharing happens when you have different orientations AND different DC:AC ratios among the MPPTs. This case cannot be defined properly in PVsyst with the power-sharing.

@Matcor Duarte this is a different issue. The original post had two different weather data sources. In your case, changing the configuration probably also changed the tracking or orientation in some way? This would explain some differences in the GlobInc variable. Take a look and compare the “general parameters” frame in the report.

near shadings : irradiance loss electrical shadings : electrical mismatch loss caused by partial shadings

The minimum height above ground is not very relevant to the near shadings. If your trackers go to 60° rotation angles: - it means they will follow the sun much lower than the 13° ones, inducing more mutual shadings if backtracking is not active - the diffuse component is also subject to more mutual shadings

You can find out the number of modules here at the bottom of the 3D scene window: Let us know if this helps, I am not sure if I understood fully your issue, sorry.

You should choose trackers to begin with, phi has no meaning in the context of fixed tilt tables.

Hi Matt, I see. In fact, the importance of shadings depends on your choice of tracking algorithm. If you use traditional true tracking, then indeed shades may be important. However, many tracking systems use backtracking, which, for low sun angles, sets the trackers at more horizontal angles, to avoid shading the direct irradiance component. When using the batch to change the pitch and number of trackers on your "array of trackers" (that is defined as an array in the 3D scene), make sure that you also change the number of modules, strings, and inverters accordingly (and if applicable).

Hi, indeed, this is a difficult task, and I am not sure how much can be done with the tools in PVsyst's 3D scene. I assume that tracker shading issues are due to the topography. The issue is mostly that the changes you want to make are at risk of being under-determined. You mention varying the module quantity and pitch, but then how do you decide the table arrangement ? Surely it will follow some rules. I can imagine that the rule would be to fill a predetermined zone as much as possible. To do this for a single simulation, I would generally employ the zone tool in PVsyst. However, there is no interaction between zones and the batch mode at the moment, so it is not useful to run a batch. In other words, this is no good in your case. The tracker shading issues is a small effect, and it will have very small differences from variant to variant. I think these differences will be well within the uncertainty of the 3D modeling to begin with. So I would suggest the following simplification: run one variant with topography and a detailed layout of trackers on it. This will give you a reference in terms of shading losses and especially electrical shading losses (which are not present on flat ground when backtracking) run your batch on a simplified array of trackers on flat ground. If you use a single Array of trackers, you can then more easily use the batch to change geometric variables or the number of modules and so on. Add the extra losses from the topography variant to the simplified variants as another loss, e.g., string mismatch. Of course, this is a crude approximation, but probably within the uncertainty of the system modeling. TLDR: this is a collection of thoughts on how to approach the problem, not sure how much it will help.

Let us know if I didn't understand the ramp-up part correctly. I am not sure if you are writing about a simple grid curtailment or something more complex.

If I understand correctly, when this event happens, there is a more restrictive grid-injection limitation or grid curtailment. There is no functionality to cover that in a single simulation, at the moment. However, you could run two simulations, one with the normal, and the other with the more restrictive grid curtailment limit. If you export the hourly CSV files (https://www.pvsyst.com/help/output_file.htm), you can then use a data analysis or spreadsheet tool to combine the data when you wish during the year.

PVsyst uses the average plane orientation for transposition calculations in an “averaged orientation” such as with trackers on a complex topography.