Michele Oliosi

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.

Hi, I would recommend reading our help. E.g. https://www.pvsyst.com/help/irradiance_loss.htm These losses are the difference in PV production when calculating with a Module at STC conditions (1000W/m^2 and 25°), vs a module at incident irradiance and standard temperature (GlobInc & 25°), vs a module at incident irradiance and real temperature (GlobInc and TArray)

Hi @Rafael I believe Meteonorm can output the GHI with or without horizon. From their parameters page https://meteonorm.com/en/meteonorm-parameter: Gh Global horizontal radiation ("GHI") Gh hor Global radiation taking raised horizon into account I would therefore double check the map, is it Gh or Gh hor in that case ?

Just keeping GlobInc is more accurate than GlobInc + ReflFrt. This is because of the albedo contribution present in GlobInc. Therefore you could technically try GlobInc - AlbInc + ReflFrt. But ReflFrt includes the IAM, so GlobInc may still well be your best shot. Indeed both ReflFrt and AlbInc (included in GlobInc) are albedo contributions. There are slight differences in their calculation (e.g. the IAM factor which is included in ReflFrt), and the albedo values may differ. Still, in the flow of the simulation, AlbInc is eventually shaded (shadings below the horizontal are extrapolated from the 2°-sun height shadings) before reaching GlobEff. ReflFrt will then usually compensate this shading loss. Some differences may arise but the values can be considered close.