Defining partitions when importing scenes with terrain-following trackers

[laurahin]

Hi,

We are treating our first project that uses terrain following trackers (Nextracker XTR).  When creating the scene in PVcase, our CAD worker had to define articulation points where the trackers could change angle.  The design calls for 27 module strings, and they’re broken into groups of 6-8 modules as needed.  During import into PVsyst, the tracker sections are being read in as separate trackers.  We don’t have an issue with this, but haven’t found a way to define the partitions for electrical effect calculations.  In the past, we have sometimes used slightly longer trackers in the shading scene to make them fit properly.  In this case, we’ve used a non-integer number of partitions per object.  We thought we would do the same here, but the non-integer values would have to be less than 1 and this isn’t allowed in the partition definition.  Any recommendation? 

I saw some relevant info on PVcase’s web page (below), but didn’t understand it.  It may be that we brought the scene in incorrectly (the “Import to PVsyst steps” link is broken) and the segments comprising each tracker are still associated in some way in their example. 

Thanks!

 

 

[laurahin]

I looked at this help page from PVcase more closely.  It appears that we have to run PVsyst twice if we want to get the electrical effects of shading correctly.  Is that true?

Thanks.

Modeling Terrain following trackers from PVcase in PVsyst | PVcase Help Center

[dtarin]

 For terrain following trackers we model all trackers 1 string in length to adapt as much as possible while retaining the electrical shading effect one would expect. 

Using the module layout shading calculation you can assign strings to cross multiple tables, and the limit in PVsyst can be bypassed in the settings (I think before it was 5MW, not sure if that is still a thing). One other possibility is if you were originally modeling half cell modules with 2 in width by 1 in height (for single string racks), you could model half racks 1x1. Running a test between this method and a module layout simulation might inform you on how accurate it is. 

 

[Michele Oliosi]

Just to complement the discussion, we have gone through this tutorial but are a bit puzzled as to why you would need to do two simulations and not just one. I think we are missing some understanding about why this tutorial was written, to begin with.

When you choose the TFT option in PVCase this just seems to change the export to PVsyst. This is done in a way that splits “Terrain-following” trackers which have a further articulation into smaller trackers so that PVsyst gets the number of modules right. In my view, then setting up the partitioning definitions on these trackers is OK.

From what I understand, there is a worry that since partitions are limited to a single table in PVsyst, in the TFT scene, they do not represent well “a string”, i.e., the shading electrical mismatch calculation will underestimate mismatch effects. However, in general, shades caused by the topography are quite irregular to begin with. Since PVsyst's partitioning approach in version 7.4 is conservative for these cases (we even advise reducing the fraction for electrical effect if shadings are too irregular, based on module layout results for example), slightly reducing the shading electrical mismatch losses by splitting the partitions lengthwise is not going to put you in tension with the reality of the field or loss mitigation.

Moreover, if you don't use the TFT approach, the tables will be longer and straight, i.e., I am not sure how well the electrical shadings are modeled in this non-TFT case. Since you are diverging from the real geometry of the tables, I wouldn't take results calculated without the TFT as a reference for the electrical shading loss.