André Mermoud

The instantaneous powers are not appearing on the report. You can get the E_Grid values in case of overload by creating a CSV file of hourly data (button "Advanced parameters => Output file" and analyse the hourly data when the inverters operate in overload conditions.

This is obviously the main result of the PVsyst simulation. However you have to define the parameters of these losses in the "Detailed Losses" section. For the results, see the Loss diagram.

The Rserie adjustment is indeed the main parameter that manages the low-light behaviour. You can adjust it for getting the desired low-light performance, i.e. matching your experimental points if available. NB: If you are in the page "Additional data => Measured low-light data", this is a tool for importing the detailed measurements concerning your module. This tool is an independent help, the parameters you set here are not the parameters of the PAN file. The PAN file may have different STC values, and when you exit this tool PVsyst will ask if you want to keep the low-light performance of the model established here. If so, as the STC are different the paramerers RSerie and RShunt suited for the PAN file may be different as in this tool.

This is not possible in PVsyst in the present time. This is indeed not pertinent in most cases: why charging the battery if power is available from the grid when necessary ? Now there may be particular cases where this cous be useful. For example: - in case of very weak grid, it could be useful for keeping a minimum of charge in the battery, for ensuring consumption in case of grid failure. - If you want to store energy during low tariff period, for restituting it during high tarif period. However this may be done in any system, even without a PV production. This is not considered in PVsyst.

The calculation sequence is as shown on the loss diagram. For getting the values and acronyms in EXCEL, you can open the report, Menu "Export > Loss diagram values". You will get a table to be pasted in EXCEL: Here you can see the flow of the calculation of the energies. The GlobBak value is accounted after taking the rear shading losses into account. Now the problem of measuring this value on-site is really difficult. The irradiance received by the backside is highly dependent on the position in the table (top to bottom in sheds, or from axis to edge in a tracker). There is no real consensus about how to measure this value on-site. Please see the help "Project design > Results > Performance Ratio" for a more detailed discussion of this problem.

Yes, you can indeed define any kind of customized plot to be accumulated during the simulation. In the project's dialog, please open "Advanced simulation > Special graphs". Now for your case a much better way would be to create a CSV file of Hourly values, that you can manage in EXCEL. For this open "Advanced simulation > Output file". Here you can choose any variable among the 100+ variables of the simuation.

I had asked the project because I had a doubt about the E_Grid and EOutInv values, on the 05/06/90 10:00 .. 14:00 records. Normally, PVsyst calculates the production during the best hour of the best clear day of the year (according to the clear sky model), for an advice about the sizing of the PNom you should define for your inverters. You have indeed specified your inverters pack using this value (374 MW), and this is “a priori” correct. With this definition, we expect that the real production exceeds the PNom value only very exceptionally. In your case, it exceeds it during 5 consecutive hours, which I found very suspect. This is the reason why I asked for checking the input meteo data – which seem indeed excellent. With your project I found the explanation: you have defined a bifacial system, so that the real power may exceed this PNom value. I had not anticipated this possibility when defining the “Max. output power (clear sky)” value. This should be done in a future version.

This is quite normal, and fully explained in the help “Project design > Grid-connected system definition > Power Factor”. Your inverter PNom is very probably specified in terms of Apparent power [kVA]. In the “output parameters” page you should have: Therefore if you are operating with CosPhi = 1, the PNom will be 2155 kW, but if you operate with a power factor of 0.95, the power limit will be Pnom = 2155 kVA, corresponding to an active power = 1048 kW. This doesn’t represent an explicit loss, therefore this doesn’t appear on the loss diagram. However you will se a difference in the overload losses.

I don't see well what you want to do. For such an approximation, you can use the Input/Output diagram as reference (draw E_Grid as a function of GlobInc). Without power overload, this should fit this distribution with a rather well defined straight line. You will have a dispersion of points, depending namely of the array temperature. You should apply the temperature model for the array temperature, based on the ambient temperature. If you apply the temperature loss to each hourly point, you should probably reduce the dispersion.

First question: this shading Module Layout calculations from the I/V curves is explicitly done at each step of the simulation. The effect of the partial shadings on the whole array is fully explained by the I/V curves. Second question: in this case the "Linear shading" (irradiance deficit) is 0.4%, and the electrical loss is null. The repartition between Linear and Electrical losses is not always quite reliable, as the linear shading loss is calculated globally for all tables of the concerned orientation, when this electrical calculation concerns one MPPT input. But the global loss is correctly calculated.

PVsyst doesn't treat the integrated storage systems (all-in one hybrid systems). It needs to specify the battery pack, the charging and discharging properties independently. As I understand, you have datasheets for 2 battery systems: the BF100 series (with 3 different capacities) and the Powerstone. The Powerstone is an assembly of 15 battery modules, but I really don't understand their definition: the voltage is specified as 512V for 100 Ah. This means an energy storage of 51.2 kWh. I suspect that there is an error on the datasheet, the voltage should be 51.2 V. I will include these batteries in the database for the next version of PVsyst.

The Module Layout calculation is based on the effect of shades on each submodule (i.e. set of cells protected by one by-pass diode). Therefore the submodules layout within the PVmodule should be well defined. The Module Layout calculation is only develoed for standard modules, with submodules "In length", or twin half-cut cells. See the help "Physical models used > PV Module - Standard one-diode-model > PVModule Structure > SubModules layout". The Voltec modules have a very exotic internal organization and connexion of cells, you cannot use them for the Modulelayout calculation.

The Inverter nominal power is a property of the Inverter that you have used. The Clear sky model is based on the geographic situation of your system (latitude, longitude, altitude). It doesn't depend on your weather data. Your weather data seem indeed to be quite correct. I don't know why you have such overload losses above the calculated maximum Clear sky power value. Please send us your full project, using "Files => Export project" in the main menu (e-mail support@pvsyst.com).

You should be aware that the calculation of the State of Charge (SOC) of the battery is extremely difficult and uncertain. This depends on the effective capacity of the battery pack, which itself depends on the instantaneous current (charging/discharging rate), temperature, possibly effective SOC at this time, etc. Keeping all these parameters into account in an instantaneous way leads to very strange and erratic charging/discharging balances along the day (or the year), especially when the discharging conditions are highly varying, which is the case in Peak shaving Therefore we had to find a compromise, by evaluating the effective average capacity during the discharging phase, and keeping this average for the calculation during the next charging. This works rather well for long-term balances. Moreover the Charging/Discharging current relation to the energy is dependent on the battery voltage, which is itself a function of the current (through the internal resistance), the battery efficiency, the SOC, the temperature). It is probably this contribution which involves little negative balances (-1.7%) in your hourly results. NB: You have defined a PNom of the inverters equal to the Max. power as calculated from the clear sky model (374 MW). Now you have several hours exceeding this power. To my opinion, this means that your climatic data are far above the clear sky model. Please check them.

As i said, this is not yet implemented, but on our roadmap.

The basic irradiation used for the PR evaluation is GlobInc, not GlobHor. I.e. the global incident on the collector plane. This is the irradiance value after the transposition. For example, in your first system: GlobInc = GlobHor * (1 + Global in collector coefficient) = 1994 kWh/m2 * 118.2 % = 2357 kWh/m2 This GlobInc value is also available on the monthly table.

First of all: the simulation with 2 different kinds of orientation (tracking and fixed planes) will be possible with the version 8, to be released within some few months. Now for getting a merged performance ratio betweem 2 different simulations, you should come back to the PR basic definition (cf Help "Project design > Results > Performance Ratio"): PR = E_Grid / (GlobInc * PnomPV) You shoud add each components from both projects: PR (glob) = (E_Grid1 + E_Grid2) / (GlobInc1 * PNomPV1 + GlobInc2 * PNomPV2).

In the yearly simulation, the initial battery state has almost no impact on the yearly results. Now the initial state is a choice of PVsyst. There is no reason to suppose 90%, 100% or 10%. However this initial SOC may be modified in the advanced parameters. In the main menu, please open "Settings => Edit advanced parameters => Batteries", iten 301 "Initial SOC for simulation".

In your Subarrays definitions, you have defined 3 MPPT in each sub-array. If so, you should indeed define at least 3 strings in each subarray. Now in your case you have one string per Subarray, so that should define one MPPT input in each subarray.

The "Powr setpoints" that you mention here is indeed the limit nominal power for this MPPT input. This is not fixed in the inverter. This is the result of the "Power sharing" calculation by PVsyst, for ensuring that the PNom of the whole inverter is the sum pf the PNom of each MPPT input (according to their own number of PV modules). Answers to your questions: 1. During the simulation, each MPPT input is supposed to have a PNom corresponding to the value listed here. In the real system the limitation will be the Pnom for the whole inverter. 2. If you have MPPTs with, for example, 1 and 2 strings, you should always make sure that the Power sharing is activated. If all MPPT inputs of an inverter are within a same subarray, you should uncheck the option "Use Multi-MPPT feature". If the inverter inputs are distributed on several subarrays, you should use this tool for Power sharing.

Yes of course, this is what I explained above.

The tracking angle optimization doesn't work with diffuse thresholds. At each time step, the simulation evaluates the optimal tracking angle on the basis of the transposition model: the angle is adjusted in order to get the best transposition result GlobInc, considering the Beam and Diffuse components.

In the "System" dialog presizing tool, the specified area is the modules area (the sum of all modules), not the ground occupation.

PVsyst applies the default values (for getting -3% relative efficiency @200W/m2) to the PV modules of the internal database for which the Rserie is not defined. Now for the PAN files defined by the users, this doesn't make sense: the user should be able to define its own Resistance values. Therefore PVsyst doesn't modify these values anymore, except when these are not compatible with the one-diode model (i.e. Rserie > RsMax).

Sorry, this is an error in the translation tool. The first sentence should be read as "The PV array operating voltage (XX V) is over the required voltage for direct charging (YY V)" This will be corrected in a next version.