PVsyst 7.2.21 Power Sharing: Error Msg "Number of MPPT input not a multiple of no. of inverters"

[Ashley]

Hi there, 

I encountered an error msg saying that the number of MPPT is not a multiple of the number of inverters.

I am trying to do power sharing across 7 x 125 KTL Sungrow Inverters (total MPPT 84). The sum of MPPTs across the 4 sub-arrays adds up to 84 but PVsyst does not allow power sharing across the 7 inverters (e.g., 12 MPPT x 7 = 84 MPPT). Kindly advise. 

[Michele Oliosi]

Hi the issue here is that with these two configurations, it is not possible to know how the MPPTs are distributed among the different inverters.
For example, for configuration 1, there are 2 inverters, but you have 11 and 13 MPPT to distribute, so there could be (11+1 and 12) or (10+2 and 11+1) or...
For this reason, we ask that in each sub-array, the number of MPPT is a multiple of the number of inverters in the configuration it belongs to.

Despite the complicated premise, resolution is easy: you should split your sub-arrays further, so that you satisfy the requirement.
For example, in the case of configuration 1, you could split the sub-arrays into:  
- sub-array "west facing opt" split in west facing opt 1 with 11 MPPT and west facing opt 2 with 2 MPPT (total 13)
- sub-array "west facing 19pc" split in west facing 19 pc 1 with 10 MPPT and west facing 19 pc 2 with 1 MPPT (total 11)

This would give you two configurations instead of one:
- 1.1 with 10+2 and
- 1.2 with 11+1

 

[J. Behrschmidt]

I have the same problem an the number of MPP is a multiple of that of the inverter.

[J. Behrschmidt]

one remark: I ask myself, if it is realy necessary to pay attention that in each subfield the total number of MPP is a multiple of that of the inverter. In my opinion this criteria should be for the sum of MPPs of the sub-fields involved in power sharing. For the subfield it is more important, that the number of strings is a multiple of the MPP used in this subfield

[Michele Oliosi]

@J. Behrschmidt the requirement that the #MPPT is a multiple of the inverter number is necessary in order to fully define which MPPT goes to which inverter. As in the example above:

On 8/17/2023 at 9:44 AM, Michele Oliosi said:

for configuration 1, there are 2 inverters, but you have 11 and 13 MPPT to distribute,so there could be (11+1 and 12) or (10+2 and 11+1)

What this means is that in reality you don't have just 1 configuration, there are 2different configurations in your settings.

[J. Behrschmidt]

Thanks for your answer, but this belongs to the start of the topic and the example there. I posted another configuration. In this I payed attention that the sub-fields have a multiple of the inverter mpp. Why doesn't this configuration work?

[Michele Oliosi]

I see. The number of inverters in the configuration is 147, so none of the subarrays has a #MPPT multiple of 147.
You will need to be more specific with your assignments of strings -> MPPT -> inverters.

Each configuration should be an identical type of inverter. For example, if 25 inverters have the same configuration: 3 MPPT of type 1, 2 MPPT of type 2, and 1 MPPT of type 3, then that would be a configuration with 25 inverters. For each of these configurations you should create the necessary sub-arrays. In the same example, you need a sub-array with 25*3 MPPT of type 1, another of 25*2 MPPT of type 2, and another with 25*1 MPPT of type 3.

[Ashley]

Sorry, i don't quite understand the explanation. 

May i know the reason why the number of MPPT in each sub-array must be a multiple of the number of inverters in the configuration it belongs to?

Meaning to say, if I wish to do power sharing across 7 x 125KTL Sungrow inverters with a total of 84 MPPTs, each sub-array that i create has to be a multiple of 7 (e.g., 1,7,14,21, etc)?

Another question i have is whether this is a new feature by PVsyst as i did not encounter such an issue when i was using an older version.

thank you

[Michele Oliosi]

The important point to clarify is what a configuration means: it is a certain number of inverters that have exactly the same strings & MPPT configuration. Among your 7 inverters, there may be a subset (for example 3) that share in the same strings & MPPT configuration. Then in the sub-arrays that refer to this configuration, you should have a multiple of the number of MPPT in this configuration (in the example 3).

It is essential to separate the total number of inverters in your system, from the number of inverters in a given configuration.

Indeed, this check is relatively new. However, this means that some incorrect situations were allowed in the past.

[Ashley]

I see. Thank you for the clarification. However, I am not seeing any changes in "Inverter Loss over nominal inv. power" % after I managed to normalize the power sharing as shown in the screenshot. I am getting a % loss of 4.26. Is this normal? Thanks.

[Michele Oliosi]

In your situation, the issue comes from having multiple orientations. PVsyst has currently some trouble handling imbalances between MPPT powers when they are both due to a difference in nominal DC power, or differences due to the orientation which causes the power to shift from a string to the other.

The most critical is the case of configuration 1.

I would suggest not to use the multi-MPPT for these 2 inverters of configuration 1. You should instead define a single orientation with 2 inverters while disabling the “multi-MPPT feature”. You can then define the orientation as “mixed orientation”. There is a cost, however, in that you should define your strings as either all with optimizers or without optimizers (I assume that is what OPT means). This approximation is necessary to be able to have a single sub-array and use the mixed orientation feature. I think you will end up with less clipping losses. But since this case is quite complicated, please let us know the results, and we will help you with it if there are still some problems. We can also move the discussion to emails, at support@pvsyst.com, as you prefer.

[Ashley]

I am currently using PVsyst version 7.4.5 and I would like to follow-up on this issue...

Can i clarify what you mean by "PVsyst has currently some trouble handling imbalances between MPPT powers when they are both due to a difference in nominal DC power, or differences due to the orientation which causes the power to shift from a string to the other."

I ran 2 different simultations recently and i observed a significantly higher inv loss over nominal power for the latter (2.78% more). My question is when should i be enabling the multi-MPPT feature?

1. 125CX-P2 inverter with multi-MPPT feature disabled   

2. 125CX-P2 inverter with multi-MPPT feature enabled with various input DC power but same orientation

[Michele Oliosi]

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.

[Ashley]

I have checked the simulation and it shows that power sharing is already defined.

Please advise why the losses are still so high. thank you.

[Michele Oliosi]

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.