Large batch simulation of tracker based systems

[Matt]

I'm trying to set up a batch simulation of a system that would use single axis trackers, and I want to be sure that tracker to tracker shading issues are accounted for in some form. Problem is I only know how to do this with a 3D scene imported from something drawn in PVcase, but I need to run hundreds of permutations, each with varying module quantity and tracker pitch, so creating a shade scene for each permutation really is not within practicality. What other options do I have to simulate that?

[Michele Oliosi]

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.

[Matt]

8 hours ago, Michele Oliosi said:

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.

Thank you for your input, I'm indeed looking at things in a very simplified manner, so as you had suggested I'm just leaving topography as a perfectly flat plane. We're not using this for a specific project, but instead trying to better understand a few general behaviors so we can best inform what our upper and lower boundaries should be as we look at optimizing a site per a client's criteria.

Currently I'm assuming a 72 module tracker, and using the parameter file to vary the pitch, and total number of trackers. I'm not sure that tracker shading is a minor issue, are we referring to the same thing? I'm thinking of the module to module shading during low sun angles as tracker pitch starts getting very close when I talk about tracker shading.

[Michele Oliosi]

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).