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.

Yes this is what I meant ! However, the differences seem to be small, I do not think they would account for the transposition difference. Another possibility that could exacerbate the effect of small GHI differences could be if DHI was not included in the file or not used at import ? Is there a chance you could send the weather data files (MET) or the raw data over to support@pvsyst.com? This would make the analysis a bit simpler.

Glad to help ! I see, however I still fail to see the purpose of this request, sorry. If the inverter clips at a given time, this means that at that time the PV production reaches the clipping threshold at that time. If you model the PV production based on the measured data (not from a TMY), the clipping time should at least roughly correspond to the reality. Same thing with the module temperature, if you were to model using the real historical weather data, the temperature of the modules, measured and simulated, should at least roughly match. Let us know if I missed something about your intentions with the simulation.

Dear JStief, This is puzzling, especially because PVsyst will average data to 1-hour steps anyway, meaning that the modeling should be identical. The first thing that springs to mind is that the 1-min, 5-min, and 60-min files are not simply related by averaging. In other words, if you average the 1-minute data, you won't obtain the 60-min data. Is there a chance to check that ?

Hi, these two factors are directly related to the components in your system as well as the weather. Directly setting a clipping time or a maximum module temperature would be unrealistic, and is not possible in PVsyst. Instead, you can consider changing the components such as changing inverter model or PV module, or also changing the system layout.

Assuming that the statistics of the yield of a PVsyst are only influenced by the climate, as a first approximation, the PR will not change. This is because as a first approximation, the yield is proportional to the average irradiance (from which the climate variability is taken). However, at second order there will be other effects, that are too complicated to track down. Indeed, there is no definite definition of a P90 year useable for a simulation, only the statistical meaning that the yield should be better 90% of the times. I.e. you cannot exactly pinpoint whether this or that combination of entries in the time series has led to the reduction of the yield. However, since the very definition of P90 production also assumes a linear relation between irradiance and yield, it should be okay to consider the PR as constant.

Hi, this is strange. NS axis trackers (whether 3D scene or using the “unlimited trackers” optimization) should work without issue. Can you send your project (use the export button in the project window to generate a zip archive with all necessary files) over to support@pvsyst.com ? Or share a snapshot of the disposition of your 3D scene. This will allow us to look into it further.

Indeed, I confirm that this is the case and is quite misleading… and also not consistent with how PVsyst usually works. You should not be able to keep the spectral correction checked if it cannot be used for some reason. Thanks for this feedback @LauraH

It depends on the layout of the strings in the field. We don't have a rule of thumb, but you could do something along these lines: you can make some simple assumptions concerning your field. For example, if your trackers are 2P (two in portrait), then you could assume that there are two strings per tracker, i.e. 1529 strings total. Then you could also assume that the trackers are roughly arranged in a square terrain, with GCR 0.4. And that modules are 1x2 m^2. Let's say x is the number of trackers on a single line along the axis and y is the number of rows. Roughly, y * 2 (# modules in table height) * 2m (module height) / 0.4 (GCR) = 24 (# modules in table length) * x * 1m (module width), i.e., y = 2.4 x. The total number of trackers is 1529 = y * x = 2.4 * x^2. Solving, that you get roughly x ~ 25 and y ~ 60. So 60 rows should be roughly it. Note that above 10-20 rows, the impact of the number of rows becomes quite small, so for systems of this size the exact values are not important at all.

We have calibrated the number of partitions based on the module layout calculation. Therefore, all these effects are taken into account in the partition model. The partition model per se is an approximation that will not always reflect the details of the electrical effect of partial shadings, but that should recover a plausible loss value for a long term (e.g. a year) simulation. However, for the case of the 2x14 structure, it should not be a partition that traces through the middle of the modules. That would be correct for the case 2T. Instead, this 2x14 structure is in the case 2TU, which has two partitions with size 1x14.

Hi ! Which version are you using? I am asking this because in the current version this is not stated, as far as I know. The unlimited orientations do always include mutual shadings. The shadings calculation is inherent and is not related to choices in the "Near shadings" window. The number of rows (with the frenchism "sheds") is actually quite important for the evaluation of mutual shadings: it does affect simulation results.