André Mermoud

This calculation "according to strings" corresponds to an upper limit of the possible shading for each specified string. A "Fraction for Electrical effect" of 100% means that the full beam component is lost when the rectangle si shaded. A value higher than 100% would mean that more irradiance than the beam would be lost, which doesn't make sense.

The Voc(Tmin) requirement corresponds to a safety requirement. The procedure used in PVsyst for the evaluation of the max. voltage is a universal common practice, adopted by everyone in the PV community (not only PVsyst). We will certainly not modify this procedure. See the FAQ How to adjust the design temperatures ?.

This "Ground reflexion on front side" contribution had to be introduced with the bi-facial mode. It is due to the reflexion of the ground just between each row of collectors. It is mainly dependent on the tilt (low tilts will give lower contributions). This was quite necessary especially for the treatment of vertical bi-facial systems. It is also related to the pitch, as with big pitches, the contributing area in front of the PV table is higher. You can do some trials for this estimation in different situations. NB: This contribution is theoretically also present in usual not-bifacial systems. However it has always been neglected, as the calculation is quite complex, it requires all the hypothesis of the bi-facial systems - definition of the ground albedo, the geometry, etc. We were not aware of it until working on bi-facial systems. I doubt that any other PV simulation software takes this contribution into account and calculates it accurately.

The "Unbalanced" feature is a very special mode, only available for 2 MPPT imputs with very dissymetric inputs. When you have more than 2 MPPT inputs, you cannot define this mode and its very specific behaviour. But you can always define Sub-arrays of different powers on each MPPT. In this case you should use the "Power sharing" option for attributing a given PNom to each MPPT input. See the help "Project design > Grid-connected system definition > Multi-MPPT inverters: power sharing" for further details.

The back-up current is specified for your system, as a property (setting) of the back-up generator. It is specified in the "System" dialog, page "Genset". It is supposed to be constant at any time, when the genset is activated.

Th PNom limitation is applied on the apparent energy, therefore earlier. This is fully explained in the help "Project design > Grid-connected system definition > Power Factor"

The errors are of the order of 0.016% of EApGrid. This is a rounding effect of course (pro^bably on your Cos(Phi) value).

I don't see any difference in the program. Please check that both simulations use the same Transposition model, and exactly the same meteo data file.

The beam is an average irradiance over for the whole hour. Therfore PVsyst calculates the duration for which the sun is below the horizon line, and the duration over. The beam component is accounted for the duration above the horizon.

The albedo involved in the bi-facial calculation is the albedo of the ground surface "seen" by the collectors, just below the installation of course.

The PVGIS old database in monthly values in no more maintained. The owners (JRC) announced that it would be unavailable in November 2018, so that we removed the import from this source. If you want to import these monthly data you have to do that manually in "Databases > Geographic sites". PVsyst has now a powerful tool for importing the new PVGIS databases, for an highly exteded geographic region and in hourly values. Please see the help.

You should ask the manufacturers/providers, and tell them to take contact with us for updating the database. However 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 Crystalline modules, except Isc, Vco, Impp and Vmpp, nb of cells in series and module sizes, you can let all the other parameters (mainly Rserie, Rshunt, Rsh(0) and RshExp) at their default value. You have a checkbox near to each parameter for retrieving the values proposed by PVsyst.

Our next improvement for Bi-facial will concern the vertical systems, which need to deeply review the Transposition model, especially for the circumsolar component. However this doesn't affect the usual calculations (reasonable tilts < 40°). We don't have any indication that the model has to be revised. Several studies with experimental data are on the way, and don't indicate that the bifacial gains are strongly under-evaluated in the unlimited sheds (or trackers) hypothesis. The treatment of "single sheds" will not be available before several months.

This problem has been corrected for the next version 6.79. In the meantime, please simply avoid using the checkBox "Default from inverter".

Sorry, this bug arises in the version 6.78, only in the loss diagram with Grid limitation (slight error in the evaluation of EOut Inverter). The final result is correct. It has been corrected for the next version 6.79.

Please explain what you think is a bug in the "Produced energy". This normalized way of presenting the simulation data is indeed not well-suited for Bi-facial systems. The additional energy (bifacial gain) is indeed added to the Ya value, i.e. deduced from the array losses La. If sufficient, it could indeed lead to negative La values, and even PR values greater than one. However I don't know any official definition of these normalized variables for describing the bi-facial systems.

This tool is suited for the analysis of Measured data on an existing system, for comparing the System performance (for example E_Grid) to the simulated values. It will create a *.DAM file for the comparison tool. If you want to import Meteorological data for using in a simulation (creating *.MET files), you should use "Databases > Import ASCII Meteo file".

You are right. The "Array nominal energy" is indeed a new intermediate calculation (introduced in V 6.77) , which was not correctly calculated for Mixed Orientation in the versions 6.77 and 6.78. This will be corrected in the version 6.79, to be released within about 2 weeks. This only affects the losses expressed as a percentage in the loss diagram (up to EArray at MPP). The simulation results are quite correct. NB: In the meantime If you need a correct report, the can download the version 6.76 from our web site www.pvsyst.com, and install it in parallel with your exiting version. Both versions may by used without interaction.

Thank you for these reports of bugs and propositions. They have indeed been corrected for the next version 6.79.

PVsyst doesn't treat this case. It is extremely difficult as the reflexions are peculiar, so that the backside will be ununiformly irradiated. Remember that the current of a string is driven by the current of the worst irradiated cell. Moreover, this calculation would require a very accurate description of the reflectors, and would be very specific to this geometry.

If all your strings are identical (same number of modules in series), you should uncheck the case "Use multi-MPPT feature". The simulation will consider each inverter as a whole and will not share the Pnom on the MPPT inputs. Another way is to redefine your inverter as a 4-MPPT input device.

Please think globally. When keeping the battery charged and using the rest of the PVproduction, you have indeed less Unused energy at this time. But during the next night you will discharge the battery to a lesser extent (higher DOD) than if it was discharged during this episod. This means that during the next day you will reach the full charge earlier, and therefore have more unused energy. Globally, over a long period and if you don't reach the Loss-of-load, you cannot produce more energy than what you consume (neglecting the losses in the battery). This is the first principle of the thermodynamics: the conservation of the energy.

Basically the efficiency is the ratio of the produced electrical power, divided by the input power (irradiance). Therefore the efficiency of a PV module at STC will be : Effic = 0.001 * PNom [Wp] / Module Area [m2]. - The nominator is a power at STC - The denominator is indeed the STC Irradiance across the module area, i.e. 1000 W/m2 * Module Area [m2], which explains the units. Now we have different possibilities of defining the module area: - The Gross area is from the module's sizes: Length * Width. This includes the frame and spacing between cells. This is the most usual, always available in the database. - The Sensitive area may be defined in the PVsyst database, when defining the cell's area (facultative). In this case the module's sensitive area = NbCells * Cell area. This will lead to another efficiency related to the sensitive area, characteristic of the cell's technology. - In some cases we can define Tile modules (with mutual covering). In this case PVsyst defines the sizes of the "apparent" area for the evaluation of the efficiency. Use of the Efficiency The efficiency is never used in the calculations: in any electrical calculations (simulations, etc), PVsyst uses the "One diode model". The efficiency is only an indicator for display. In the Loss diagram, the mentioned efficiency is related to the Gross area of the PV system (sum of all modules), which is also mentioned on the plot. It allows to get a quick check of the "Array Nominal Energy at STC": EArrNom = GlobEff * System Area * Efficiency[%]/100 NB: The performance ratio (PR) doesn't depend on the efficiency in any way, as it is normalized to the Pnom value. If you have a better efficiency, you will have a better yield but a higher PNom at the denominator. Effects of the area on shadings The only part where the distinction of module area versus sensitive area could have an effect, is the calculation of the shadings. In PVsyst the fraction of light lost due to direct shadings is calculated by determining the shaded fraction on the PV surfaces in the 3D drawing (blue rectangles and polygons). These include typically the frames and spacings between PV modules. In some rare cases, this can lead to very small deviations, e.g. when the shadow touches only the frames. We deem that these deviations have no significant effect on the simulation results.

We cannot say anything without more information. Please send your whole project to support@pvsyst.com, in order that we can analyze the problem.

The ageing tool uses a "Monte-Carlo" method for the evaluation of the Mismatch loss parameter evolution along the years. The "Monte-carlo" method is a random process, which gives a different result at each execution. See the help "Project design > Array and system losses > Ageing, PV modules degradation".