André Mermoud

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.