André Mermoud

I have already answered this question in "https://forum.pvsyst.com/topic/3401-modeling-of-inverter-power-limitation-based-on-input-and-output-voltage-also-temperature-derating-for-multiple-input-voltages/#comment-9502

IIn PVsyst, the transformer losses are defined as a sum of - the ohmic losses, proportional to the square of the current or power, calculated at each hour of the simulation. The annual ohmic loss value is not identical to the specified loss fraction, which is specific to a reference power. See the help "Project design > Array and system losses > AC ohmic loss from inverter to injection point". - the iron loss, a fixed constant loss, permanent as soon as the transformer is connected to the grid. This may give a high contribution as it is permanent and doesn't depend on the PV production. See the help "Project design > Array and system losses > External transformer losses"

This PNom deratig according to the input voltage is not yet implemented in PVsyst. PVsyst puts a fixed voltage limit (here 1250 V) for the MPP tracking. However the PVsyst results should be rather correct. They will only be affected if you define high string lenghts (Vmpp close to these maximum operating voltages). As the falling slope of the P/V curve is close to the falling edge of this derating, the overload losses of PVsyst (by displacing the operating point on the I/V curve) are correctly evaluated when the MPP point is over PNom. The conditions for "stopping" the inverter will be similar (see the FAQ just below). https://forum.pvsyst.com/topic/194-why-sometimes-the-overload-losses-increase-significantly-without-reason/#comment-369 NB: This is on our roadmap. We will work on this topic during the next months.

Yes, this is normal. NB: In your voltage definitions, a current of 11A * Voltage of 235V means that you have an inverter with PNom = 11*235 = 2.58 kW (per MPPT input). This doesn't correspond to you previous posts where you had a voltage limitation of 235V for an inverter of 5 kW, i.e. a current of 21.28 A

1. - Temperature derating In PVsyst, there is indeed one only value for the temperature derating Nominal power. However the effect on the simulation will be extremely low because: - The inverter temperature is usually not known/defined with such an accuracy of 2-3 °C at each time step. - There are usually very few hours in the year with such an inverter temperature (this is the environmental temperature around the inverter) - When such temperatures are attained, the error will be effective only when the PV array Power is higher than the PNom of the inverter (overload conditions). 2. - Input voltage conditions This is indeed not implemented in PVsyst. But the behaviour of the simulation is rather close to these limitations. - On the left (low voltages), this corresponds to the input current limitation, defined in PVsyst by the "VmppMin for PMax" parameter (see the help " Component Database > Grid inverters > Grid inverters - Main interface > Grid inverters, main parameters") - On the right (high voltages), this curve corresponds to the increase of voltage when the inverter is in overload conditions (displacement of the operating point). Again, an error in the simulation will only occur in overload conditions, when the falling edge of the I/V curve is close (i.e. crosses) this PNom curve of the inverter. 3. - Grid voltage condition This is not applicable as the Grid voltage is not known during the simulation (it is not an input parameter). Again, this may only affect overload losses, in very particular Grid voltage situations.

We name "Module Mismatch" the mismatch between modules in a PV array. However this is highly dominated by the mismatch due to current differences (i.e. within a string). Because the current of the string is driven by the current of the weakest module in the string. The mismatch in voltage between 2 strings with "reasonable" voltage differences (some few percents) is very low. You have a tool for analyzing this in PVsyst, button "Detailed losses" => "Module quality - LID -Mismatch", page, button "Detailed study".

Thank you for this information. I correct this immediately for the next version.

In practice, the initial SOC for a new system may be anything: the battery from the manufacure may be charged, or not. If it has been stored for a long time, it may be quite discharged. The initial SOC may be specified in the Advanced parameters, topic "Batteries", item #301 "initial SOC for simulation". However this doesn't have any significant importance for a simulation over a long time.

This is on our roadmap. But it involves a very deep change in PVsyst, we will not find possibilities to develop this before probably more than one year.

You are right, the wind velocity measured according to the WMO standards (World Meteorological Organization) specify that the measurement should be done at 10 m height. The Uv value of 1.2 W/m²K / m/s proposed by PVUSA or Tim Townsend is referred to this measurements (i.e. values of all standard meteo data files). This is well explained in the help (topic "Array Thermal losses", paragraph "U-value"):

This is on our roadmap. But sorry, we cannot give a reliable delay. At least several months.

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