Michele Oliosi

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?)

You can check this topic as well the issue is similar

@JaviBrave Here is a quick gif of the procedure, hope that helps !

Hi, you should rather put 2 rectangles in X. It is not really possible to define 1.5 string per table, but since (I assume) all your strings will be submitted to similar regular and longitudinal shadings, the distinction between the full and the half string will not matter for shadings. They will probably be shaded in the same way.

Actually PVsyst will apply both by default. The nominal active power limitation by the inverter is automatic. The question "limitation applied at" "inverter" or "injection point" refers only to the supplementary grid limitation. The difference is whether or not the losses between inverters and injection point should be taken into account to raise the limitation a little bit at the level of inverters.

Basically if you are using a PAN file not from the PVsyst database, sometimes the module parameters have not been assigned following our default procedure. Whenever we apply aging, the module parameters have to be recomputed (this time we use adapt the parameters automatically), which may lead to some discrepancies. It should be good practice to check all module parameters beforehand. https://www.pvsyst.com/help/pvmodule_parameters.htm https://www.pvsyst.com/help/pvmodule_rserie_rshunt_determ.htm You especially want to look at the page:

Thanks @dtarin @Nader Shaheen, regarding the white roof additional generation potential, you should define a higher albedo in your bifacial model definitions ("bifacial" button in the system window, appears once bifacial modules are selected). Themal parameters won't change between bifacial and monofacial, you can use the presets to fit your case. For module quality you usually don't need to do anything but leave the default, unless you are using degraded modules. Finally ohmic losses just depends on your cabling. A more visual way is by defining cable lengths in the "detailed computation".

Hi @ayoub96, no you are not missing details I think. Can you give some sample of your values and sums ?

Hi can you give some examples on the differences you find ? Indeed you may be in a situation that has almost the same angles and therefore leads to slightly different results. The PhiAng is the angle used for the whole time step, so in principle both results should match. Some other geometry factors may be at play: do you have exactly the same geometry of the tables ? (Module spacing, frames, etc) and are you using the same shading calculation ? Finally, the diffuse shadings for trackers are done a bit differently, so comparing values after the shading loss may not lead to the same results, albeit the results should be close.

Dear Nicolas, Your understanding is correct. The results at the end of the simulation are for the whole system. No at the moment, is not possible to get results for each orientation as a single simulation output.

There may be a bug indeed. You can send us your project (export it via the main window > File > Export projects) for review. You can also try the following: within the 3D scene there is Tools > Orientation management, which can allow you to assign tables to a specific orientation.