Robin Vincent

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.

Please contact the support by email at support@pvsyst.com with your project (project => export project) so we can have a better understanding of what is happening.

The results export is restricted to the same time step as the simulation, which is set to 1 hour. Smaller time steps will be available once the sub-hourly simulation is.

No, the simulation itself is still hourly-based. We only extract additional info from sub-hourly weather data to correct the clipping losses.

With unlimited sheds, pretty much all the parameters you mentioned will impact the near shadings losses. You may be able to find more detailed information in the help page for diffuse losses with tracking systems : https://www.pvsyst.com/help/project-design/shadings/calculation-and-model/diffuse-losses-with-tracking-systems.html#tracker-diffuse-shading-definition-window-from-version-730