André Mermoud

The usual PV modules operate following the one-diode model, in the same way. The model covers the "extreme" conditions. There is no "special" behavior for some specific modules.

The LID loss is not related to the long-term degradation. The long-term degradation is applied to the module performance at the beginning of the simulation step. Now applying the LID loss before or after the long-term loss in the loss diagram has no real importance. However you are right: in the present time, during the simulation, the LID loss is accounted as a percentage of the degraded PV module, when it should remain as a percentage of the initial (not degraded) module. The error is very low, but we will correct this in the simulation for a next version.

The battery end of life is not a well-established criteria. As I said, the number of cycles guaranteed by the manufalctrers is sometimes based on 80% and sometimes on 70%. And the number of cycles you can accept for your own instalation depends on your requirements (kind or use of your system). We will consider to provide this as an option in a next version.

Please observe that the degradation specification of the PV module manufacturers is not the degradation factor. It is a warranty on the power of each PV module individually. The long-term degradation of the whole PV system is an average of the real degradations of all PV modules, which is indeed less than the warranty limit. Moreover, the LID is an initial degradation which has nothing to do with the long-term degradation. The initial value of this warranty curve (usually -2 or -3%) may represent sometimes the LID degradation, but also the uncertainty of the Power measurement (at factory) of each PV module. In PVsyst, the LID loss is specified independently in the "Detailed losses". It acts over the whole simulations (i.e. the whole life of the PV plant) as a permanent diminution of the real PV module efficiency. This is explained in detail in the help https://www.pvsyst.com/help/project-design/array-and-system-losses/ageing-pv-modules-degradation/index.html?h=degradation Now for the long-term degradation of a given year, the PVsyst simulation result represents the average degradation along this year, i.e. the average of the degradation value between the beginning and the end of the year. This is the reason why the degradation of the first year uses half the annual coefficient (and the next years use 1.5, 2.5, 3.5, etc).

The "loss" due to irradiance level is related to 2 factors: - The low-light performance of the PV module - The irradiance distribution along the period of simulation. Please check the low-light efficiency of your module ( PV module dialog, page "Model parameters => Rshunt-RSerie", option "Rel effic" 😞 The default of PVsyst (reasonable for most modules) is -3% at 200 W/m2. Now when distributing their own PAN files, most manufacturers set the Rserie parameter for boosting this value, to -2% or even -1% . In this case you have a large part of the curve with positive relative efficiency, i.e. a gain during the simulation at high irradiance.

The capacity slightly decreases when using the battery. The battery life (number of cycles specified by the manufacturer) is defined as the situation when the capacity drops below a given threshold. Traditionnally, this limit was usually 80%. Since some years, several manufacturers consider a drop down to 70% of the initial capacity. This is not always mentioned on the datasheets. The discrimination between input or output of the battery (efficiency, around 5%) doesn't make much sense as the uncertainty on the number of cycles is much much higher.

Thank your for sharing this very interesting experience of the real world when using batteries. However this is not really related to the simulation of systems by PVsyst.

This situation is fully explained in the help of PVsyst https://www.pvsyst.com/help/physical-models-used/grid-inverter/inverter-pnom-as-f-voltage.html?h=pnom The treatment of PVsyst is not exactly compliant with this specification, but the results should be close.

Please give some precisions about what you mean by "Night losses". You can define losses for feeding the auxiliary equipment (fans, HVAC, monitoring, etc) , which are usually drawn from the usual low-voltage grid. The Iron loss of the transformers is a completely different kind of "night" loss. In fact this is a permanent loss, acting as soon as your transformer is connected to the grid. When producing PV energy, this is substracted from the production. This loss may be suppressed by night, by installing a switch on the HV line.

The auxiliaries and night losses may be specified for the simulation, in the "Detailed losses" part, page "Auxiliaries". You have the opportunity of defining fixed values, with possibly a part proportional to the produced power, as the inverter losses will produce heat which has sometimes to be evacuated.

Sorry, this configuration of using the storage for shifting the delivery of power to anothe period of the day is not yet implemented in PVsyst. As a workaround for getting quantitative results, you can define a self-consumption system. You define a user's needs profile as the hours and power when you want to resell the electricity (this should be sufficient for completely discharging the battery). The results will give you the energy delivered to the user from the solar system, which is indeed the energy that you have reinjected into the grid.

Question 1: in PVsyst, the required power factor is fixed (yearly or monthly values). There is no dependency on the temperature. The inverter specification indicates wheter the Pnom is specified as Active power [kW] or apparent power [kVA]. In the inverter's definition, page "Output parameters": During the simulation, PVsyst will apply the PNom limit according to this definition. Question 2: In principle, the reactive power IS NOT a real power: you cannot produce movement or heat with it. Therefore the production of reactive power doesn't consume any active power. Now you talk about Reactive power generation during non-producing hours. This is a very special feature of some solar inverters. PVsyst doesn't treat this : the rective power is always generated proportionnally to the available active power.

If I understand well, you have a cluster of 8 MV transfos, and a line of 3 km up to the injection point or a HV transformer. You have probably a junction box, and a common line to the injection point. Sorry, this is not yet implemented as such in PVsyst. in the present time in PVsyst you can only define a line from each transformer individulally to the injection point. Therefore for each inverter you should define a line with a length of 3 km, but a section corresponding to the power of one transformer. In the future, we will implement the opportunity of defining a junction box, and a common cable transporting the global power of all MV transformers. Please see the help https://www.pvsyst.com/help/project-design/array-and-system-losses/ohmic-losses/transfo-in-cascade.html?h=mv+transfo for further details. NB: If you are working with the "relative" AC losses (i.e. defined as percentages), and you are waiting for a global loss of, say 1% for this 3 km line, you should define a loss of 1% for the line of each transfo.

In the loss diagram, the energies are always evaluated from the previous energy. In this case, the Stored energy sharing is evaluated from the charging energy rather than the discharging. You can evaluate the available solar energy as 20'443 MWh * (1-2.3%)*(1-0.5%)*(1-0.4%*(1-2.8%)*(1-1.0%) * (1-0.6%) = 18'933 MWh. Then: 18'933 MWn * 8.5% = 1609 MWh. This is the charging energy. The direct use is 8'933 MWh * 91.5% = 17'323 MWh. Here is the detailed calculation in EXCEL: you can check that the final result is very close to the loss diagram. NB: You can get the detailed calculations of the loss diagram directly in EXCEL. In the menu of the report, you can use "Export => Loss diagram values", that you can simply paste in EXCEL.

The energy provided by the Solar system may be used: - either for charging the battery, - or (mainly when the battery is full, but this depends on the kind of system) it is directly used, either for feeding the grid or the user's needs (this also depends on the system kind). This is what is named "E Direct Use", as a complement to "ECharging (from PV)".

This graph is the distribution of the output of the system, as a function of the output power. Each bin represents the total energy produced when the system is operating at the concerned power. Now if you have overload losses, these arise always at the PNom of the inverter (or the system). Therefore they are all accumulated in the class correspond to PNom. NB: when opening this diagram in "Detailed results => Predefined graphs", you have the opportunity of adjusting the vertical scale (up/down button on the top left of the frame) for getting a "usual" distribution plot.

Please check the definition of the PV module of your first simulation. The temperature behavior is certainly false. A temperature loss of 0.7% is completely out of expected range. Except of you are at th North pole, a temperature loss is always several percents. Your second simulation shows a a reasonable temperature loss.

When editing the report, please open "Report options" in the menu. Here you have the opportunity of defining the values you want in the monthly table. The TArrWtd value is not available on the report. You can get in in the detailed results, button "Tables". Here you can generate a table of monthly values with any chosen variable (option "Custom table").

The GlobInc value is the result of the transpositiom model, and therefore independent on the mutual shadings. However with tracking systems, the tracker's position - and therefore the GlobInc - is indeed dependent on the pitch when you are using backtracking mode. Please check that in your simulations the backtracking is activated.

First question: In usual systems, (not vertical), the "Ground reflexion on the front side" is very low. Now the PR in a Vertical situation with bi-facial doesn't make much sense. Therefore we don't worry about such inaccuracies. Second question: in "normal" systems with several rows, this contribution corresponds to the reflexion of the terrain between rows. In you particular case, you have probably one only row, or a very big pitch value. This is a limit case for applying the vertical rows model. Don't focus on the PR (which is an artificial indicator meant for usual systems, with well normalized incident irradiaton), and take the real energy yield into consideration. By the way the PR for bifacial models is not well established and is subject to many discussions. If you want to use the PR for a contract, you should carefully define the way of defining it with your contractor. For the 3rd question, the IAM effect is indeed included in the "Ground reflexion on the front side" calculation, as for usual systems, this is a very sensitive correction (this reflexion occurs at very high incident angle on the front side of the collectors). Last question: you can indeed perform a similar monofacial simulation, by setting the bifaciality factor of the PV module at a null value.

Yes, sorry, there are errors in the parameters of the help. We have to correct them. Here are the correct parameters: This gives this curve:

The simulation involves many complex models. The incident irradiance is evaluated by a transposition model, including possible tracking, and losses like shadings or IAM are applied. The PV array yield is evaluated using the one-diode model. Then you have models for the inverter, the AC losses, the ageing, etc... All these models are described in the help (see especially "Physical models used").

The PAN files are meant for internal use within PVsyst. They obey to some internal coherency constraints. We don't ensure support about modifying them externally.

You define the option you want, and when clicking OK, you will be prompted for saving your PAN file with your choice.

No sorry, we don't have any additional information about the flickering effects on the inverters and the MPP tracking. Please ask the inverter manufacturer. However considering the wind turbine as a disk is obviously not the right way. PVsyst doesn't treat semi-transparent obstacles.