André Mermoud

The optimizer is basicaaly a DC:DC converter, which can increase the current of the source (PV module) by diminishing the voltage. It may deliver "any" current, independently of the source current.

Your inverter is defined with a PNom expressed in kVA, i.e. in apparent power. Therefore if you have defined, as an example, a Cos(phi) = 0.95, the active power corresponding to the apparent power (77 MW) = 77 MW * cosPhi = 73.15 MW. This is the effective clipping PNom value. Otherwise, if you have several subarrays with different orientations, the PNom total may never be attained, as the PNom on one orientation is not at the same time as the PNom on the other orientation. See the help "Project design > Grid-connected system definition > Power Factor"

With SolarEdge, the strings at the input of the inverter may be distributed in different subarrays. Therefore you can define several subarrays, with different orientations, as suggested by the error message. What you cannot do in PVsyst is to mix modules of different orientations in a same string. Although it is possible with SolarEdge optimizers, PVsyst doesn't manage this case.

We have deeply reviewed the treatment of the Grid limitation in the version 7.3.2. The result is now more correct for some special configurations. However there is indeed a bug when calculating the repartition between the inverter’s loss and the loss due to grid limitation in some particular cases. The loss due to the grid limit is fully reported on the inverter’s overload loss. This corresponds to the situation when you uncheck the case “account as separate loss”. However, this doesn’t affect the global loss, the final yield E_Grid is correct. We have corrected this balance between losses in the latest version 7.3.3. NB: you have indeed a little difference bwtween V 7.3.2 and 7.2.21 (-0.08% ! ). As I wrote previously, the calculation was not quite correct before V 7.3.2, this was the reason of the update.

Yes PVsyst applies the definition of the PR (corrected) as it is defined in the help. Now I don't know how you have done your calculation. This requires to be executed hour by hour (see the item "sum over hours").

Sorry, these colors were chosen for an exposition as clear as possible of the layout. We don't want to modify them. For the strings grouping: when in your subarray you define a number of strings not divisible by the number of MPPTs, PVsyst will distribute the strings on the MPPT inputs, in an alternative way. Here the first MPPT has one string and the secnd MPPT has 2 strings, etc. Now if you want to put th string #3 on the first MPPT and the strings #1 and #2 on the second MPPT, you should do that manually with the right-click of the mouse. NB: If you want to split all strings you can manually fill the MPPT#1 with another string, and then apply the automatic filling, which should (hopefully) begin at the MPPT#2.

One of your strings is 550W * 22 = 12.1 kW. One inverter input allows 100 kW / 10 = 10 kW "nominal". Therefore putting 2 strings on one MPPT input leads to a PNom ratio = 2.42. which is not reasonable. In a multi-MPPT inverter like this one, you can indeed charge a MPPT more than the other ones (i.e. define some MPPT inputs with 1 string, and some MPPT with 2 strings). But not with such an individual PNom ratio (as dtarin said, 1.5 or a bit more). However if the difference is too high: this will probably not be allowed by the manufacturer, and you will have high current losses in the more charged MPPT. See the help "Project design > Grid-connected system definition > Multi-MPPT inverters > String inverters, current limiting"

If SolarGIS uses the Perez model, it should have the same accuracy as PVsyst id the input data (Ghi and Dhi) are the same. Now you should be aware that the transposition model highly depends on the diffuse component. I don't know what is the diffuse model used by SolarGIS, but if you want to do a close comparison you should use the same input data (Ghi and Dhi) in hourly values. In PVsyst, the horizon shading is taken into account before applying the transposition. Then the GlobInc (POA) is evaluated without any other perturbations. The 3D irradiance models (shadings, IAM, etc) are applied on the GlobInc, DiffInc and AlbInc issued from the transposition.

This tool in PVsyst is indeed a new feature, which tries to guess the cell sizes from available information like Sizes of the module, possible standard sizes of the cells, submodule partition, number of cells in series, etc. Now your module is not quite standard. It has 4 cells in the width, therefore 2 x submodules. Therefore the number of diodes should be 2. The configuration should be "In length" if you have indeed 72 cells in series (Vmpp around 40V), or "Twin Half-cut cells" if this has 2 x 36 cells (Vmpp around 20V) However this rather special configuration is not well treated in the present time. We will improve this in a next version.

Please explain in detail what you name "E-Battery service". In PVsyst, you can define a "Universal" battery with any specified voltage and capacity. This will have a "reasonable" average behaviour. I don't see why you are minimizing the losses. These are the reality of a system. Now when using a battery in a PV system, this is usually for charge/discharge cycles of the order of one or very few days. Therefore on a yearly simulation, the initial state doesn't have a significant influence. However you can specify the initial charge state in the advanced parameters, topic "Batteries", item "Initial SOC for the simulation".

Yes sorry. Yes, sorry. There is indeed an important bug in the version 7.3.1. When using the irradiance optimization option for trackers, the phi angles are not calculated correctly. A workaround is to revert to the usual “astronomic” calculation, which will probably be more compatible with your actual control system on the field. In the “Orientation” dialog, you should uncheck the option: This usually gives a difference inferior to 1% This issue has been fixed and the correction will be made available in the version 7.3.2.

I don't know. We have never been contacted about this error. Please send us (support@pvsyst.com) the whole project, using "Files > Export projects" in th main menu, and explain the exact way of getting this problem.

There are several ways of defining rates. PVsyst doesn't display all of them explicitly. On the loss diagram (or main results table), you have the basic results: - E_User = total user's needs - E_Solar = energy provided to the user from Solar - E_Grid = energy rinjected in the grid. PVsyst define the "Solar Fraction" = E_Solar / E_User. This corresponds probably to your "Self-production" rate.

During the simulation, there are two steps: - Define the array (cell) temperature during the simulation, according to the external conditions (Ambient temperature and Irradiance, possibly wind velocity) - Use this temperature as input for the one-diode model. For the temperature of the array, there is a model described in the help "Project design > Array and system losses > Array Thermal losses". This is based on a parameter U (heat loss coefficient) or Uc ans Uv when wind velocity is involved. For the one diode model, increasing the cell temperature will diminish the voltage and the power (about -0.35%/°C for crystalline modules).

The ohmic fraction is defined as a percentage of a "Reference Power". Here the reference power is the STC power, but it could be any other power (the ohmic fraction will be proportional to this reference power). However this Ohmic loss specified as a percentage is not the basic data. The basic data is the resistance of the wires, derived from this Loss fraction. The resistance is the same whatever the reference power chosen. This is fully explained in the Help "Project design > Array and system losses > AC ohmic loss from inverter to injection point".

The grid limitation is meant for big systems. Defining a value less than 1 kW doesn't make sense in practice. For the unavailability of the "Simulation" button when the message sais "Ready for simulation", it is indeed not normal. However this only arises when you define a grid limitation, and the Grid limit power is set to 0. We will correct this in a next version.

These values in the hidden parameters ("Low/High Grid Power limitation Power Ratio") are only used for the verification of your definitions (warning messages). The PNom ratio mentioned on the dialog is the ratio of your grid limitation specification, and the PV installed power. It is shown just for information.

The C1, C2, C05 values are battery definition parameters. These have nothing to do with the results you are waiting for. Here you have defined a charging power of 6.25 MW, for a battery pack of 27 MWh. This will indeed fill the batterty pack in about 4 hours if the PV system provides a sufficient Power for that. Which will probably be the case rather early in the morning, since your PV systerm has a nominal power of 52 MWp, i.e. almost 8 times the charging power !

The C10 is the basic definition of a battery in PVsyst. This reference cannot be changed. You can have the correspondance with other Cxx values in the battery definition dialog: here a battery defined with a C2 capacity of 105 Ah will have an effective C10 capacity of 108.4 Ah. This is the value defining this battery within PVsyst. Now when using it, the simulation will permanently re-evaluate the capacity as a function of the Charging/Discharging rate along the simulation.

The irradiance on the tilted plane is computed using the transposition model (Hay or Perez), as described in the help. This strongly depends on the beam component (i.e. the diffuse). Now when the GlobHor is modified, usually the diffuse is also affected (a higher GlobHor means a higher beam, therefore o lower diffuse fraction). This will affect the ration GlobInc/GlobHor.

The shadings calculation "According to strings" is applied to an array connected to one MPPT. With optimizers, the MPPT input is one (or possibly 2) modules. Therefore each rectangle should represent the set of modules connected to one optimizer. NB: The ModuleLayout option is also useable for the calculation of the electrical shading loss with optimizers.

There is no way in the present time for explicitly defining the tracker's position. Providing such a possibility (i.e. defining the tracker's position by an external file) is on our roadmap, but will not be realized before several months.

The simulation works exacly in this way: the individual inverter limitations are applied first. And if the grid limit imposes an additional restriction, it will be accounted as "Unused loss" in the loss diagram (provided that you have specified "Accounted as separated loss" in the grid limiting dialog). If you uncheck "Accounted as separated loss", all the losses will be accounted as inverter losses.

Yes, these are two different bugs. We will correct this for a next version, but I don't know when. NB: There is indeed no way of modifying the number of cycles within PVsyst in th present time. The only possibility is to directly edit the *.BTR file, for example in Notepad, and modify the parameters at the end of the file:

Yes indeed. providing an hourly definition of the Grid limitation is on our roadmap. However I don't know when we will be able to develop this feature.