Robin Vincent

For Huawei optimizers, we are strictly applying the rules requested by Huawei. In this case, they requested between 9 and 12 strings per inverter for the sun5000 series. Please contact Huawei directly if you think a modification to this rule is necessary.

We cannot answer for sure on the sole base of those diagrams. Please send us your project (in 7.4.7) at support@pvsyst.com so we can understand why you have such a difference.

After some archeology, here's a more complete answer : If you were using Unlimited sheds or unlimited trackers, the fraction of unshaded and shaded rear side was correct If you were using trackers on the 3D scene, the fraction of unshaded and shaded rear side was also correct (using the total number of sheds at least). If you were using fixed tilt on the 3D scene, then fraction of shaded rear side was always 2/3, and in that case your analysis is correct. This behavior has been fixed in the 8.0, and improved in the 8.0.6 when you have multiple columns of sheds. In the 8.0.6, you will be able to see and change the number of rows used for the bifacial calculation from the bifacial tool, which should let you try to reproduce the previous behavior if you want to isolate this specific change.

PVsyst V8 development was focused on improving the "orientations" management. This includes several modification that could impact the system you described. I cannot give you an exact list, since I don't know your exact project, but I think this one is very likely to generate changes in your results :

Regarding the bifacial contribution, please see this post : For the azimuth, are you using averaged orientations and/or do you have a specific field topography ? Since most of the reduction seems to come from the bifacial diffuse irradiance contribution, you can try manually setting the number of sheds in the bifacial menu. Setting Number of sheds = 3 should give you a value similar to what you had in V7. I'd suggest not to do so, as the V7.4 results were unrealistically high while results with the V8 should be closer to the reality. But you should be at least be able to validate the reason behind this change.

Update: In the V7, most of the time the number of sheds used for the sky diffuse on the rear side was set to 3. It meant that 2/3 of the sheds were impacted by mutual shadings, regardless of your project. Starting with the v8.0.0, we now use data from the system for this computation, which in most case results in a reduction of the diffuse energy on the rear side (a greater percentage of the sheds are shaded). This value is likely to change again a little in the V8.0.6, as we fixed a minor issue.

As mentioned in the other thread, the only way to mix orientations within a string is to use the averaged orientation option. This also means the transposed irradiance will be the same for all your modules sharing this orientation, so it won't generate any mismatch. Other effects (notably shading) will use the real orientation. But in your case, it should not change anything : string mismatch should not occur with module level optimizers. You can still change that behavior in the detailed losses menu, Power Loss at MPP.

Hi, Please check this tread, as it could contain the answer to your question.

If I understand correctly, you need to mix different orientations in a same string. In that case, the only solution I can think off is to use the "average orientation" option, combining NE + E and SW + W. Based on your layout, the azimuts seem relatively close, so the resulting transposition error should be small. You may find more details here : https://www.pvsyst.com/help/project-design/orientations-in-v8/average-orientation.html?h=average This will allow you to define only two subarrays, each with strings long enough to be connected to a MPPT input. If you still have issues regarding your project, please contact us at support@pvsyst.com with your project attached.

You are correct, it is not possible to define a single subarray with mixed orientation and SolarEdge optimizers in PVsyst. Nevertheless, you can achieve a similar result by creating two separate sub-arrays, one for each orientation, then attribute the strings to the same inverter. To do so, open the "strings configuration" menu in the system definition, then set different sub-arrays to each input of your inverters

Actually, it is even trickier than that. For both values, changes are detected if any of the 1st 4 characters is changed. It usually means 1 digit for module quality (the "-" counts as a character) and 2 digits for the LID. Then, if the value is less than 0.1 point different from the default, it is set to the default value. The final value is then stored and, as you mentioned, only 1 digit is displayed. This is obviously not ideal, and we should harmonize the behaviors and make sur the number of digit displayed matches the number used. Nevertheless, such an accuracy (1/10000) is definitively not necessary in the 1st place.

This issue is due to a bug in the automatic string attribution to each MPPT (triggered when changing something in your system or when clicking on reinitialize inverter list). It should be solved in the 8.0.5. Meanwhile, to be able to simulate your system you can try deleting and adding back each inverter one by one until the error message disappear. Make sure your system is fully defined before doing so, as any modification on the subarrays definition will trigger a new string attribution,which could lead to the issue reappearance.

Yes this is planned for a future version of PVsyst (at least with optimizers), but I cannot give you any timeline for it.

No you cannot set heterogenous strings in PVsyst. The closest workaround would be to have subarrays with strings containing +1 and-1 modules relative to your odd-strings definition, and connect them to the same inverter. It won't be exactly equivalent, and only work if the total number of modules connected to the inverter is even. But at least the total DC power would be correct, and the impact on the different component efficiencies and threshold limited.

Sub-hourly simulation is a simulation with a time step lower than 1 hour. It may be useful to correctly account for non linear phenomenon such as clipping and curtailment. It is currently not directly available in PVsyst, even though workaround exist to run pseudo sub-hourly simulation https://www.pvsyst.com/wp-content/pdf-tutorials/pvsyst-tutorial-v8-pseudo-sub-hourly-simulation-en.pdf or to have a better clipping correction estimation https://www.pvsyst.com/help/physical-models-used/grid-inverter/subhourly-clipping-correction.html?h=clipping. In both case, sub-hourly weather data is necessary.