Michele Oliosi

Minor version 7.3 has introduced a new way to compute the electrical effect of shadings, whenever only the cell at the bottom of the modules or submodules is shaded. The goal of the update is to better represent the actual behavior of these electrical effects: if one gradually shades the cells the are at the bottom of a module or submodule row, the electrical shading loss should quickly increase linearly until a plateau is reached (they are at their maximum value) once the full cell width is shaded. Compared with version 7.2.21 this tends to decrease the electrical shading losses. However the discrepancies have been more marked in certain cases. In practice: In the "module layout" mode: the new bottom cell evaluation is performed for each submodule independently. This is the most accurate way to model this effect in PVsyst, and we are confident that update 7.3 has improved the overall accuracy of the evaluation. In the "according to strings" mode (fast and slow): the bottom cell evaluation happens globally for the whole scene. An average shadow height is evaluated and compared to the width of the bottom cell. This approach has been extensively tested in regular setups, and should be more accurate than 7.2.21 for regular arrays with many rows, on a single orientation. However, this approach tends to underestimate the electrical shading effects as soon as irregularities are added, e.g. other shading objects, being on a complex topography, or using different orientations. This unfortunate effect has been discovered recently and a correction is being studied. The new behavior can be circumvented, see below. When using the "unlimited" orientations, with electrical effect activated: this situation is ideally regular, we therefore expect that new corrections yield a more accurate result (see caveat just below). A less common error affects projects using the unlimited orientations and half-cut modules in landscape. At the moment the bottom cell evaluation is incorrect for this case. We recommend using version 7.2.21 for this specific case. Workaround for the "according to strings" mode: To revert to a behaviour that mimics version 7.2.21, users can modify the parameter "3D elec. shading: Fraction of bottom cell for no shading" to 0 %. Note that in certain cases, the behaviour of 7.2.21 cannot be replicated. This is for example the case whenever shades cover only a very small fraction of the area, or with thin shadings. The second parameter in the screenshot can also help mimic version 7.2.21 for the "module layout" case. We however consider the new calculation better than the previous.

PVsyst will not calculate like that. PVsyst will simulate the following: The reason for the difference between warning in one case and error in the other is that (for the warnings only) PVsyst in the first case does only a rough evaluation using the total Pnoms, it doesn't separate the two types of inverter. If you still want to proceed, you can change the threshold for activation of the error. It is found in the project settings, you can increase the value 3% to a higher value.

0) right 1) Yes, in fact we iterate the formula twice, because the efficiency depends on the temperature. 2) U = Uc + Uv * WindVelocity, and the values are kept as entered by the user. 3) usually, but it may be different (it is defined in the module, you can find it under "Additional data" / "Secondary parameters" 4) GlobEff 5) efficiency is the module PV conversion efficiency, not jut 10%. See point 1, we start with the efficiency at ambient temperature, and then iterate the formula.

Hi, the bifacial model as it is now was built for rows of modules. If there is only one row, PVsyst cannot decide on some parameters and cannot proceed. We are planning to improve this gradually, but for the moment the only workaround is to add a second row somewhere far enough so that there are no mutual shadings. As long as in the bifacial model there is a pitch value, it should then work.

If you have a single nominal orientation, the simplest is to use the window "orientation management" to identify all effective orientations as a single nominal one. You will find this window from the 3D scene view > Tools > Orientation management tool. Once there you can adjust the tolerance and "identify orientation", the goal being to define a single orientation. This will also give you some information about the largest deviation in effective orientations in your scene.

Hi @Endura indeed we have confirmed this new "linked" behaviour, which is in fact incorrect. We will be working to reverting to the previous behaviour within a couple patches. In the meantime I would go about as you suggest, i.e. Sorry for the inconvenience

Hi, There are two issues: Most importantly, the bifacial model can only work with horizontal single-NS-axis trackers or slightly tilted axis. It won't work with dual-axis trackers. This is a current limitation of PVsyst. A minor issue is the one shown on the message. When opening System > Bifacial system, you will see the following radio buttons You should select "unlimited sheds 2D-model" for fixed plane orientations, and "unlimited trackers 2D-model" for tracker orientations.

This is due to the details of the algorithm used for the distribution of the power in PVsyst's inverters, after applying the grid limitation. Since we have improved this algorithm quite a bit in version 7.3, I would suggest trying it out.

Hi, we have improved the calculation to account for the size of the bottom cell on each partition. This may indeed change the electrical shading losses. I am however surprised to see that the losses increased. If it's possible for you we could have a look at the variant if you send it over at support@pvsyst.com. You can export the project via the main window > File > Export projects.

Hi, Yes this is likely the cause. In fact the "central tracker and mask" algorithm will somtimes fail, depending on the details of the scene, this is why we left the option of selecting "all trackers". If your computer can run it, it is the recommended option. We shall improve the central tracker and mask selection algorithm in the future.

Hi ! The above evaluation is idealized it does not assume a complex meteo data, but a clear sky day. Since the shading factors are different for the diffuse and direct component, once you put it into a realistic situation with varying diffuse and direct, you may get different results.

Hi ! Thanks for the feedback ! Indeed we are aware of this bug, at the moment the "account as separate factor" may not work in some cases. We are preparing a fix for patch 7.3.2.

Hmm I see, sorry I hadn't tried before answering. It seems we need to fix the interaction between batch mode and the date selection.

Hi @dtarin , thank you for the suggestion. I added a ticket on this topic.

You can try using the "Advanced simulation" button, leading to the batch mode to modify the tilt in your simulations, and the simulation dates selection to restrict to a specific month. This is more precise as it takes all your simulation parameters into account, e.g. shadings. There is also a tool found from the main window > Tools > Transposition factor. In this case there is no accounting for other parameters that could impact the optimum angle.

The modules will turn grey if there is no direct irradiance shining on them. In the 3D scene animation only direct light is taken into account. For low sun heights the north-oriented may not receive any direct light. This is probably why they turn grey. Note that the irradiance deficit will change depending on the time: in your screenshot, you are showing 18:45 (see the right hand panel). That is a case where the sun is low.

In this window, you can click on "no shadings". The orientation "unlimited sheds" already includes a shading calculation, therefore using a 3D scene shading calculation would be a duplicate. Btw you can use the fixed tilt plane orientation as well (with a 3D scene) with the bifacial model. The only restriction is that the 3D shading scene be regular (pitch, table sizes, etc) enough.

Hi @garf, I see that you have a total of 7 MPPT used on the 9 MPPT inverter. Probably when you set up the Power sharing, there is an error message appearing in red because of that; this will prevent you from completing the power sharing setup. To correct this situation, since we do not allow empty MPPT inputs in PVsyst in the multi-MPPT / power sharing mode, you can artificially change the number of MPPT in your inverter to 7 for the concerned strings. You can edit this in the inverter definition, making sure to change the inverter name and file name, and save as new, as to not to confuse both inverters in the list (with 7 and 9 MPPTs).

Yes, I agree with @dtarin if your modules lay flat, then you can put everything in a single orientation. If the modules are in alternating east west fashion (what I meant by domes i.e. something like the image below), then mixed orientation for each subarray is fine.

Hi ! We mean:

You can put up to two orientations in the same (system-) sub-array. For 3 or more, each orientation should be in a separate sub-array. The only case where you can put many orientations into one, is when dealing with a single nominal orientation on top of a complex terrain with slopes. In that case in the 3D scene, you can change the "Tolerance parameter" from the Tools > Orientation management window and identify the orientations, so that you get only a single effective average orientation. If you have multiple orientations as in your case: then you should check that each's sub-array's module area corresponds to the area of the modules found in the 3D scene.

Actually it should be calclulate loss irradiation I should calculate : ( power at STC conditions - power ( globinc,25°)) calclulate loss temperature I should calculate : ( power ( globinc,25°) - power (globinc,Tarray))

For the implementation within PVsyst: Are you in a dome (e.g. schematically /\/\/\/\/\/\/\/\/\ ) or two pane roof (schematically ////// \\\\\\\ ) situation ? For the dome one, you could just use a single sub-array, and choose "mixed orientation 1 and 2" instead of having two separate orientation sub-arrays. For the two pane roof, I think your approach works well: you create one sub-array for each orientation individually.

Unfortunately, last time we tried we weren't able to compare PVsyst and PVGIS TMY generation from a time series, since the PVGIS TMY file doesn't have the relative humidity. We are therefore not yet able to confirm whether they follow the ISO norm strictly or not. We will update our help in case we manage to cross validate the generation methods.

I don't think there is a variable for that, but an easy way to find this is generate a hourly output file (Advanced simulation > Output file, and then press "simulation" from that same window), select your day and make the evaluation in excel by selecting the hours above a certain threshold.