André Mermoud

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

In the AC losses part, the reference power may be either the STC power of the PV array, or the PNomac output of the inveters. This choice is done in the project's settings: In this case the PNomac of the inverters is the nominal power (not the possible max. power at low temperature). NB: In your case the choice of the reference power is the array STC power (nameplate of the PV modules). However the reference power choice affects the ohmic loss parameter when expressed in terms of percentage. The basic definition of the ohmic losses is the cable Resistance. When operating, the ohmic loss is proportional to the square of the current. When expressed as percentage of the power it is proportional to the power. This is explained in detail the help https://www.pvsyst.com/help/project-design/array-and-system-losses/ohmic-losses/index.html. As an example: You have defined a MV lines loss of 1% for a PNom at STC = 8.2 MWp (PV array). Now if you have a PNomac(inv) of, say, 6 MW, the relative loss at PNom(inv) will be 1% * 6MW/8.2MW = 0.73%. You can check that if you change the referenc power in the project's settings, the relative losses will drop accodingly in this dialog.

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=ageing The LID degradation occurs in the first hours of the system operation. It is simply treated as a diminution of the PV module efficiency, whatever the operating year. In your case it should be specified as null. This curve is a warranty for each individual module. It does not describe the average ageing behavior of the PV system.

I don't know what you have defined as Charging device power in the Grid storage dialog. Probably around 100 kW. Now I see that these hourly values correspond to a power of 1.4 kW, i.e. 1.4% of the nominal power. At this power level, the inverter efficiency profile (defined by a maximal and EURO efficiency) is very low, close to 0.

It uses the last two points.

Yes indeed, one only other user reported this error. The error is indeed the unit's name, which should be MWh/year. With this the value itself is correct. I really don't know the origin of this error. I tried to secure some initializations, but I really cannot reproduce this problem, so that I can't be quite sure that it has been corrected. The user who had reported it cannot reproduce it, too. If you get this problem in a stable way, please send us you whole project, using "Files => Export project" in the main menu. Please send it to support@pvsyst.com.

No, due to by-pass diodes, the hot spot situation is not supposed to arise in normal operation.

Yes of course. If you don't check this option, there will not be any losses due to the HV transformer, nor the line after this transformer.

When you have a nominal power, defined up to a given temperature, say 50°C, and an enhancced maximum power up to lower specified temperature, say 20°C, the simulation will use the curve shown in the inverter's definition dialog, page "Output parameters": The inverter temperature to be used during the simulation is defined in the "Energy management" dialog: Now the efficiency curve is specified by points at different powers, and interpolated between these points at each time step. If the actual power is over these points, the efficiency curve is simply extended linearly.

Sorry, no progress in the present time.

IRev is calculated according to the expression mentioned above, by neglecting Rserie (put Rs = 0). This expression gives the IRev as a function of a specified voltage. Iph is the short circuit current for this shaded cell.

In PVsyst, the model for the reverse characteristics is this quadratic expression. This corresponds rather well to the reality, but this is a rough approximation. By the way the values of this model have a quasi null impact on the PVsyst simulation results. Now the term (Rserie * I) is indeed a little contribution (perhaps it should not be taken into account, we will check). You can forget it.

This tool shows what happens for a specified current (i.e. imposed by the rest of the string). You can drag the red point of this forced current for analysing what happens at different values. The voltage of this point is the result of the reverse characterisics model: You can find this formula in the help https://www.pvsyst.com/help/physical-models-used/pv-module-standard-one-diode-model/reverse-characteristic-of-a-cell.html The temperature is obtained by applying the U-value on this cell, taking the dissipated power as input parameter instead of GlobInc.

First of all: the value 1.9% is related to the total energy flux of the system. The real "round trip" efficiency of the battery pack should be related to the energy passing through the battery. This is mentioned as 5.3% here. I don't know where your affirmation of 85% comes from. This is extremenly fluctuating according to sources. Some Li-Ion battery manufacturer mention 95% on their datasheets (which is probably not realistic), others 90%, rarely less. Due to the extreme complexity of the battery model, especially the SOC evolution according to the charging/discharging balance, the determination of the battery efficiency cannot be quite reliable in the PVsyst simulation. This issue is fully explained in the help https://www.pvsyst.com/help/physical-models-used/batteries/battery-model/battery-efficiency.html?h=battery+efficiency

In this tool, PVsyst tries to evaluate the temperature of the reverse-biased cell, as a function of the power consumed in this cell and the U-value (with resp. to 25° ambient). In this case this is not dangerous, but in usual modules the cell temperature may become very high: this is the hot spot problem.

Yes, this is an error in the report. This represents indeed the loss at the output MV line of the Transformer. We will correct this for the next version. When defining the wiring losses in PVsyst, the frame "Array wire loss inverter to transfo" concerns the connexions from the inverter to the transformers, and "Medium Voltage Line" the output of one transformer. The evaluation of the wiring loss is indeed a direct calculation of the loss, at each hour, according to the specified wire resistance and the instantaneous current. There is no uncertainty here, as far as the resistance is well defined. When specified as a percentage at a given power, the resistance is directly calculated from this loss (no error). The only uncertainty could be the resistivity variation according to the wire temperature: in PVsyst this is defined for 50°C, the variability being 0.39 %/°C.

Some answers to your questions: Module Mismatch Losses: Currently set to 1%. - This depends on the sample of PV modules you are installing. Not on the technology. String Voltage Mismatch Losses: Currently 0.1% - Idem, by the way this is an extremely small correction.. Module Quality Loss: Default. - This is a parameter at your disposal. You can put here what you want. But the default is based on the tolerance, it doesn't depend on the technology. LID Loss Factor: Set to 0% for N-type modules. It is indeed null for N-type cells. Otherwise the value should be set according to the manufacturer if available. For example, HPBC claims better shading performance — can mismatch losses be reduced? - This is indeed implemented in the ModuleLayout calcuation. But don't wait for a significant improvement of the shading loss ! (see the Help https://www.pvsyst.com/help/physical-models-used/pv-module-standard-one-diode-model/pv-module-reverse-lowvoltage.html?h=ibc Are there other parameters I should modify to better reflect these technologies? - If modifications are necessary, they will be in the PV module definition and modelling. We are currently studying this but we don't have definitive conclusions yet. The main workaround we can propose in the present time is to increase the Voc specified at STC when you cannot establish the one-diode model (i.e. when the RSerie cannot be specified for the required low-light performance).