André Mermoud

I don't understand well what you mean. If the unavailability concerns a failure of the PV system, you should define it in "Detailed losses > Unavailability". Here you define periods fo which your system will not provide any energy. If this concerns the use of the electricity, you can define a load profile with some periods without any consumption.

This is indeed not implemented in PVsyst in the present time. Now if this is just for the back-up of "possible" breakdowns of the grid in the "self-consumption" option, the yearly energetic impact will not be important as these failure events are supposed to be rather rare. The effect will be that you may have au unwanted component "Missing energy" in the final loss diagram. Implementing such a feature would require to define an additional parameter set, describing the Grid aunavailibility periods. If this is to be used with the "weak grid" option, it could indeed be very interesting to provide a detailed tool for that. We will consider this in our roadmap.

The one-diode model (Shockley equation) cannot be applied when the Vmp/Voc ratio is too high (greater than about 84%). This is a limitation due to the diode exponential shape. In PVsyst we consider that the Voc is not important (not significant during the simulation). Therefore we have sometimes to increase the Voc value at STC for applying the model. This is especially the case for the STC data of new technologies, like TopCON. Therefore you should slightly increase the Voc value, until reaching a reasonable RsMax allowing to define a low-light efficiency of -3% @ 200 W/m2. NB: We don’t know whether the specified values are quite compliant with the measurements. In the past we have observed with several manufacturers, that the Vmp/Voc specified values on the datasheets were significantly higher than the measurements reports they sometimes provide for the same modules, elaborated by independent laboratories acc. to IEC 61853.

The simulation is considered as P50 when it is based on average meteo data (synthetic generation from averaged monthly data), or typical meteological year data (TMY). Creating a simulation corresponding to P90 doesn’t make much sense. What would be the use of such a simulation results, when the P90 statistical approach only concerns the yearly result? You cannot say that each month has P90 monthly results, as the variability of monthly results is obviously much higher than the annual variability. Therefore you cannot compare the monthly values with the measured ones on a real system (this is also true for the P50). Performing such a simulation would need to avail of a Meteo data file representing P90 weather data. Some Meteo data providers may elaborate such files, but we have some doubts about the validity of tis methodology. Please carefully read the Help “Project design > P50 - P90 evaluations” for understanding the deep meaning of such statistical evaluation, based on the annual variability of the meteo conditions.

Basically, there is no parameter for that in the Bifacial model of PVsyst. Now depending whether the modules of the 2-3 "rows" belong to a same string or not, the mismatch in the width of the table may be a little bit different. However we don't have any calculations for this evaluation yet.

I don't know. Please check that your inverter is not defined with an increased Pnom when the temperature is low (page "Output parameters" of the inverter's dialog).

No, each optimizer has a maximum output current parameter. You have the following output curve (this inverter is defined with a max. output current of 15A). NB: this curbe is part of the Optimizer definition dialog. However sorry, there is a bug in the versions 7.2 and 7.3, the maximum current is not applied correcly. This will be corrected in the next version 7.4.

I don't understand well your problem. If each subarray is connected to a power station including the inverter, the ohmic losses should be accounted as "AC losses after the inverter" (in the dialog "Detailed Losses > Ohmic losses"). In this case you should evaluate an equivalent resistance of the wires between the output of each substation and the injection point.

Why not over Isc ??? The optimizer operates at the Maximum power point of the module. This is completely independent on the Isc. The optimizer is a DC-DC converter, i.e. an electronic device which is able to transform any voltage signal into another voltage, by keeping the available power, i.e. Iout = Pout / Vout. The maximum available current is a property of the optimizer. See the behaviour of the optimizer in the software (open the dialog of the concerned optimizer, and look at the page "Output I/V behaviour").

There is no general solution to your problem. It depends on your layout, your geometrical constraints, the number of half tables to be defined, etc. A solution would be to define 2 different half-tables kinds: some with 14 modules, and some with 15 modules. Another solution would be to define strings of 28 modules for the half-tables (these should be defined in another subarray, and connected to different MPPT inputs).

You are referencing a document which I have written 18 years ago, which was the final report of my first experiments about the PV module modelling. Things have obviously evolved since this date, and the criteria for choosing the Rserie has been highly refined. We have recognized since over 12 years that the Rserie is related to the low-light efficiency, and this is now the basis for defining this value if we avail of "official" measured data. In absence of such data, PVsyst chooses a reasonable default value corresponding to a low-light relative efficiency of -3% @ 200 W/m2. However the way of defining RSMax has not changed: it is still the limit Rserie value which allows to solve the 3 equations at ((0,Isc), (Vmp, Imp), (Voc, 0) at STc when fixing Rshunt. We don't propose an explicit equation for that. The model and its "modern" declinations is fully described in the help of PVsyst "Physical models used > "Standard one-diode-model" NB: In your plot for Rserie = 0.5 ohm, I don't know how you have determined the values of IoRef, IphRef, and diode ideality factor. These are obviously not correct as your curve doesn't match the voltage condition at the (Voc, 0) specified point.

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).