Michele Oliosi

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.

The simulation models both the location and the temperature, provided you have parametrized these properly. If the inverter malfunctions, you could also derate the inverter in PVsyst. Moreover, it is important to import the historical weather data corresponding to the monitoring period. Can you confirm whether you are using the corresponding time series for your simulation? If you are using a compatible time series as input for the simulation, it is then worth to compare the measured and simulated time series to understand whether the discrepancy correlates with any factor. Usually comparing the yearly PR and measured PR is not very telling per se. I think you should use the standard PR. However, it depends on how you are calculating the PR for the measured performance data. You should match the definitions of simulated an measured PR.

Summarizing what we found with the data: the diffuse was not the same depending on the time granularity. This is likely a problem that the weather data provider should address. In PVsyst if the diffuse data is different, then the simulation results will be different.

It is not in our most urgent priorities, but it is in our roadmap. Indeed, it would make the reverse transposition when importing POA data more reliable. However, to our knowledge, it does not address the bias inherent to applying the Perez model to sub-hourly data.