Michele Oliosi

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.

If all variables are 0, PVsyst may interpret this as missing values. How come both temperature and irradiance are exactly zero at the same time ?

Yes ! You can send at support@pvsyst.com

Thanks for the suggestion. It would indeed need some significant planning / work in terms of integration. But it would be quite interesting. Most likely this will land on our longterm roadmap.

Hmm indeed that doesn't seem normal. I'd try to try and recompute the shading factor tables, if you are using the tables. If that still doesn't change the results, I would suggest sending us your project (exported via the main window > File > Export project). We'll be then able to review if any parameter is causing that or if there is a bug to be corrected.

You should be able to find your file via the page “Meteo tables and graphs”. If it doesn't show up you may need to import again and also make sure that your workspace is not on a cloud-synchronized folder (which usually causes a few bugs).

The "Near shadings: irradiance loss" also includes diffuse shadings. In PVsyst we consider that these do not produce any electrical mismatch. It seems that your backtracking is working well, since the electrical losses according to strings are 0%.

Ah I see, if both are different from the nominal power of your inverters you can either: modify the inverter Pnom just set the most stringent of both (it would be very unusual if this changes throughout the year I think?)