André Mermoud

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.

Sorry, this storage strategy - i.e. storing PV energy for a restitution in the evening - is not yet implemented in PVsyst. This should be done within some few months. I the meantime, if the battery has full priority at the beginning of the day, or charges with a fixed power, we can propose a workaround for at least evaluating the result. You could use the "Self-consumption" option, by defining a consumption corresponding to your foreseen reinjection power from 6pm, for a sufficient duration in order to discharge the whole battery (and null the rest of the day). Then you can consider the energy delivered to the user as the energy to the grid. You can ignore the missing energy.

There is indeed an error in the Backside diffuse irradiance calculation (in some special cases) in the version 8.0.13. However this comes back to normal when you save the variant and reopent it.

The cable type or installation mode may affect the resistance only in terms of "Resistivity as function of the Temperature". In PVsyst, the resistivity is specified for a temperature of 50°C (alu or copper). This will be modifiable in a next version of PVsyst (probably in V 8.1). But in practice, we usually don't have any information about the cables temperature in the system during operation. NB: The resistivity variation is 0.39 %/°C. Applied to a loss which is usually of the order of 1% of the total energy, the effect is completely negligible in the simulation results.

This warning has nothing to do with the Pmpp difference between the nameplate and the one-diode model result. This is due to a problem in the simulation process (irradiance calculations), which has been corrected in the V 8.0. But sorry, I can't say anything more without analysing your project in detail.

PVsyst is a worldwide distributed software. We obviously cannot include such national or local requirements, especially like this one which seems to be very evolutive. Moreover, we don’t want to take any responsibilities regarding such national administrative rules.

The transfo loss reported by the simulation (loss diagram) is the sum of the Copper losses and the Iron losses. Remember that the Iron losses are a fixed value, permanent (24/24) if you did not check "Night disconnect". It represents an important contribuition.

You mention that "PVsyst requires that the saturation current of a module at STC (I0_ref) be at least 0.01 pA, or 1e-14 A." I don't see where you found this statement in the documentation. Probably you have "added" the condition at STC (otherwise the documentation should indeed be corrected. Please observe that the Io value is extremely dependent on the temperature. It varies by a factor of about 20'000 when passing from 25°C to -10°C. In the PVsyst database, we try to choose parameters which ensure that the saturation current Io(T) remains > 0.02 pA downto a temperature of -10°C. See the help https://www.pvsyst.com/help/physical-models-used/pv-module-standard-one-diode-model/temperature-behaviour-correction.html#temperature-correction-on-gamma, especially the Nb2 paragraph.

This depends on the PV module you have defined in your subarray. The LID box is only visible when the LID is pertinent, I.e. with crystalline modules: siMono, siPoly, HJT