André Mermoud

Sorry, we don't know the LisePV software.

The "Module Layout" is a copy of the real 3D system, shown as a 2D representation. In this framework, PVsyst attributes a new "matrix" name to each table: it tries to identify lines and columns in this 2D representation, and redefines table names according to this matricial disposition. Each table may be seen using the original shading object in the 3D scene, or this matricial redefinition. You have the choice of seeing one or the other of these names. Note that if the 3D object is an array, its 3D name will be the same for several tables, and PVsyst has to complete it with "Row#1, Row@2, ...) In your case, the name in the combobox is the name of the 3D object, when the name on the plot is the Module Layout matrix name. The list of inverters is defined according to the sequence in the SubArrays. In the present time PVsyst doesn't identify "physical" inverters (i.e. No of inverter and No of MPPT input), but only deals with "MPPT inputs". This will be improved in a next version.

Please carefully check your management of the DST (Daylight Saving Time). As most of the Climatic data files, PVsyst doesn't take the DST into account: the Summer time is shifted towards Winter time. It seem that you are waiting for a production during "your" Summer time, when the PVsyst simulation works in Winter time.

When connecting SolarEdge optimizers (Buck/Boost) in series, you have to add the voltages. Now if you have different powers (shaded optimizer), the power curves are added down to the voltage limitation of the higher power optimizer. Below this current value you add a portion of hyperbola, and the voltage limitation value: this leads to a little disruption in the curve: Drawn as power, this becomes: There is indeed a degradation at high voltages. This is the reason why SolarEdge imposes a minimum number of optimizers in series (for attaining the fixed input voltage of the inverter), but also advises to foresee one or two additional optimizers for ensuring a good prevention of the shading effects. This is mentioned in the help.

You are right: it is not very logical that the battery is used when there is sufficien PV power for feeding the user needs. However if you think about the real system in operation: when the battery is full, it has to be disconnected. This means that the PV array is directly connected to the user's circuit, through the Power converter. If the user's needs are lower than the PV production, how does the MPPT-DC converter behave ? In a Grid-connected system, the Power limitation (which is a fixed value) is achieved by a displacement of the operating point on the I/V curve. A MPPT-DC converter should be able to detect the output needs level; probably an overpower (with respect to user) will increase the output voltage. The device should be able to detect this voltage increase and displace its operating point on the I/V curve accordingly, Which MPPT converters are equipped with such a control system ? I don't know ! When I wrote this simulation behaviour (25 years ago! ) I was pretty sure that such a control doesn't exist. This is now perhaps possible (this should be mentioned on the datasheets), and perhaps the simulation should be able to treat this case.

This probably depends on the PNom definition as a function of the temperature. - This may be different in both cases. You don't provide the values of PNom and PMax of each inverter and the corresponding reference temperatures. - It depends also on the way you have defined the inverter's temperature during operation in the dialog "Energy Management".

Thank you for this information. There is indeed an error in this calculation, we have to correct it for a future version (probably V 7.2.17). However this tool is purely informative, this doesn't have any incidence on the battery's behaviour.

The treatment of AMPT optimizers doesn't work anymore. It is a bug which has been introduced in the versiion 7.2.14 (and perhaps 7.2.13). This will be corrected in the next version 7.2.15, to be released very soon. In the mean time, the only way of using AMPT optimizers is to revert to a precedent version.

I don't see how you can use the yearly-monthly-daily calculation for the evaluation of the overlaod loss. Only the houly values give the opportunity of evaluating this, this is what is performed by the simulation of PVsyst. Now this is even not quite correct: for a quite accurate evaluation of the overload losses, the calculation should take the sub-hourly data (minutes data) into account. We are preparing such a possibility for a next version of PVsyst (but not available until some few months). .

The PV efficiency may be used in several different situations within PVsyst. - When used in the simulation, the Array temperature is known (evaluated from Tamb and GlobInc, by iteration). - In other situations (tool for PV curves or PV model plots, other tools outside of the simulation, this is not known and we have to do an hypothesis.

The Ni-Cd batteries don't obey to the same model than Lead-Acid batteries. We have not yet developed a specific model for this technology. Moreover the use of Ni-Cd batteries requires some specific precautions with the electronic devices used (larger voltages, SOC management, etc). And also the use of Cadmium poses serious environmental problems. which are very difficult to consider, especially in developing countries. We don't have a full knowledge of these constraints just now. We will probably develop this feature in the future, but we have other priorities in the present time. This also depends on the market's pressure. Few manufacturers are proposing Ni-Cd batteries for Solar use.

This is indeed a bug in the report: the value is shown in kW, without decimal: the real value is around 0.284 kWp (I don't see the real STC value of your modules)

These Latitude denominations don't have a well-defined definition of course. These are just for an evaluation of the suitability of some tracking modes according to the geographic situation. By Low latitude, we think close to tropical or sub-tropical (say below 30°), medium are latitude of medium Europe (35 to 45°) and high latitudes higher than 50°. Concerning the GCR of shed-like systems: you should essentially consider the mutual shadings: In low latitudes, the sun is very high in the sky, and the mutual shadings are low: you can diminish the pitch. At high latitudes, the sun is lower on the horizon, so that the mutual shadings become important, and especially in winter. For Tracking systems (N/S axis), the mutual shadings arise in the morning and the evening. dependning on the sun's height (profile angle). This is rather similar at low and medium latitudes. At high latitudes, the sun is low on the horizon and runs over very large azimuts (in summer). Therefore a vertical axis is more suitable. The advantage of tracking systems is mainly due to the beam component. Therefore tracking systems are suited for very sunny climates. You have tool in PVsyst for easily evaluate the performance of such systems (unlimited sheds or trackers).

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.