André Mermoud

You can find some data about the current and voltage degradation in the works, namely, of the TISO in Switzerland. For example in this publication: https://www.researchgate.net/publication/256080133_TISO_10_kW_30_years_experience_with_a_PV_plant

We obviously don't avail of detailed ageing data for a specified PV module. The average degradation rate itself is really not well defined. In the literature you can find a wide panel of values (0.3% to 1%/year). The PVsyst proposition of 0.4% seems a reasonable choice for usual modules. The specific mismatch effect due to ageing has been developed "theoretically" as a tool in PVsyst, without any experimental basis. We don't know any publication studying this problem in the literature. The hypotheses under this evaluation (Monte Carlo evaluation of the dispersion progress) are purely speculative. Therefore this model is obviously not able to take your particularity into account in a reliable way. You can probably take a lower value for the Isc/Vos RMS.

The PVsyst proposition doesn't take the maximum current into account. It is your job to check it in your final design. However the maximum current of a PV array is not well defined: the value corresponds to the STC (1000 W/m2), but if the inverter is specified for a given maximum current, it will limit the array current during operation, by displacing the operating point on the I/V curve. By the I don't see where you find that maximum current of 180 A. The manufacturer specifies 325 A in the PVsyst database: Your configuration of 15 strings of 25 modules of 650 Wp represents a PV power = 243 kW, i.e. a current of 238 A under 1020 V at STC.

Please remember that we are working in hourly values. And the thresholds according to the battery SOC may arise during the hour, so that the transition from an operating state to another one may arise during the hour. Therefore you can have a "Battery full" state at the beginning of the hour, and a discharge during the rest of the hour. However there is also a visual artefact because you are showing lines from the middle of hour to the middle of the next hour. In your first plot, at 13:30 you have unused energy, but no BESS discharge. At 14:30, you have BESS discharge, but no Unused energy. The intermediate lines don't have any meaning.

First of all, the inverter's behaviour with grid voltage deviations is very rarely described in the datasheets, and probably different for each inverter. By the way, PVsyst doesn't treat possible Grid voltage variations along the time. This is not part of the input variables, and we really don't see from which source we could evaluate it in prevision simulations.

I don't see what you mean by "some modules are overlapping". For filling your field, you can do that manually by the mouse. But you can possibly use the option "Attribution automatique" (you have many options for doing this), and than correct what seems not suited for you, by exchanging/dragging the string attributions with the mouse.

PVsyst doesn't provide a plot for this variation, because the Voc is not of big interest for the simulation. You can get the results of the model for any Irradiance and temperature conditions, in the PV module definition dialog, main page, "Internal model result tool":

The answers to your questions are fully explained in the help: https://www.pvsyst.com/help/project-design/array-and-system-losses/ageing-pv-modules-degradation/index.html?h=ageing https://www.pvsyst.com/help/project-design/array-and-system-losses/ageing-pv-modules-degradation/module-performance-degradation.html 1. - ISC dispersion has nothing to do with the datasheets information. Its nature is explained in the help. 2. - You can evaluate the effect of the Current and Voltage degradation weighting by yourself, by excuting several simulations. You will see that this is not very significant. 3. - When you have one only module, it is quite obvious that you don't have any mismatch loss. 4. - In the ageing process, the mismatch between "degraded" modules increases along the time. 5. - This is an input parameter. The global degradation is the sum of the individual PV modules degradation and the increasing mismatch.

Sorry, I really don't understand your strategy. It is not the battery (or the Ecoflow) which decides when it starts charging or discharging, but the external conditions (user's needs or PV availability). Starting discharging at a given SOC doesn't make sense without a clear definition of the energy demand. PVsyst controls the the charging or discharging "autorizations" as a function of the SOC evolution. If you are discharging (drawing energy), the battery will stop delivering power when the SOC reaches the specified threshold "Minimum discharging". When you are charging, PVsyst will disconnect the PV production when the SOC attains the specified "Maximum charging". This may arise within hours, You have a part of the hour in one state, and another part in the other state.

Thank you for sending your project. However it doesn't show the same output as you have shown here: The message tells you that the maximum discharging power is highly undersized. Your load definition has many hours with a load demand of around 21.3 MW, including during night, and you limit the discharging power to 10 MW. When I specify 22 MW as a discharging power, as you did in your previous message, I don't see any error nor warning anymore.

The voltage drop of a PV array doesn't make much sense, as when the R*I² loss increases, the Pmpp will move on the I/V curve, and therefore the current will also be modified. PVsyst doesn't provide any guidelines for this difference between Power loss and Voltage drop, which depends on the I/V curve. We consider that the voltage drop is not defined, and of no interest in the case of I/V curves.

The EcoFlow is a grid-tied inverter, which can only be used (in PVsyst) in a grid-connected system. Now if you want to use it in a stand-alone system - which is probably more suited for your very special use - you should define it as a "Controller for Stand-alone" in the database. But the problem of the user's needs definition remains the same: you have to define it, whatever the way you are using the produced energy. The battery needs to "know" when it has to be charged or discharged.

Sorry, I can't understand that. Please send us your full project, using "Files => Export project" in the main menu. Send it by e-mail to support@pvsyst.com, and tell us in which variant you have this problem.

This concerns the inverter at the output of the battery pack. On the next page "Self consumption", please define the "Max. discharging power". As a first step, you can ask the default value proposed by PVsyst according to your consumption profile (checkbox on the right).

The Stand alone systems simulation in PVsyst is based on a balance between the PV production, the user's consumption and the intermediated battery for ensuring a match at each instant between these two energy systems. Therefore if you don't define the user's needs, the simulation cannot work, and I really don't see what you want to obtain as a result. Now if you consider this as a grid-connected system with storage, this should be a self-consumption system, and the problemremains the same: without self-consumption definition this doesnt make sense. You can indeed consider a grid-connected system, without storage, for the evaluation of the possible PV yield. This will not involve the battery. The battery behaviour is obviously dependent on when you will consume this energy, therefore on the user's needs definition. i

Yes sorry, this is an error in the graph title. The values for the curves calculation are indeed those specified in the dialog. Thank you for pointing this out. We will correct this for the next version 8.0.16.

The "Module quality loss" represents the confidence you put yourself in the PV module real performance. See the help https://www.pvsyst.com/help/project-design/array-and-system-losses/module-quality-losses.html?h=module+quality The "Light induced degradation" affects only the P-type wafer-based cells. It is sometimes - rarely - mentioned on the datasheets. See the help https://www.pvsyst.com/help/project-design/array-and-system-losses/lid-loss.html?h=lid The "Module Mismatch loss" depends on the real module characteristics dispersion. See the Help https://www.pvsyst.com/help/project-design/array-and-system-losses/array-mismatch-losses/mismatch-loss-due-to-modules-dispersion.html?h=mismatch NB: you have little questionmarks buttons for getting help for each of these losses, please use them.

There is no automatic way of optimizing the system for summer or winter in PVsyst. You are probably thinking about the "Quick optimization" tool present in the "Orientation" definition dialog. This is just an "immediate" tool for indicating how your present orientation choice is situated with respect to the optimum for this period. This choice doesn't modify anything in your orientation parameters, and therefor nothing in your system definition.

This is probably due to a bad definition in the PAN file used. I have corrected / securized this problem for the version 8.0.15, to be released mid-august 2025.

I don't completely agree with you. This parameter has indeed an effect, but it is extermely low. With one of my projects, after 10 years, EArray passes from 4483.6 MWh with 90/10, to 4481.2 with 10/90, i.e. a discrepancy of 0.05%. This means that this distribution is not really significant. I don't see any intuitive explanation. Only the simulation can establish this result.

I think you missed my previous answer, three days ago. I wrote : "this storage strategy - i.e. storing PV energy for a restitution in the evening - is not yet implemented in PVsyst." Is it not sufficiently clear ?

Yes, in this case, this is the ratio of the annual values. In fact, the P50/P90 statistical evaluation only make sense when you compare yearly results. These notions don't apply to hourly or daily values, and hardly on monthly values. For example for evaluating the P90 of the results of, say, January, you should avail of a list of January values from many years, and calculate the standard deviation of this sample. This will obviously be far larger than the yearly variability. This doesn't make sense. Now applying the P90 factor to each hour of a climatic data file is not correct. This would mean that each hour of a clear day would be diminished by this factor, which is obviously not the case. The P90 factor will induce a difference in the distribution of the bad and good days, not the absolute values of irradiances. The only way to get P90 hourly values is to use a TMY weather datafile specifically constructed in this way. I.e. choose periods for the TMY construction which result in a P90 predefined yearly sum. This file may be completely different than the original P50 weather file.

Your questions: Why is the “Produced Energy” (and PR) so much lower in the no injection scenario when the PV array performance and load supply remain the same? You have a system of 3.4 MWp, this probably produces more than 17 MWh during a clear day. Now during this day the internal consumption is 4.8 MWh and the possible storage is 3 MWh, therefore 7.8 MWh. If you don't reinject into the grid, you will have more than 9 MWh lost ! Is PVsyst not counting excess PV generation as “Produced Energy” when it is curtailed (i.e., when the battery is full and there's no injection allowed)? In this case the energy is indeed not used (it is even not produced), it is quite logical that it is named "Unused energy" Is there a better way to represent "total generation potential" in a self-consumption system without grid injection, so that I can compare energy yield more realistically? Why a better way? The "Total generation potential" is indeed the sum of the used energy and the unused energy, this seems quite clear for the user.

Sorry there is no workaround. This will be corrected in the version 8.0.14, to be released mid-July. In the meantime, you should reinstall the previous version 8.0.12. You can install it in parallel with this version 8.0.13, both versions may coexist without problem.

I observe that on the left, you have defined an iron loss fraction of 0.06%, which is reasonable (the usual values are around 0.1% of the nominal power). On the right, you have defined 0.77%, which is extremely high.