André Mermoud

These parameters are basic specifications of each PV module. You can change them within the PV module (using the PV module definition dialog). Then you have to save this PV module as a new PAN file for using it in your simulations.

When defining the AC losses, the loss percentage is proportional to a specified reference power. Now this reference power may be either the POut(AC) when the system is working at STC, or the maximum output power PNom of the inverters. This choice may be done in the project's parameters. See the Help https://www.pvsyst.com/help/ac_ohmic_losses_ref_power.htm In your case, the "STC: Pac = 339 kW" means that the reference power has been chosen as the Pac when the system is running at STC (Nominal PV power = 346 kWp, multiplied by the inverter efficiency). NB: If you change this reference, the relative ohmic loss [%] will change, but not the absolute (real) energy loss in [kW]. NB: PVsyst proposes a cable section, but you may obviously modify this choice.

Please carefully read the help "Performance Ratio" https://www.pvsyst.com/help/performance_ratio.htm The PR corrected for the temperature is a very special evaluation, to help for the evaluation of the global annual PR from a little period data for in-site production assessments.

In your workspace \PVsyst7.0_Data\Templates\, you have an EXCEL document "Components.XLS". If not, you should use "Reload templates" in te Workspace dialog. Now in the PV module dialog you have a button "Copy to table". This will fill the clipboard for pasting the PAN file values in this document.

Although it is possible to connect strings of modules in different orientations when using optimizers, this possibility is not yet available in PVsyst in the present time. ,

The number means functional by-pass diode. This means the by-pass diodes determining a sub-module. Some manufacturers put 2 by-pass diodes in parallel for each submodule. This should be accounted as one only. I don't know any module configuration with more than 5 sub-modules. Please see the Help "Physical models used > PV Module - Standard one-diode-model > PVModule Structure > Submodules"

I had a look on your project. The problem is not linked to the grid limitation, nor the inverters nominal power. In your simulation there is already a limitation at the PV array output (EArrMPP), which never exceeds 289.78 kW. This limitation is due to the use of SolarEdge optimizers. The output current of the optimizers S440 WW is limited to15 A. With SolarEdge inverters, the input voltage is fixed, here 750 V for this inverter. Therefore a maximum power for one string = 750V * 15A = 11.25 kW. In your system, you have 26 strings, i.e. a max. power of 26 * 11.25 = 292.5 kW. After some losses (mismatch, wiring), there is 289.78 kW remaining at the output of the array. NB: You will retrieve this loss in the loss diagram "Current overload losses" One solution for avoiding this problem would be to limit the number of optimizers in each string.

We don't know any problem of this kind. Please send your project to support@pvsyst.com, by using "Files > Export project" in the main menu. And tell us exactly what you are doing for getting this problem.

The batterie LifePO4 are indeed Li-ion batteries ... Defining a new battery model in PVsyst is not easy, and you can do some erroneous definitions. If you don't find your battery model in the database, you can always use the "Universal" battery, for which you specify the Voltage and Capacity as you like. The "Universal battery" will adapt its parameters, and behaves in the same way as other LiFePo4 batteries of the database. NB: For batteries not present in the database, you can send the datasheets to support@pvsyst.com, and we will see for implementing it in the database of a next version.

Yes, it is quite possible to define your situation. When right-clicking on the inverter's list, you have the opportunity of adding an inverter. Then, click "Reinitialize" and "Adjust subarrays" and everything should be OK. NB: This possibility is mentioned in the help.

I had a look on this project. In the first simulation, there is indeed an error. The first shading factor table calculation was not correct, it did not take the Backtracking strategy into account. This sometimes arised with the versions up to V 7.2.17 (where this bug was corrected). You are indeed using a rather old version 7.2.14 (April 2022); you are advised to update to the latest version. For the next versions the table was re-calculated correctly, and leads to linear shading losses of the order of 0.75%. This loss is mainly due to the mutual shadings on the diffuse part. See the help “Project design > Shadings > Calculation and Model > Diffuse losses with tracking systems”. In usual cases this contribution is about 2 to 3%, because it also includes the shading loss on the project’s albedo component, which is completely invisible from the trackers in the field (100% loss). But in your case you have put the albedo = 0 in your project, so that this loss is not accounted here. However the final result is correct as the albedo contribution is also not taken into account in the transposition. NB: Your question A: for trackers, the mutual shading loss on diffuse is calculated in a specific part, independently of the simulation, and doesn’t take the option “No shadow casting” into account. This is the reason why it is apparent in the variant VCC. Question B: In the VCB, supposed to exclude the mutual shadings of trackers, this contribution is indeed calculated as explained above. Therefore the shadings of VCA and VCB should not be added. The contribution of the other objects (trees) is completely negligible in such a system. Question ? As explained the VC9 is erroneous. The recalculation updates the shading factor table and is correct.

I admit that this definition may be confusing. It has been established before the generalization of the maximum power possible increase according to the temperature. But it is a choice. The convention is to specify the nominal values, not the derated values. The maximum value, when used, is indeed mentioned on the report. And the PNom ratio in indeed an indicator, not a fundamental quantity. If we change the definition, other people will not be satisfied and there may be contradictions in other parts of the system interpretation. Moreover, if the inverter operates at high temperatures, what should be done ???

Please carefully check that your inverter is able to deliver reactive power (in the inverter definition: page "Output parameters", frame "Power factor"). NB: By mistake in the version 7.3.4, the limit is the higher CosPhi between Lagging and Leading. You should define a same limit for both. This will be corrected in the version 7.4.

Yes sorry. This is an error in the report. We will correct this for the next version 7.4, to be released hopefully about at end of May

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.