Michele Oliosi

As mentioned above, in PVsyst v7 it is not possible to run multiple orientations with the bifacial model. You should either make a variant where you approximate all orientations with the average one, or split your differing orientations into separate variants.

Hello! Sorry at the moment it is not possible to simulate a variant with multiple orientations and the bifacial model. For a carport, if the orientations are not too different, I would suggest running a variant with a single orientation (the average one) to at least get an approximation for the bifacial gain. This will complement a “monofacial” simulation run with the 2 orientations.

Version 7.4.6 further improves the evaluation of electrical shading losses by correcting the bottom cell strips positioning for NS-horizontal-axis trackers, tilted-axis trackers, and EW-frame trackers. In version 7.4.0 to 7.4.5, the bottom (and top) one-cell-wide strips were drawn incorrectly along the short side of trackers. Version 7.4.6 corrects this and draws the one-cell-wide strips along the longer edge of the trackers. This correction will drive electrical shadings down slightly for projects with electrical shading losses, trackers, and an irregular topography. This mitigation of the losses comes on top of a conservative model, thus moving towards more accurate values, in general. As a consequence, especially for projects with NS-axis SAT (and other less common trackers noted above), it is advised to update to 7.4.6 and run key simulations to obtain more accurate results.

100% agreed. We have a ticket to address this.

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.

Dear Gregory, This seems like a very good approach, I see no inconvenient in applying it to other subdivisions. Of course, keep in mind that this is an approximation, but that will give you a good estimate of orientation mismatch within a string.

Indeed, in reality, there will be a small impact on the reflected irradiance if the ground is tilted. However, the bifacial 2D model in PVsyst does not include these effects yet.

Development of version 8 took longer than expected. Indeed, this time “This year” should be a more trustworthy statement.

Dear Spencer, No, at the moment there is no real possibility to increase the amount of electrical shadings with the model of electrical shadings in partitions. It's an excellent point which we should address. The worst case value in the model is when there is only a single partition per table. But if due to the wiring, a shade on one table deactivates several tables, that cannot be modeled with the partition model. A workaround could be to define larger tables (across the same row). But in case of strings over different rows, I really don't see how to solve the problem with the partition model. The only way in PVsyst would be to go with the module layout model, but for large scenes it will take quite a lot of time. If you send us some examples (screenshot or better full project) we may be able to take a more detailed look, but I'm not sure what can be done.

Hmm I agree that this plots seems wrong. There may be a bug at that level. Sorry, we need to correct it. By the way these plots are there just for information, they don't have an impact on the simulation.

Other than what is included in the help, I should say that the partition model is an approximation, that tries to account for mismatch between submodules that are shaded or not. On top of that, in the end the inverter decides which operating point to choose on the total IV curve, which can be quite complex for partial shadings. In the situation where a string is on two different rows, you will have 1/2 of the modules being affected by shadings most of the time. This causes an increase in mismatch compared to a situation in which modules are all on the same row. This means that this situation is less resilient to shadings. It ensues that there need to be fewer partitions.

Hi, Please read the following help page: https://www.pvsyst.com/help/shadings_partitioninstrings.htm It might be correct for the 2*24 table, but it depends on whether the modules have half cut cells in parallel or not. In case of half-cut cell modules, you should make 4 partitions in Y instead of 2. For the 2*12 table, this is not as resilient to shadings. It's hard to model it with PVsyst, but a good start is: standard modules, leave as is NPartY = 1 half-cut modules, NPartY = 2

This error message was meant to be present in the previous versions of PVsyst, but a bug prevented it from appearing. This has been fixed in the latest version of PVsyst, that’s why you see the error message now. To get rid of the error message, you can go to the Home window > Settings > Edit advanced parameters, search for “spread” and modify the following value: I hope this helps. Note that cases which have a very large tilt spread may induce a certain uncertainty in the transposition calculation. NB: Please open a new thread if there are issues not related to the original post.

There is not more direct sunlight on the backside of the modules by increasing the height. Only reflected sunlight on the ground will increase. The maximum irradiance on the ground is found when the tables are high enough so that their own shading of the ground has little impact. This happens relatively fast. Intuitively, if you imagine tables very high up, you can imagine how the shading they cast on the ground is irrelevant in most hours. From that point on, it does not matter at what height they are.

Indeed, at the moment this is not possible in PVsyst. We only model the impact of mutual shadings for the backside irradiance modeling.

There is no mistake in your settings. At the moment, the bifacial backside irradiance model is a 2D view factor model, that approximates the situation of the 3D scene. Shading objects are not represented, neither are differences in height of the tables and so on. One partially related point is that the “Height above ground” in the backside irradiance model definition is not retrieved from the 3D scene either. You should therefore enter it manually according to your system specifications.

Hello, Indeed, the optimization tool is quite rudimentary and doesn't include many parameters to vary. You can however change this parameter with the batch mode, which has many more capabilities than the optimization tool and is useful for more advanced comparative studies.

We will release more information as it comes along. For the moment, I can just say that it should be expected sometime in 2024. Currently, as mentioned on this recent post we are trying to release V8 this year, as early as it is feasible. We would like to add the sub-hourly modeling correction feature in either of V8.0 or V8.1.

What I meant is that if you define a single sub-array containing 100 inverters and, 2114 strings: PVsyst will evaluate the average DC:AC ratio for the sub-array, on this window, only to trigger warnings. In this instance, it does not trigger a warning. For the simulation, PVsyst will consider : 86 inverters with 21 strings x 32PV per string; and 14 inverters with 22 strings x 32PV per string. Instead, if you properly define two sub-arrays with 86 inverters with 21 strings x 32PV per string; and 14 inverters with 22 strings x 32PV per string: For the evaluation of warnings, this time each DC:AC ratio is computed, since this is done sub-array per sub-array. One of the sub-arrays triggers a warning. For the simulation, there is no difference: PVsyst will consider 86 inverters with 21 strings x 32PV per string; and 14 inverters with 22 strings x 32PV per string.

We have some improvements that will help on our roadmap. In particular, in version 8, it will be possible to define multiple tracker orientations. This will be useful in case there are few distinct slopes (+ small variation, that will be averaged upon).

Dear Virgil Ciolponea, Are you sure you want to use E-W trackers? This type of tracker is more uncommon. NS-axis trackers (turn towards east in the morning and face west in the evening) are more common. Unfortunately, the bifacial calculation only handles NS-axis SAT at the moment. Even though PVsyst will formally allow turning the N-S axis tracker 90° around, it will not lead to good results, especially in backtracking mode (the backtracking of EW and NS axis trackers are different). If you need a bifacial gain value, I would suggest extrapolating the values using a fixed tilt variant to establish an approximation of the bifacial irradiance gains.

Hi Laura, Thanks for the suggestion ! Indeed, at the moment other than tweaking the files, there is no way to reset this. I filed a ticket to find a way to reset the state.

Hi, Unfortunately, in v7 it is impossible to have both trackers and fixed structures in the same variant. You should simulate them separately instead. This limitation will be lifted in v8, to be released sometime in 2024.

which settings in particular ?

Yes, that would be the correct way to proceed. If the irradiance is already reduced by a horizon of some kind, no need to account for it a second time in PVsyst.