Shading: Linear and Acc. to Module Strings Yield Same Result

[Dan Nicksy]

Good afternoon,

I have created a PVsyst model, including a near shading scene (NSS). Modules are installed flush mounted to a low-slope roof; I have modeled this as follows: Nb. Sheds = 1; Nb. X Modules = 39; Nb. Y Modules = 15. In order to represent individual strings within the array, I have partitioned according to module strings as follows: Nb. String in X = 3; Nb. Strings in Y = 15; Fraction for Electrical Effect = 100%. It is my understanding that this divides the shed (39 modules by 15 modules) into 45 strings (13 modules by 1 module each), and that if any part of a string is shaded, that entire string is treated as electrically ineffective (i.e. does not generate any power); I recognize that this may be overly punitive. The roof has a number of air conditioning units and ducts, modeled as elementary shading objects (parallelepipede, portion of cylinder).

I ran the simulation three different ways: No shading, Linear Shading, Shading according to module strings. I found that the shading loss was identical for both Linear Shading and Shading according to module strings; I verified this by outputting hourly Shading Loss to CSV. In order to test how PVsyst was behaving, I partitioned the entire shed (39 modules by 15 modules) into a single partition, such that if any part of the shed was shaded the entire shed should be electrically inactive. Again, I found that the simulation run with Linear Shading and Shading according to module strings yielded identical values.

Am I misunderstanding the "Partition in Module Chains" or the "Fraction for Electrical Effect" functions? (I have read the help documentation on both topics) Is this a known occurrence in PVsyst V6.39? Is there a justifiable reason that the production should be the same between Linear Shading and Shading according to module strings?

Thank you in advance for any help you are able to provide,

Dan

[André Mermoud]

In the simulation results, you havs always the same "Shading loss factor" in the irradiance losses. This corresponds to what I name "Linear Losses", i.e. the losses due to the irradiance deficit.

Now when you define shadings "According to module strings", you have an additional loss named "Shadings: electrical loss according to strings" in the Array losses group. This is the effect of the electrical mismatch.

[Dan Nicksy]

The factor, "Shadings: electrical loss according to strings" is zero in the waterfall diagram when the simulation is run with Near Shading according to module strings. I understand that the "linear" loss will be the same in each case, but am still confused why there is no further loss associated with the module stringing.

[André Mermoud]

Probably you have not specified the rectangles correctly ?

In the option "According to module strings", button "Partitoin in module chains", one rectangle should represent a full string of modules, not one only module !

[Dan Nicksy]

In my original model I partitioned in module chains as you suggest; in the "Partition In Module Chains" dialog box I set the rectangles so that one rectangle represented one full string of modules. I was surprised to see that the shading loss was so low, and that the "Shadings: Electrical loss according to strings" value was zero. I conducted two further tests to help clarify the issue.

1) Ran the model with Shading Loss as "Linear". The annual production value was identical.

2) Used the "Partition in Module Chains" dialog box to set the rectangle so that one rectangle was used to represent the entire array. My understanding here was that if any part of the partition was shaded, the entire thing would be electrically inactive. I understand that this is not representative of the physical situation, but was trying to test the PVsyst model to determine where my problem was. I expected to see a significantly reduced energy production value, but instead the model yielded the same production as the "Linear Shading" simulation and the original "According to module strings" simulation where the array was partitioned such that one string was represented by one rectangle partition.

[Dan Nicksy]

Update: I've done some digging and discovered the following two anomalies:

1. At some points throughout the day, the "Shading factor according to strings" is zero even though there is shade cast on a "string" i.e. partition of modules. In Fig1 and Fig2 there are 14 modules in a single shed partitioned into two strings and the shading object is 0.5x0.5x0.1 metres, centred at (0, 0, 0.15 metres). Fig1 shows the simulation performing as expected; Fig2, one half hour timestep later, shows a non-zero linear shading factor and a zero shading factor according to strings. It seems that the shading factor according to strings goes to zero whenever the south-most "string" has shade cast in its middle, but the shade does not touch any edge of the partition.

2. If the bottom of a shading object is higher than the panels (in the Z-direction) then the object may not contribute to the linear shading. Fig3 shows three shading objects; the bottom of the two on the right is higher than the panels. These objects to not cast linear shade on the panels (shown as yellow rather than grey). In Fig4 the same objects have been extended downwards so that the bottom of the objects is below the height of the panels; now they cast shade on the panels.

Are these known issues? Has anyone else reported these problems?

Note: I'm aware that it is unusual to have shading objects that are a) this close to an array, and b) directly above the array. However, this is a real-world problem I'm facing involving a pre-existing array and a landlord installing some new HVAC equipment, and I'm trying to model it appropriately.

[André Mermoud]

The calculation of the shading factor "According to module strings" is indeed not quite reliable in some special cases like this one.

Please remember that this calculation should be considered as an approximate tool.

The program analyses the shading state of each summit of the rectangle-string, and one intermediate point on the segment. Therefore a little shade on a part of the rectangle-string might be not recognized.

For such a special condition, you should use the "Module Layout" option. Here the shading state of the corner of each sub-module is analysed.

Now for the object not taken into account due to its base altitude, perhaps this is a result of the optimizing algorithm. In the 3D editor menu "Tools" please try to desable "Optimized shading calculation".

[Dan Nicksy]

Thanks for the explanation. Now at least I understand why I'm getting these results.