Michele Oliosi

No the tracker angles are the same. The interpolation profile is only a profile Shading factor = f(tracker angle). Therefore the only changes are in shading factors (for diffuse and albedo).

Hi the reason is in the calculation of diffuse and albedo shadings. For more information you can see here: https://www.pvsyst.com/help/project-design/shadings/calculation-and-model/diffuse-losses-with-tracking-systems.html This calculation creates an interpolation profile based on the available tracker positions. By changing the tracker limit, the support pointss of the interpolation profile are shifted, thus leading to (in principle slightly) different shading values.

Dear @PranavK, this is new to us and unfortunately I cannot say much without looking at the project. Can you send it over at support@pvsyst.com ?

Indeed, to model the front side irradiance (useful for monofacial) the height above ground is not used. There is therefore no problem in your comparison, even if you cannot enter the height above ground. One table = one module in your example. Therefore collector band width = 2382mm when in portrait and 1134mm when in landscape. If you check among all inverter manufacturers, there should be at least a few microinverters. However you can also define a new microinverter on your own, by modifying an existing one. You can therefore make a very low power one.

You can set up the module layout tool in one of your projects for a sample visualization in a concrete case. The impact of inverter limits is displayed and is similar to the simulation so it will help understand. Other than that there are some explanations in our help, for example: https://www.pvsyst.com/help/physical-models-used/grid-inverter/inverter-operating-limits.html However, there is no visual representation of what actually happens during a simulation. You could check the output variables IArray and UArray though. Together these represent the DC array's operating point.

You are correct about width / length, although a shed may be several modules tall... this means that the collector band width could be 2, 3 or more times the size of a module. About your system: the best way to model this in PVsyst is not via the "unlimited sheds" orientation. The unlimited sheds is useful when you have multiple rows of tables. Instead, your system is basically one table (with a gap). As far as the front side irradiance goes, the best is to do a 3D drawing and use the module layout shading calculation mode. Unfortunately PVsyst does not model the backside irradiance in 3D, which means that in your case the backside irradiance model (bifacial model) would be quite wrong. Indeed, there are multiple 3D specificities in your system: the raised part of the roof, the gap in the modules, the different albedo, and the mounting structure. All of these cannot be modeled in PVsyst. You could use the unlimited sheds as an approximation. In this case, please set the number of rows to 1, and the collector band width to 5 times the length of a module (+ gaps). The hole in the middle and differences in roof height cannot be modeled. Then you can use the bifacial model, but note that the results will be approximative.

@AHSAN ALI An important point here is understanding what "shed" means. A "shed" in PVsyst is one row of PV tables in a row arrangement. A "shed" is not the same as a module: Because one table may have several PV modules. Because one row of tables has several tables in it. In the diagram of the "Orientation" window, you can see three (generally) such rows depicted in blue. This is a cross-section or side view of the row arrangement. This also means that the size of the tables is what you will enter in the parameters "coll. band width" and "top/bottom inactive bands". What matters is the vertical size, in other words the "height" or "width" depending on your perspective, but usually the short side of a table. The "Orientation" window is not where you will define the total number of modules. Here only the geometry matters. The "System" window is where you will define the number of modules properly. In your example with 8 + 8 modules, you should define "Nb. of sheds" as 2.

Hi, PVsyst will use the operating range to displace the operating point on the IV curve. This displacement away from the MPP will cause losses, captured in the variables IL_..., e.g. IL_Vmax for the maximum voltage. The parameters here are the Vmax and Vmin parameters. Note that a different yet related loss, the derate at very high or low voltage levels (or more generally as a function of voltage), is not captured by PVsyst. We do only model a voltage dependence by means of three caracteristic efficiency curves based on three ordinary voltage points. However this may not capture the full voltage derating curve.

@sauld no you are right, there could be some losses that would be missed by this approximation. Unfortunately this is a compromise, because currently MPPTs can only receive identical strings in the System definition in PVsyst. However for most cases these losses are rather small. The most important is the string to string mismatch (usually shading effects are even smaller because you need a very specific shading pattern for the multi-MPPT to help). You could add an estimate of these losses to the mismatch losses manually. You can estimate them using a tool found from Home window > Tools. There is a similar discussion here (see the last answer by my colleague Luca):

Unfortunately, it is not possible to put two different types of string on the same MPPT in PVsyst. You must either approximate the module rated power so that the MPPT are homogeneous, or you should redefine the inverter as having 6 MPPT, although this could somewhat affect the inverter losses.

No currently only a partial selection of variables can be added as monthly tables. However EUseful is actually a composite variable, it is equal to other variables depending on the case. For example, here it should be equal to "Energy from the sun".

For most practical purposes, this is already available in the latest 8.0 version. Indeed, PVsystCLI has been made compatible with batch files. In other words, you can call a batch of simulations from PVsystCLI using a batch parameters file. You can find some more details on this page: https://www.pvsyst.com/help-cli/reference/index.html#run-simulation The command that you should look at is --batch-params-file

@Yvano I see. Thanks for the clarification. Indeed, as mentioned by @André Mermoud the only way currently is to use the automatic attribution instead of the manual one to reach these overlapping modules. I will record this issue for future improvements.

Hi please make a new post in English or translate this one (including the title). Following the language rule will allow us to help more efficiently and also help other users 🙂

Hi @James Barry Thank you for the feedback. This comes in very timeline as we are currently assessing models for the decomposition of irradiance from GHI for minute data. We are aware that diffuse fraction models such as Erbs can be biased when applied on sub-hourly scales. Providing an alternative to Erbs is thus a necessity.