Michele Oliosi

This is not possible currently (not possible to have trackers and fixed in the same simulation in version 7). I would advise running both variants without grid limitation. You can define an output file (https://www.pvsyst.com/help/output_file.htm) for each of them. Then combine the output powers for each simulation step. You can then apply a grid limitation in another tool, e.g. in excel.

The shadings seem really negligible, because even on 21st of December (worst case), you have only 7.5% electrical loss. You mention, “the lowest production should control the current and constrain the specified production”, this is not necessarily true, thanks to bypass diodes. I think in this case, the bypass diodes are mitigating part of your electrical shading losses. The blue message in the module layout tool is a bit misleading. What it should mean is that you can optionally review the shadings at specific days in the year (assuming clear sky conditions) using the “Shadings 3D” tool. This tool is however just for review. What matters in the end is validating the module layout assignations (you don't need to go to the “Shadings 3D” tab at all if you do not want to review), and running a simulation. You can check that shadings have been computed according to module layout definitions in the simulation report.

Hi ! Except notably for irradiance transposition (by orientation) backside irradiance modeling (one bifacial model for the whole system in v7), and shadings if not using the module layout, (e.g., if “according to strings” or “linear” the shadings are calculated by orientation) the calculation is mostly done separately, sub-array by sub-array. I will try to summarize this as a table: Mixing / Model Note 3D scene without Module layout 3D scene with Module layout modules of different ratings, same manufacturer and series Defined as different sub-arrays OK, but shadings are averaged over all modules in the same orientation OK modules from different manufacturers, but same physical size Defined as different sub-arrays OK*, but shadings are averaged over all modules in the same orientation *Bifaciality: not ok if rackings are not the same size OK* *Bifaciality: not ok if rackings are not the same size modules from different manufacturers, different sizes Defined as different sub-arrays OK, but shadings are averaged over all modules in the same orientation OK multiple racking configurations, e.g., 1P and 2P OK* *Bifaciality: not ok if rackings are not the same size OK* *Bifaciality: not ok if rackings are not the same size fixed tilt and SAT racking Not possible currently (→ v8) bifacial modules with different bifaciality factors Defined as different sub-arrays. Bifaciality factor is averaged between sub-arrays following an average weighted by DC nominal powers. No particular issue with shadings since these do not impact backside irradiance modeling currently No particular issue with shadings since these do not impact backside irradiance modeling currently bifacial and monofacial modules Not possible, unless bifacial model is deactivated bifacial and monofacial modules, where we trick PVsyst by editing the monofacial module PAN to make it bifacial with a bifaciality factor of 0 Defined as different sub-arrays. Bifaciality factor is averaged between sub-arrays following an average weighted by DC nominal powers. No particular issue with shadings since these do not impact backside irradiance modeling currently No particular issue with shadings since these do not impact backside irradiance modeling currently

I should also add, that when you combine sub-arrays with different bifaciality factors, we use a weighted average (based on nominal DC power) to compute an average “bifaciality factor” for the whole system.

Hi @laurahin, the transposition calculation is lumped together *if* the orientation is the same. From there onwards, however, the calculations are done independently per sub-array. This is because most parameters are defined on a sub-array basis. The most notable exception is the bifacial modeling, which is defined globally for the whole system. If two sub-arrays have different bifaciality factors, PVsyst will define an “average” bifaciality factor, by weighing by the respective DC nominal powers. In general this works well, but can be incorrect if one sub-array has very different irradiance conditions (or IAM factors for example) than the other, by which the weighing based on DC nominal powers is not really correct. A second exception is shadings, which is done orientation by orientation (which may therefore lump together multiple sub-arrays), if you are using the “according to strings” aka partition model. If you use the “module layout” model, then we are accounting for the sub-array differences in shadings as well.

In version 7, you should always do separate variants for fixed and tracker. We would like to publish version 8 during the first half of next year, but this is still uncertain, and we cannot yet give a more precise release window, unfortunately.

The calculation of the normalized production and losses is based on monofacial systems. Indeed, for some bifacial systems, and in particular vertical bifacial which have a large bifacial yield, the effective irradiance is higher than the front-side incident irradiance. In the diagram or in the array losses label, you therefore get negative values. The diagram does not really work in this case, actually. The results are however correct, it's just the definition of array losses which is not adapted.

I agree with Eduardo, here the problem is tables which are differently-sized. If their “width” (how tall they are) is different, PVsyst will not be able to run the simulation no matter what. This will be possible in v8, but not before (should be ready sometime next year).

The calculation of the normalized production and losses is based on monofacial systems. Indeed, for some bifacial systems, and in particular vertical bifacial which have a large bifacial yield, the effective irradiance is higher than the front-side incident irradiance. In the diagram or in the array losses label, you therefore get negative values. The diagram does not really work in this case, actually. The results are however correct, it's just the definition of array losses which is not adapted.

Hello, Although this page (https://www.pvsyst.com/help/meteo_import_nrel_nsrdb_viewer.htm) needs an update because the interface has changed, the basic steps are still correct, i.e., you should use the option “Convert UTC to local time”. Your file is in UT, so it cannot be imported with the PVsyst “Known format” mode. You have three choices : redownload the data with “Convert UTC to local time”, use the “Custom file” option instead, or convert the file to the PVsyst standard file format. As stated in the help, https://www.pvsyst.com/help/meteo_pvsyst_standard_format.htm you should use the tag: “#Time reference, UT” to specify that the data is in UTC.

Indeed, this seems like an unwanted regression. I will file a ticket about this.

This seems alright. There is no apparent reason here for GlobHor to be reduced. Can you check the MET file via this interface ? Database > Meteo tables and graphs

Unfortunately it is not present yet, I will add a ticket in our roadmap. In the meantime, I would suggest computing with the yearly energy injected into the grid, by dividing it by the DC nominal power.

Hi, You should use the module layout tool (detailed electrical shading calculation), which will estimate the electrical shading losses by adding the IV curves of each submodule. In such a way, you will be defining all these 3D scene modules by their string and inverter attribution.

Hi, which import mode are you using: known format or custom file? In the custom file case, make sure that the units are correct. Can you copy a snippet (a few lines) of your file?

Glad to be helpful !

Hi, NASA SSE in PVsyst is ancient data and I especially wouldn't rely on its wind speed data, probably it is zero as a placeholder for no data. They have had an update recently, I think, but we haven't updated on our side yet.

Indeed, PVsyst doesn't really treat the ground collision. It will be up to you to define the tracking range so that it doesn't hit the ground. I think all simulations steps in which the trackers are “below ground” cannot be trusted, although in appearance the results do not seem too bad.

It depends on whether you have chosen the “fast” mode or the “slow” mode. In the fast mode, the interpolation is used in the simulation. In the slow mode, the interpolation is shown in the iso-shading graph, but the simulation does the calculation properly with the 3D scene. It is a shading factor for albedo, i.e., it is applied to the albedo irradiance contribution to the front-side of the modules. This is why it is not weighted per energy, but is just a geometric factor.

Hi, I see, thanks for checking this. We would need to see the file to find out what is going on. Can you send us the source file over at support@pvsyst.com ? We will have a look asap.

Hi, yes, with caveats. Your trackers should all have the same nominal orientation, but they can follow the terrain. An error regarding discrepancies in the orientations may still be shown, but this can be bypassed by changing some tolerances in the advanced parameters. As a result, the reference orientation will be the average of all tracker orientations. There used to be a limit in the tracker axis orientation RMS deviation from the average to apply the backtracking. This is now mostly gone. However, the backtracking algorithm still moves all trackers similarly, according to the simplest backtracking on flat ground specifications. We do not yet handle independent trackers.

Not really, but you can also choose to ignore these gaps. In some situations, they do not really affect the shadings much.

Ok, so the difference occurs before the evaluation of EArray. My following hypothesis about what is happening is: The electrical shading factor table is changing from one simulation to the other. You can check whether this is the cause for the difference by switching to “linear shadings” and see if the difference persists. The fact that the table changes can be due to 2 different reasons: Since you are changing the pitch, the 3D scene is changed. This means that the shading factor table is recalculated. You should check that the backtracking works as intended. If you have perfectly flat ground, there should not be any electrical shadings, so you can output the variable ShdElec and check whether it is zero. The shading factor table of your variant has been calculated in a previous PVsyst version. In this case, the batch mode will make sure it is recalculated with the latest version. You can make sure this doesn't happen by viewing the Table in Near Shadings and clicking on “Recompute”.

Hi ! Currently, only the torque tube gap can be included in the tracker design. If the motor / pile gap is significant, I would suggest splitting the tracker into several trackers, with the size between the gaps as their individual size.

Ok, we will need to dig deeper. How about other quantities, such as EArray? In the report you find the yearly value in the table. You can also output this variable from the batch.