Michele Oliosi

After analyzing your project, I have found that most of the sub-arrays in your system are in an erroneous state, i.e., they do not have the “power-sharing” flag activated. This may happen, for example, if you defined the “power-sharing” once but then switched to not using the multi-MPPT feature at some point. An easy way to correct the state of all sub-arrays is to go to the “power-sharing” window, and click twice on the power-sharing checkbox to deactivate and reactivate it. This will reset the flag for all concerned sub-arrays. On our side, we will try to fix the program to make sure that these situations do not happen anymore.

This is the loss on one day (the selected day). No, the shading factor table represents the loss for a particular sun direction. There is no temporality involved. It cannot be easily converted, you need to run the simulation to convert it to a yearly loss. It is the solar azimuth angle (negative for east, zero towards south).

Electrical shading losses are the total losses due to shadings. Beam linear loss is the loss of irradiance due to shading the beam irradiance. This latter is accounted in the "electrical" loss.

This error message was meant to be present in the previous versions of PVsyst but a bug prevented it from appearing. This has been fixed in the latest version of PVsyst, that’s why you see the error message now. To get rid of the error message, you can go to the advanced parameters, search for “spread” and modify the following value: I hope this helps. Note that cases which have a very large tilt spread may induce a certain uncertainty in the transposition calculation.

Regarding the “Lower temperature for absolute voltage limit”, since this is a safety condition, we make the hypothesis that the cell temperature is the ambient temperature (which corresponds to the highest possible voltage). It is customary to put the lowest possible ambient temperature over several years. The other temperatures are usually not very constraining, so it is okay to put a rough estimate there.

At some point, yes. But it is not too hard to correct the error in the current version. Instead of using the mixed orientation, you can define two subarrays with one MPPT and one string each. Then you can combine them in the string configuration, I think.

Hi, and happy new year as well ! This is a missing feature with our Huawei optimizer string configuration interface. At the moment, it is not compatible with the mixed orientation feature. Without optimizer, this would work. I will file a ticket for this missing feature.

Hello, Are you running the latest version of PVsyst ? If yes, if you can send your project at support@pvsyst.com, that would greatly help us in figuring out the issue or bug. Thanks in advance

Hello, No, at the moment it is not possible to have two bifacial orientations. This will only be possible in version 8, to be released at some point (in principle in the first half of) this year. The annual yield will not change much if you use only one orientation, though, unless you are overloading your inverters. However, the hourly distribution will change, of course.

Hi, Unfortunately, at the moment, PVsyst doesn't handle well (in terms of backside irradiance) situations without a pitch. However, there are some workarounds for this issue. You can either: Use the “unlimited sheds” orientation, and define a large (e.g., 50m) value for the pitch. Keep the 3D scene, but duplicate all objects. Then you can place the copied objects far away to the east or west. This artificially generates a large value for the pitch — a situation in which the number of “rows” doesn't matter anymore. PVsyst may then throw a warning regarding the mismatch between 3D scene PV area and System PV area. This warning can be bypass via the main window > Settings > Edit advanced parameters, with the following parameters:

Hi, we actually checked, and it is not a regression but rather a case we didn't account for, sorry about that. You probably have single fixed tables defined in your 3D scene ? In that case indeed the functionality is missing (and always had)… We will correct this in the future. If you have trackers, or (the PVsyst PV object that is named) arrays of tables, then it should work.

The module layout view is a rough representation of your 3D layout. The fact that row#1 col#1 is below the others is just to avoid overlaps, it has no impact on the simulation. What counts is the 3D view.

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.