André Mermoud

Yes indeed, this problematics is often asked to the PVsyst team. We consider providing a solution in the future, but probably not before several months. In the mean time: the solutions mentioned above may be acceptable workarounds. We can observe that the difference in power between both module kinds (325-330Wp) is 1.5%. If the expected result is only the system yield, you can perform 2 simulations, one with each module, and do a weighted average of the E_Grid. With this approximation, except the energies (EArray and E_Grid), all the losse (in percentage) will be quasi-identical in both simulations.

There are indeed some simulation problems with a very low grid limitation threshold, especially when you have several sub-arrays. For simulating a system in self-consumption without injection into the grid, you should use the "Stand-alone" option. Or for a big or complex system, you can simply use the normal Grid-connected system, and consider the E_Grid as an unused energy rahter than an enegy injected into the grid. This is quite equivalent. Indeed, the grid limitation is not compatible with self-consumptions systems with storage.

First of all: what do you mean by DOD ? DOD means "Depth Of Discharge", this is the contrary of SOC, which is "State Of Charge": DOD = 1 - SOC. Therefore the minimum DOD corresponds to a fully charged battery. Now for your question, I don't know. Please send your whole project using "Files > Export files" to Support@pvsyst.com.

This is indeed a rounding effect. I don't know how you have evaluated your values, but we consider that errors lower than 0.1% on a specific month is completely insignificant.

At the inverter level, there is a first limitation, which is the nominal power of the inverter. If the Inverter's power limitation is attained (before the grid limitation is applied), it is accounted as inverter overload loss. When the the grid limitation occurs, in practice it is executed by limiting the power at the output of the inverters. The corresponding power loss due to the grid limitation is accounted a grid limitation (unused energy). This requires that the "grid power measurement" information has to be included as input to the inverter, for adjusting its real output power. Now applying the grid limitation "at the inverter level" means that this required grid power limit value is evaluated at the output of the inverters. This means that the AC losses after the inverter are not taken into account, i.e. that the effective power at the grid level will be (Grid limit - AC losses).

This depends a little bit if you are in a Stand-alone system, or a grid-connected system with storage. For a stand-alone system, these values are fully defined in the help "Project design > Results > Simulation variables: Stand alone system". Except perhaps IUser = EUser / UBatt (the user is supposed to be fed directly by the DC bus). For a grid system with storage (self consumption mode), this is explained in the help "Project design > Grid-connected system definition > Grid systems with storage > Self consumption with storage". Pay attention on a difference: here E_User is the user's needs, which are referenced as "E_oad" in the stand-alone system.

This is quite normal. The mismarch between strings of identical or close voltages is very low, even if you have high current(power) differences between strings. The mismatch is only due to a possible voltage difference (TArray may be slightly different in different orientations, due to irradiance). In your case the orientation difference (tilt = 10°) is rather low. You have a tool in PVsyst for understanding the Mismatch between strings: please open "Detailed Losses > Module quality - LID - Misatch" page, and press "Detaied study".

There is no simple formula. The IArray is computed from the one-diode model, and modified according to some losses in the PV array. The one-diode model is fully described in the Help "Physical models used > Standard one-diode-model". This is a complex calculation that you cannot evaluate by hand. NB: in your report of hourly values, several units are not correct: I Array is in [A], no kAh, "Energies" (in fact average powers on one hour) are in [W], not kWh.

No sorry, this is not explicitly mentioned in this dialog. You have to take the the PV area from your "System" definition, and simply calculate this value explicitly by yourself (Ground area = Sensitive PV area / GCR) We will see for adding this information in a next version.

The PNom of the SolarEdge inverters on the report is the result of a complex calculation (especially when you define several different strings), and may indeed lead to some errors. In this particular case, the name of these inverters is SE100KUS, but these are assemblies of 3 inverters of 33.3 kW (nominal power). When you multiply by 3 * 8 you obtain 799.2 kW. This is quite normal. By the way this value only concerns the report. It doesn't have any influence on the simulation results.

Please reas the help "Physical models used > PV Module - Standard one-diode-model > Sandia Model for PV modules". Everything is explained here. See also the report SAND2004-3535 (2004) The Sandia model has been developed by the Sandia Laboratories in the years 1990-2000. The elaboration of the Sandia Model parameters for one module requires a detailed measurement of many I/V curves, during about 10 days. The Sandia Laboratories have measured and characterized about 100 commercial PV modules up to 2004, However to my knowing they did not publish any new data since about this date. These data are available in PVsyst. The main objective of implementing this model in PVsyst was to closely compare its behaviour to the PVsyst one-diode model. This allowed to establish the low-light behaviour in outdoor conditions (and therefore the Rserie value) of this sample of modules.

You are right, there is some confusion in the report here. The result is indeed an energy, to be specified in kVARh and KVAh And we will harmonize the denominations "From the grid" and "Towards grid.

The temperature behaviour is determined by the muPmpp value, which is always specified on the datasheets. I don't identify the origin of this very little discrepancy of 0.07-0.09% between versions. I don't know which differences in input parameters are involved in lines #1 and #3. Even if the Rshunt value is different, the final default behaviour is determined by the Rserie value, which is adjusted in order to fix the Relative efficiency @ 200 W/m2 at -3%. The Rshunt value may change the curve shape, only in a marginal way. Now the differences in the results are in a fork of 0.08% in one case, or 0.14% in the other one. NB: If the parameters are specified within the PAN file, they are used as such. Only the default value may change.

The "Thin object" feature is related to the electrical mismarch losses, i.e. the repartition of the shades on the PV modules (or more exactly cells). It doesn't affect the "Linear" shading loss, which is a deficit of irradiance, and is calculated in the same way as other shades. The percentage specified here corresponds indeed to the "Fraction for electrical effects" of the main shadings dialog. This value is the same for all "Thin objects" of your 3D scene. The best way of evaluating this fraction is given by the specific tool "This objects shading analysis". During the simulation, the "Linear shading loss" due to irradiance deficit will be the same. But for calculating the "electrical mismatch loss", PVsyst will evaluate the loss due to the "string rectangles", and apply the "Fraction for electrical losses" of the thin object to the shading rectangles affected by the thin object. This calculation "According to module strings" in indeed an approximation. It is mainly applicable to regular systems for mutual shadings from one row to the next one. It is not realy applicable to other shading objects. This the reason of the parameter "Fraction for electrical shadings". We don't have any mean of determining the "Fraction for electrical shadings" in a general case. The only realistic calculation is the Module Layout tool. However this tool doesn't manage thin objects.

Yes, the default values for the PAN file parameters are a difficult problem, and PVsyst has evolved about this question. The objective is to find a set of parameters leading to the same behaviour in operating conditions (namely the low-light relative efficiency) In PVsyst we have decided to specify the default values in order to obtain a relative efficiency of -3%. This may be achieved with different Rshunt values, but the Rserie is adjusted according to this criteria. Please see the latest version 7.2.12, and especially the new help topic in this version: "Physical models used > PV Module - Standard one-diode-model > Rseries and Rshunt determination procedure"

Are the other tables exactly of the same size ? Did you push the button "Applica" ?

The RMS of the Isc and Voc values is not a calculation, but an hypothesis (input parameter) for this pedagogic calculation tool. This allows to define a distribution in a simple way. Logically, this should indeed be related to the the tolerance of the PV modules sample defined by the I/V measurements performed at the output of the facory, and which can sometimes be obtained from the manufacturer. Applying this value leads indeed to very low Mismach losses. However in the reality, the dispersion is probably much higher, due to the quality of the Factory's flast tests instruments (their accuracy cannot be better than around 3%), differences in LID or soiling, etc. See our FAQ How to define the Mismatch loss parameters ?, differences after LID, etc.

Yes, this is on our ToDo list. But I don't know when we will implement this.

Yes, in the simulation the inverter chooses the best MPP (which is not necessarily the case in the reality). However this best MPP voltage is often lower than the Minimum voltage for MPP tracking, so that the simualtion will choose the better power between the secondary MPP and the power at the VmppMin. This is visible in the plot showing the I/V curves in the Module Layout tool.

In the simulation, the lifetime is a mix of the "Static" lifetime and the ageing due to the number of cycles. The ageing due to the cycling is probaby much higher with your Lead-acid battery than for the Li-ion (6000 cycles at 80% DOD) But the Li-ion battery you have used is specified for a lifetime of 5 years in the database. Now it is extremely difficult to find datasheets for Li-Ion batteries, and still more difficult to find this information on these datasheets. However I finally found a value of 10 years for the static lifetime of this battery. You can modify this in your battery definition (page "Detailed Model parameters"). I will also update the database for a next version.

The Mismatch between PV modules in an array is a rather rough calculation, based on a statistical distributions of the parameters. The phenomenon is mainly related to the mix of different I/V curves, by calculating the addition of currents (in series) and then voltages (strings in parallel). This is not really sensitive on the exact I/V curve of each PV module, so that we may avoid recalculating the I/V curve from the one-diode model for each module. The shape of each I/V curve will be very similar for all the concerned modules. Therefore this tool uses the basic I/V curve of the reference module, and performs a "scaling" if the voltage and the current according to the individual Voc and Isc of each module.

The Bifacial model of PVsyst supposes that your system may be approximated by an "unlimited sheds" configuration. In your case, perhaps the altitudes of some trackers are not completely homogeneous, or the spacing between trackers is not sufficiently regular.

The web site of PVGIS has changed, so that the old versions of PVsyst cannot import them anymore. THe first version able to import the new PVgis data is V 6.86. Please update.

The *.SHD files are meant for internal use in PVsyst only. We don't provide any description nor ensure maintenance about these files, which have a very complex structure. You can import CAD files from diverse File formats (.DAE, .3DS, .PVC). See the help "Project design > Shadings > Near Shadings: Import "

You should use the "Power sharing" option for distributing the available Nominal power ont several MPPT inputs.