André Mermoud

Question #1: this is a calculation for one particuler sun position, and by clear day. The fraction for electrical effect is a parameters applied to the shadings along the full year. Question #2: by "regular shades", we consider indeed the bottom shades of the previous sheds in a sheds arrangement. However in your case the sheds are not so regular, as the altitudes seem to be different (you have shades on the 4th shed, but not on the second and the first one). For the evaluation of the "Fraction for electrical loss", you can perform a simulation with Module layout, and a simulation with the shadings "according to strings" with 100%. The ratio between the shading losses of both simulation corresponds indeed to the "fraction for electrical loss" that you have to apply.

The variance of the meteo data multi-year distribution is supposed to be the same for any future year. Therefore the ratio P99/P50 remains the same whatever the year. You can simply calculate P99 (YearN) = P50(YearN) * P99/P50 (Year0)

On this part of the report, the calculated average mentioned on the report is indeed the average of the soiling factors, not the soiling losses. It is not weighted by the effective irradiation. This indeed doesn't have much meaning when the soiling is highly inhomogeneous along the months. However in the simulation, the soiling loss is calculated at each hour, according to the irradiance. It is quite correct.

I really don't understand what you mean. The GlobInc value is the result of the transposition on the tilted plane, it doesn't include the soiling losses. The soiling losses are taken into account in the GlobEff result (effective irradiance on the collectors). NB: The GlobInc is not an average, it is a cumulated energy.

No problem. This is quite well addressed by the PVsyst simulation. You don't mention the order of magnitude of the discrepancies between your blocks, but when the DC:AC ratios are not too high, the overload losses are only slightly dependent on the PV nominal power. You can simply try to simulate a simple system, with your different blocks independently, for the evaluation of the overload loss in each case.

I don't know. The discrepancy is 0.12%, on a bifacial contribution of 5%. I.e. a global discrepancy of 0.006%. This is compltely negligible. This is not necessarily related to the option "according to module strings". We observe sometimes little differences in the simulations, often related to rounding errors. Except in some cases, we usually don't investigate discrepancies lower than 0.1% in yearly simulations.

I don't know. Please send us your whole project, using "Files => Export project" in the main menu. e-mail: support@pvsyst.com.

Sorry, with the bi-facial model presently implemented in PVsyst, you cannot define a bifacial system with several orientations. This will be possible in the next version 8.0.0.

The grid limitation principles are fully explained in the help " Project design > Grid-connected system definition > Grid power limitation" Now I don't have any knowing of the fact that E_Grid exceeds the grid limitation. Please send an example-project. In the previous post, it was not the E_Grid, but the EOutInv value which exceeds the grid limitation.

Yes, this is possible as an approximation, when your system is not too uneven. NB: if you have warnings (for example axis tilt differences too high) you may modify the limits in the advanced parameters.

When you want to evaluated the irradiance on the ground, you will use the Biacial option. In the bifacial system definition, you have this parameter: The ground irradiance calculation will take this parameter into account.

Yes, as soon as you put a component in your workspace, it will appear in the PVsyst lists. In the lists, the components defined externally appear with a grey background.

PVsyst cannot obviously reference all batteries present on the market. You should use a battery with similar characteristics as your battery model. I.e. similar in technology, voltage and capacity. You may also use a "universal" battery, for which you explicitly define the voltage and capacity. NB: the simulation result is not very sensitive to the exact capacity of your battery pack.

These values are a result of the sîmulation. Fixing their value doesn't make sense. When you need energy for feeding your needs during the night, you don't have any solar power at disposal. Your system has to draw this energy from the grid. During the day, your load may need more power than the available PV power at this time: again, the grid will provide the complement. The only way to avoid this would be to store energy in a battery.

Sorry, it is not possible to get such a plot directly from PVsyst. The only way is to create a CSV hourly file during the simulation, including the variable E_Load (or any other desired energy quantity). And then you have to elaborate your plot from these hourly values in EXCEL.

The OND files are meant for internal use within PVsyst. We don't ensure support about them. Exceptionnally, I can say that the Nominal AC power mode (active or apparent) is described by the bit #21 of the flags.

Yes, the DC converters diectly connected to the PV array are not yet implemented in PVsyst. Please have a look on the help " Project design > Grid-connected system definition > Grid systems with storage > Grid storage, system architecture "

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.