André Mermoud

The design temperature for defining the max. Voc value (to be compared to the VAbsMax of the inverter and the PV module) should be the minimum temperature measured during the day. This is a safety condition, for avoiding overvoltages damages at the inverter input. This is specified in the norm IEC TS 62738 (2018), paragraph 7.2.1. Now for such low temperatures, the one-diode model doesn't work well. For many modern modules, the temperature behaviour is not quite correct below -10°C. In this case you should consider a linear increase of the Voc value as function of the temperature instead of the one-diode model. You can do that by: - defining a customized muVoc value for your PV module (page "Additional data > Secondary parameters") - in the "Project's settings", specify that your design should use this value (open "Project's settings > Design conditions", and choose "muVoc value: from specification".

I have reconstituted your configuration. The problem is that when defining the inverter list, you have the following warnings in orange: Sub-array #1, NInv no match Sub-array #3, NInv no match This should produce an error, which doesn't appear when you do the design in this window, but appears when reopening the variant: The fact that this message doesn't appear when designing the system is indeed an mistake, but the specified configuration is well stored on the file. You should simply press the button "Adjust subarrays" and everythis will be OK.

The data specified on the datasheets of these 2 battery blocks RESU7H and RESU10H are indeed incoherent. These correspond probably to 2 or 3 modules type RESU 3.3, i.e. 2x or 2x 51.8V with 63 Ah, with a DC-DC bidirectional converter for a 400 V external voltage. . This is not implemented as such in PVsyst. As a workaround, I have defined these devices as batteries of 108 cells in series (400V) , with reduced capacity (17 or 25 Ah). These will be available in the next version 7.4.5 of PVsyst.

Please have alook on your first dialog (top of your first post). You have defined a battery pack of 512V / 103 Ah, i.e. 52.7 kW "gross". You have defined a PV system which will deliver 5.4 kW under full irradiance, corresponding to a full charging in roughly 7.8 hours). This is quite correct. For this Power limit you could even define a smaller battery pack, corresponding to one day of overload (see "clear day excess energy" on the next page). Now on the page "Peak shaving", you have to define the "Battery input charger" power which will charge the battery. Here you have probably defined a device of 50 kW, which is highly oversized. You could define a charger of, say, 6 kW, and everythig will be OK. Same remark for the "Battery to grid" inverter power: this power will determine the speed at which you will discharge the battery during night.

The number of cells is defined on the page "Size and technology". In your case, the Vmpp = 39.27 V at STC, indeed corresponding to 66 cells, i.e. a voltage of 0.595 V/cell, which is quite correct. Now when you are using the model under different irradiance and temperature, the Voc is obviously different (here higher than at STC as the temperature is lower then 25°C).

Yes indeed, we are aware of this problem. For the version 7.4.3, we have implemented the new complex rules specified by Huawei, for the implementation and use of their optimizers. For doing this, Huawei provided 2 very different protocols, for low power (450 and 600W) and high power(1100 – 1300 W) optimizers. The protocol for high powers specifies that you can only connect one string per MPPT. What we did and is on the basis of our new implementation. We thought that this statement was also valid for the low power optimizers, and we developed this complex tool with this hypothesis. But it appears that this is not the case. The only way of using your 450 W with several strings per MPPT is to revert to the previous version 7.4.2. However the versions 7.4.2 is not compatible with the patchs 7.4.3 (or 7.4.4, 7.4.5): you cannot use them in parallel, you will have to uninstall the V 7.4.3. If you really need to keep parallel versions, you can install the version 7.3.4, which may be installed/used in parallel with the versions 7.4.3. This will be corrected in a version 7.4.6, to be released in January 2024.

In PVsyst, all the AC losses expressed as percentages are referenced to a same power. This power may be either the STC power of the PV array, or the PNom output limit of the inverters. You can modify this choice in the Project's settings (button at top of the project's dialog). You can have a look on the help "Project design > Array and system losses > AC ohmic losses: reference power".

Please carefully read the report: - on the left you have the transformer characteristics, with a nominal power of 5.3 MVA. - on the right you have the operating conditions, showing the "Nominal power at STC. This is the reference power for the wiring loss estimations in percentage.

No, the LID loss only arises with P-type wafers.

First: the fact that the battery pack is provided by a manufacturer doesn't mean that this is correct. The definition of batteries in PVsyst is complex, and I have seen several BTR files from manufacturers which were erroneous. I am working on this Grid systems simulation with storage just now, and I have discovered errors is some specific cases, namely when the battery has several "blocks" in parallel, and with disproportioned loads or battery packs. You should wait for the next version 7.4.5 (to be released in December 2023) for a complete revision of this simulation in any case. NB: The fact that the EBatDis = 505.48 kW when the discharging limit = 500 kW is normal, as the 500 kW is the output of the inverter, when the EBatDis is the input. You have to account for the inverter efficiency.

Sorry, we don't know any problem of this kind. Please check that in your first simulation, you have the same degradation parameters than for the Aging tool. If so, please send your full project to support@pvsyst.com, with a detailed explanation of your problem.

The degraded PV module is calculated once. Then the simulation is performed with this module, for the simulation of the full year.. The effect on the yearly degradation loss is the average over the year, i.e. between the beginning and the end of the year. This is the reason of the half-values for the degradation factor.

This configuration is different than the previous one. Here you have defined a charging power of 100 kW, ensuring a charge in 1.6 hours under full sun. This is more reasonable. This is close to what is acceptable for Li-Ion batteries. This charging time was 10 minutes at sun in the previous case, and as PVsyst works in houly steps, this leads to some problems when simulating one full hour. Normally PVsyst should not allow a charging/discharging Power - or current - exceeding the battery data. I don't know why this did not show the correct error message. Is your battery from the database, of from an external file ? I am just on the way of correcting these extreme problems for a next version. By the way, I persist to say that implementing a battery storage for storing an energy corresponding to 8 minutes of average consumption doesn't make sense. It depends on what you want to do with your system. If it is for an UPS (i.e. ensuring the continuity of the energy supply for a little securized part of your installation), you should define the discharging power consequently.

As we should always keep a balance between the available energy and the demand, a stand-alone systems cannot work without a storage system. At each instant, the load will be satisfied by the PV production, and the battery if this is not sufficient. A possible genset is here especially for ensuring the needs when the battery is empty. Now the case where a constant power is permanently available from a genset has indeed not been foreseen in this strategy. If you really don't have a battery storage, you should consider this case as a "grid connected" system with self-consumption. The excess power generated by the PV array will be considered as a grid injection, and the energy from the Genset the energy "from grid" required by your load.

If you want to become familiar with this topic, you should define realistic conditions. Otherwise you cannot understand the problem.

Yes, thisis what I said.

I had a look on your data (sent to Support). Your data seem a bit strange. They mention a 31 June, and the 31 May is missing. I attach a corrected file, where I have suppressed the 31 June and the file may be imported. I don’t know what happened with these data. However I suggest that you shift all date values from 01/06/22 – 31/06/22 into 31/05/22 – 30/06/22.

Your battery pack (160 kWh) is completely undersized. With a PV power of 846 kWp and a max. load of 1048 kWh, it could be charged in 11 minutes, and discharged in 9 minutes. Sorry, PVsyst doesn't treat this absurd situation correctly in the present time. You should at least limit the Charging and Discharging powers (next page) to ensure a reasonable charge/discharge in about 2 hours (i.e. a charging power of the order of 160 kW/2). But such a system doesn't make sense. We have indeed to correct the model for such situations. This is on our roadmap for a very near future.

I don't understand well what you mean when you say "different efficiency profile when calculating with CEC (98.0%) and EUR (98.3)". A profile is defined as a set of values, not one only; what is 98 or 98.3 %? The EURO or CEC efficiencies are indeed a way of evaluating a yearly average of the effective efficiency, based on the expressions you gave above. This average is a weighted average of a supposed power distribution along the year, If these data powers distributions are different, the weighted result is different. The EURO efficiency is a weighted average calculated on a "reference" energy distribution corresponding to meteo data chosen as those of ISPRA (location of the JRC - Joint Research Center - at North of Italy, in the years 1990), when the CEC efficiency is based on a climate corresponding to the californian climate. Now in absence of an explicitly defined efficiency profile, PVsyst tries to reconstruct a "supposed" efficiency profile reproducing these very simplist data "Max efficiency" and "EURO efficiency" (or "CEC" efficiency). This reconstruction uses reasonable hypothesis, but cannot obviously be absolute. These hypothesis are described in the Help "Physical models used > Grid inverter > Inverter model: efficiency"

The shadings calculation should normally be based on a 3D scene. In this case you should use "Tracking, horizontal axis N/S". However for a quick pre-calculation, you can use the orientation option "Unlimited trackers", which will perform the shadings calculation according to a generic reguar system. NB: You cannot use a 3D scene with the option "Unlimited sheds".

Some answers to your questions: 1. - SOCBal is the stored energy difference between the beginning of the calculation period and the end. It cannot be higher than the energy contents of the battery of course. 2. - The SOC at the beginning of the simulation is specified in the advanced parameters, topic "Batteries". 3. - Yes, the availabe energy when discharging is EBatDisc - CL_InvB 4. - No, PVsyst doesn't treat the mode of charging the battery from the grid. This doesn't make much sense: what would be the strategy? When activating the charging ? Why?

This is not quite exact. The PR is referred to the Incident global GlobInc (result of the transposition), not the GlobEff. NB: This PR is calculated by PVsyst. You should obtain the same result. The PR indicator takes into account all the losses mentioned on the loss diagram, between "Global incident in Collector plane" and "Energy injecter into the grid".

PVsyst doesn't take an ageing of the inverter into account. On which operating parameter would it be applied ? I doubt that the efficiency could be affected, as this would increase the heating along its life. The only effect I can see is the reduction of the lifetime (MTBF). This is not addressed in PVsyst in the present time. Now for the evaluation of the produced heat during operation, the best way would be to use the inefficiency, which is a curve according to the power, and possibly to the input voltage. This is directly accessible in the simulation data (IL_Oper loss) for each operating hour.

I don't understand well what you mean. The LID loss is accounted in the simulation. It is explicitly defined in the Detailed losses parameters. The warranty mentioned on the datasheets is not registered in the PAN file, and not taken into account in PVsyst.

I don't know what you are waiting for. Our calculation model is the better way we can imagine for the evaluation of the Bifacial yield. We have deeply checked for the version 7.4.3, that the rear side incidence irradiance is equivalent to the front side (up to about 1-2%). If the bifacial results were false, this would mean that the whole simulation of PVsyst (front and rear side) is erroneous, i.e. that the transposition models themselves are incorrect. I don't know with which data in real conditions you are comparing the PVsyst simulations, and what you consider as acceptable. NB: If you have really measured data on the field, we would be happy to get them for analysing the discrepancies. I don't know how PV*SOL evaluates the vertical bifacial systems, but we don't have any reason of being quite compatible with their resuts.