Lazare Fesnien

Hi, Most of the parameters are from datasheets. Some few parameters are not mentioned on the datasheets, and have to be evaluated. The main "uncertain" parameters (not on the datasheets) are the Rserie and Rshunt. These values determine the low-light performance of the PV module (relative efficiency as a function of irradiance, with respect to STC efficiency). If we have independently measured data (provided by some few manufacturers), we can adjust the resistances values as function of the measurements. Otherwise PVsyst chooses a "default" value, fixed now at -3% @ 200 W/m2, which is close (or slightly below) the performance of most measurements we had received. The problem is now that with modules of very recent technologies, the Series resistance is optimized (has a lower value), which produces a lower low-light performance. So that with the default of -3%, PVsyst may have over-evaluated performances with respect to the reality. We have valid low-light measurements from about 20 to 25 manufacturers. But not for all their production, just some few (usually rather old) models. The measurements received during the last 2-3 years are very scarce. Many manufacturers now provide the PAN files by themselves to the final users. So that they can put the "uncertain" parameters as they like (usually for boosting the performances). This is for the series resistance, but also for the IAM performance. Many manufacturers propose measurements which are – to our mind – completely irrealistic. See our FAQ : https://forum.pvsyst.com/viewtopic.php?f=19&t=2690

Hi, Indeed, you are right. We have reorganized ourselves internally in order to be able to answer questions pending on the forum. hoping that the answers we bring you will help you in your simulations

Hi, If the open circuit voltage is dependent on the temperature, there may also be an efficiency deficit when the temperature at discharging time is lower than the temperature when charging. This could be the case for an electric car in cold climates. In static solar systems, the battery bank is usually at a relatively stable temperature (indoor). Finally we should have: Battery efficiency = Coulombic efficiency * Ohmic efficiency * Temperature efficiency

Hi, Five parameters not defined from the datasheets are used in the one-diode model (as modified by PVsyst): Rserie, Rshunt, RshExp, Rsh(0) and Gamma (diode ideality factor). The main modification of PVsyst to the standard model is the exponential behaviour of the Rshunt value acc. to the irradiance. PVsyst fixes some default values: RshExp = -5.5 seems a very stable parameter, established on our long-term measured data at sun (direct measurement of the Rshunt as the slope of the I/V curve around V = 0), valid for any technology. Rhsunt = "reasonable hypothesis" of PVsyst, established acc. to Imp/Isc at Vmpp. This doesn't have a high impact with crystalline modules. RSh(0) = 12 * Rshunt for most technologies, was diminished for crystalline but seems indeed to be of the order of 10. This ratio is also fixed for default values. Now remains Rserie, and the closely related Gamma value. This is determined according to the low-light efficiency curve at 25°C. If we avail of IEC 61853 measurements, the value is set for matching these measurements. If not, we fix a low-light relative efficiency = -3% @ 200 W/m2. Sometimes this value cannot be reached by the model. In these case we increase the RShunt value, which allows higher Rseries and therefore higher low-light efficiencies.

Hi, When the manufacturer "imposes" a power conditioning unit device to be used with his pump, he usually specifies the converter electrical input and not the pump's input requirements as operating conditions. Therefore in these cases the component black box includes the converter-motor-pump set, and the PVsyst's pump model should act with the converter as input variables. This is namely the case with AC motor pumps, as PVsyst never manages the Pump input AC voltage nor its frequency. Only the Pump power input is a relevant input variable. This holds indeed for any pump for which the power is specified instead of the current and voltage (Flowrate=f(Power) model). Please read : https://www.pvsyst.com/help/simulation_variables_pumping.htm?zoom_highlightsub=pump+current

Hi, No, this configuration is not possible. A string must consist of one and the same type of PV module and optimizer. However, you can create different sub-array with different characteristics

Hi, You can change this STC reference to Pnom (inverter) from the tab: Project settings Please read : https://www.pvsyst.com/help/ohmic_loss.htm

Hi, The limitation itself will always be managed by the inverter as a clipping. By default, it will be accounted for in the simulation results as an inverter overload loss. You can change this behavior by checking the box "Account as separate loss". In this case, the part of the inverter clipping that comes from the injection limitation, will appear as a separate loss, right before the grid injection. The inverter overload losses will not contain this contribution any more, and the power at the inverter output will be increased by this amount. This does not correspond exactly to the physical behavior of the system, which will always clip at the inverter, but it is meant to show explicitly the part of the clipping losses due to the injection limitation. Please read : https://www.pvsyst.com/help/grid_power_limitation.htm?zoom_highlightsub=grid+limitation

Hi, In PVsyst, the Power factor may be specified by pressing the "Energy management" button, either as Cos(phi) or as Tan(phi). It may also be specified in monthly values. This will act on the inverter Pnom limitation if specified as Apparent power limit, and the apparent energy is mentioned on the loss diagram. The energy E_grid calculated by the PVsyst simulation is the active (or real) energy, expressed in [kWh]. Now the grid manager may require to produce some reactive energy for compensating the unbalances of the other users (expressed in [kVARh]). The Apparent energy is the product U * I expressed in [kVAh]. If the voltage is sinusoidal, the active (or real) energy is U * I * cos(phi) [kWh], where phi is the phase shift between current and voltage. The Power Factor is the ratio of the Active energy to the Apparent energy. In the sinusoïdal case, it is equal to cos(phi). The phase shift produced by inverters is sometimes expressed as Tan(phi), positive for reactive power generation (capacitive, Phi>0, named "Leading") and negative for reactive power absorption (inductive, Phi<0, named "Lagging").

Hi, When including a PV module in the PVsyst database, there is no real "validation". Most of the parameters are from datasheets. Some few parameters are not mentioned on the datasheets, and have to be evaluated. The main "uncertain" parameters (not on the datasheets) are the Rserie and Rshunt. These values determine the low-light performance of the PV module (relative efficiency as a function of irradiance, with respect to STC efficiency). If we have independently measured data (provided by some few manufacturers), we can adjust the resistances values as function of the measurements. Otherwise PVsyst chooses a "default" value, fixed now at -3% @ 200 W/m2, which is close (or slightly below) the performance of most measurements we had received. The problem is now that with modules of very recent technologies, the Series resistance is optimized (has a lower value), which produces a lower low-light performance. So that with the default of -3%, PVsyst may have over-evaluated performances with respect to the reality. See our FAQ : https://forum.pvsyst.com/viewtopic.php?f=19&t=2690

Hi, In addition to the Meteo Database included in PVsyst, there are many meteorological data sources available from the Web or by other means. PVsyst includes a tool for easily importing the most popular ones. These are summarized in the tables below, and we have performed a comparison between their results. Sources of Meteo data, in hourly values •Vaisala (previously 3Tier) provides hourly data measured by satellites, recent, for any location on the earth. Paid service. •Explorador Solar provides hourly data measured by satellites,for Chile, in the form of time series of the 2004-2016 period and also TMY. For free. •Meteonorm hourly values are not measured, but synthetic data constructed in the same way as the synthetic hourly values in PVsyst from monthly values. •NREL's National Solar Radiation Database provides Typical Meteorological Year files which are compilations of measured hourly data chosen among 1961-1990 (TMY2) or 1991-2005 (TMY3), for 1020 locations in the US. This USTMY2/3 format is also a standard used for other kinds data, used for example as input for the SAM software (Solar Advisor Model). •NREL's for India provides data for India, for the 2002-2011 time period coverage, in TMY3 format. •NREL's NSRDB Data Viewer provides Typical Meteorological Year files which are compilations of measured hourly data and (sub-)hourly time series from 1998-2016 for PSMv3 and 2000-2014 for Suny. The files provided are in SAM CSV file format. •PVGIS_v5 provides Typical Meteorological Years for geographical location around the world with data from CM-SAF, SARAH and NSRDB. Available at geographical site creation. •ReuniWatt provides hourly data measured by satellites, recent, for any location on the earth. Paid service. •Soda-Helioclim provides data in hourly values, measured by METEOSAT, since February 2004. But these data are not free. Files usually provided in PVsyst standard format. •SolarAnywhere provides bankable solar resource data for project finance. Available for specific sites on a 1 km x 1 km or 10 km x 10 km basis from 1998 to the present hour depending on geographic availability. •SolarGis provides hourly data measured by satellites, recent, for any location on the earth. Paid service. •SolarProspector, now decommissioned, was providing hourly values, including ambient temperature, for any location in the USA, for free. PVsyst still allows the processing of Solar Prospector files. •Vortex Solar provides hourly data measured by satellites, recent, for any location on the earth. Paid service. ... and in monthly values •Meteonorm monthly irradiance data are available for about 1'200 "stations", as averages of 1960-1991 (and also 1981- 2000 in version 6.1). All "stations" (i.e. with irradiance measurements) of the main European countries are referenced in the PVsyst database. Data for any other site may be obtained by interpolation (usually between the 3 nearest "stations"). •NASA-SSE Data (Surface Meteorological and Solar Energy Programme) hold satellite monthly data for a grid of 1°x1° (111 km) covering the whole world, for a 10 years period (1983-1993). •Solargis provides also monthly data measured by satellites, recent, for any location on the earth. For pay. Please read : https://www.pvsyst.com/help/meteo_notes_datasources.htm

Hi, When you have a different number of strings on the MPPT inputs, you should create one sub-array for each configuration (for example one sub-array for the MPPTs with a single string, and another one for the MPPTs with two strings). Then, in ‘power sharing’, you tell PVsyst which sub-arrays belong to the same inverter and how the power of the inputs is balanced. You can also find more information in the help under: ‘Project design > Grid-connected system definition > Multi-MPPT inverters’ ‘Project design > Grid-connected system definition > Multi-MPPT inverters: power sharing’

Hi, The efficiency is the ratio of the output power with respect to the input power. It depends mainly on the power and can also be a function of the input voltage. In PVsyst there are 4 ways of defining the efficiency of inverters : - from a single efficiency curve eff = f(Input power), specified by up to 8 points - from a single efficiency curve eff = f(Input power), automatically built from the Maximum, EURO or CEC efficiencies and the Power Threshold (Pthresh) - from a set of 3 efficiency curves eff = f(Power, input voltage), all of them specified by up to 8 points - from a set of 3 efficiency curves eff = f(Power, input voltage), all of them automatically built from the Maximum, EURO or CEC efficiencies and Pthresh.

Hi, If you have not defined DC ohmic loss (Detailed losses tab) then DC output array = DC input Voltage If you have defined a DC side wiring loss in this case the loss will be taken into account. We have not yet defined a viewable variable but it can be an improvement

Hi, These values ​​cannot be changed by users. The optimizers are defined with precise rules and with close collaboration with the manufacturers

Hi, Do these files have the .OND extension? If this problem recurs, please send us an email at support@pvsyst.com in order to better help you.

Hi, The only way is to re-define your inverter as 2-MPPT inputs, and define one sub-array per kind of modules. By the way the mismatch between strings of different but close voltages is completely negligible. You can have a look on our tool "Detailed Losses > Module quality – LID – Mismatch > String voltage mismatch, strings study". And on the Help "Project design > Array and system losses > Array mismatch losses".

Hi, The detailed losses are different for each variant. Indeed you must redefine them with each new variant. Here is a video tutorial explaining the "detailed losses" tab:

Hi, For the moment this feature is under development. In the meantime you can put an insignificant value or calculate or estimate a value for "Global wiring resistance (mOhm)" or "Loss Fraction at STC (%)"

Hi, Thank you for your comments, indeed we will develop these solutions soon in order to meet the different irrigation criteria.

Hi, The SolarEdge distributed architecture is based on a unique system design approach, characterized by a distributed DC-DC power optimizer for each PV module (or group of PV modules). These optimizers, with a current-driven output, are connected in series as strings, which are then connected in parallel to the input of a special (proprietary) inverter. Each power optimizer can manage 1 to 4 PV modules, and performs the MPP tracking at the input module (or group of modules) level. The specificity of the SolarEdge inverters is that the voltage of the full optimizers string is fixed (usually 350V or 700V for most inverters), so that the current of the whole string (i.e. each optimizer output) is imposed according to the available PV power at Pmpp of each input module. During the simulation, the efficiency of each optimizer is evaluated. It depends on the Current boost ratio (the longer optimizer string, the lower efficiency). Operating at a fixed voltage means that the Power Optimizers in a string operate completely independently one from the other, so that at a given time the module productions may be different without any effect on the system (shadings, mismatch, different orientations, etc). In PVsyst this requires a very special procedure for the elaboration and sizing of the system. You should first define the system, with one sub-array per kind of string (i.e. number of modules in series). Then you should press the button "String configuration" for attributing each specific string to its own inverter. See the help : https://www.pvsyst.com/help/solaredge_architecture.htm?zoom_highlightsub=solaredge https://www.pvsyst.com/help/solaredge_procedure.htm?zoom_highlightsub=solaredge

Hi, Is your problem visible on the entire inverter database or only on an inverter that you have imported/created? If a component is not visible in the drop-down list from the system, this indicates that the component is not fully defined in the database and that it cannot be used for a simulation

Hi, We update the database using the requests of the manufacturers, and publish it with each new issue of PVsyst. We can't of course follow all the new products of all manufacturers in the world. We don't want to include data without the acknowledgement of the manufacturer. Nevertheless you can easily create your own components by yourself. The easiest way is to choose a similar existing device in the database, modify its parameters according to the manufacturer's datasheets, and save it under a new name, therefore creating a new file in your database. For adjusting the parameters you have to open the battery dialog within the software. However for Li-Ion batteries, this is not so simple. For defining a battery pack, you should define a single cell, and then construct the battery pack as an assembly of these cells. Constructing the cell's file requires to avail of detailed datasheets of this cell. And the elaboration of the parameters passes by a detailed analysis of these data (especially the charging / discharging curves).

Hi, The horizon profile may be defined manually by a set of (Azimuth/Height) points in degrees. These may be from on-site measurements (using land-surveyors instruments like compass and inclinometer). They can be imported from several sources: From your workspace: · PVsyst internal file - all horizon files that are saved in your workspace From external files: From web sources directly (requires an active internet connection) Please read :http:// https://www.pvsyst.com/help/horizon_import.htm?zoom_highlightsub=Import+horizon

Hi, The horizon profile may be defined manually by a set of (Azimuth/Height) points in degrees. These may be from on-site measurements (using land-surveyors instruments like compass and inclinometer). They can be imported from several sources: From your workspace: · PVsyst internal file - all horizon files that are saved in your workspace From external files: From web sources directly (requires an active internet connection) Please read :http:// https://www.pvsyst.com/help/horizon_import.htm?zoom_highlightsub=Import+horizon