André Mermoud

All optimizers have different characteristics, and each one requires a very special development in PVsyst. These developments have been done for some technologies, and rely on parameters specified by the concerned manufacturers. They are not customizable.

I don's see any reason for such an increase of this loss as a function of the temperature. If there is a depency it should be almost unsignificant. This may be an error of the simulation, that we have to analyze in detail. Please send your full project (using "Files > Export project" in the main menu) to support@pvsyst.com.

The LID loss ("Light Induced Degradation") is a phenomenon specific to Crystalline modules (and only with P-type bulk wafers). It is due to the wafer quality, namely traces of oxygen, which recombine with doping atoms during the first hours of exposition. It is not taken into account in the flash-test at the output of the factory, and therefore in the sorting process. Therefore it has to be taken into account in the simulation. The LID loss is sometimes specified in the datasheets, but not very often. When applicable (crysrtalline modules with P-type wafers) the usual value is around 2%, this is the default in PVsyst. Now in PVsyst, you have to define the LID loss explicitely in the "Detailed Losses" dialog. You can choose the value of your PV module if it is specified with the PAN file, or you can ask for the default value. The thin film modules (especially amorphous, but also CdTe to a lower extent) are known to degrade during the 2-3 first months. The "sold" nominal power is indeed the STC performance after stabilization. Therefore there is no additional loss with reaspect to the one-diode model during the simulation. NB: The "gain" before stabilization is not acounted in the simulation, as it is considered as a temporary behavior.

In PVsyst, we consider the light soaking effect as a temporary effect. The "pre-light soaking" period is sufficient short for neglecting it in the annual yield. Nothing is foreseen for taking this initial loss into account.

In the "Orientation " part, this is a rough tool for a quick evaluation of your orientation with respect to the optimal. This quick calculation is based on a simplified model based on the monthly meteo data only, without full accuracy. Moreover, if your meteo data (*.MET file) are not complete year, this tool will use the data defined in the "Project's site. The data on the report are the result of the hourly data simulation, these are the reference results.

Sorry, I don't undertand. In your first mail you talked about a tracking system, and here it seems to be a fixed plane system. Please remain coherent in your requests.

For using Backtracking, you have to define a corresponding 3D scene. The Backtracking parameters (pitch, tracker width) will be defined by your 3D construction.

When you import an ASCII meteo file, the program should know where is is situated, this information is provided by a *.SIT file. And the *.MET file will indeed contain a *.SIT object for its localisation. Now the presence of the *.SIT file in the database is necessary for creating a project. But it is not necessary for using (visualizing) the MET file: you can suppress it in the database if you want (you should manually suppress the file, there is no tool in PVsyst for that).

The backtracking for 2-axis trackers is a very complex problem, and there are several possible different strategies. In the present time, the PVsyst algorithm is quite insufficient, and you are not advised to use it. It only performs the backtracking in azimuth (with tilt set according to the sun's height), and without going to the "north", i.e. blocking the azimuth to values < 90°. When the sun goes to higher azimuths, the backtracking should switch to a backtracing in tilt (i.e. the next tracker sees "above" the preceding one). This is not done in PVsyst as we could not find a suited analytical algorithm. At this stage, one of the problems is: when should the system switch between the azimuth and the tilt strategy? This will induce a discontinuity on the tracking orientation: at a given time, the trackers will suddenly pass from an orientation to another one. With such a behavior, the system should come back to the Azimuth strategy (at values higher than 90°) symmetrically with respect to azimuth = 90° (West or East). Now a second problem arises with multi-rows arrays. In this case we should also implement the backtracking between 2 rows (one behind the other), which even may have a shift in E-W direction. Mixing this with the E-W BT strategy becomes a diabolic problem. We don't see any way of modelling all these behaviours analytically. The only solution would be to implement an ajustment by trys-and-errors, which may become time consuming during the simulation. We did not yet develop such an algorithm in PVsyst up to now.

You can import POA values in PVsyst. PVsyst will use a retro-transposition model for recreating Horizontal global and diffuse values for use in the simulation. Please use "Database > Import ASCII meteo files", and here you have the opportunity of choosing the Plane irradiance in the importing protocol.

The shading scene is a part of the calculation version. If you export a project, it will be included in the calculation versions which involve shadings. The *.SHD files are not associated with a specific project.

If you have already imported a terrain (from a CSV file), you can indeed use the "Zones" for positioning the tables on this terrain. However this works only with a specified pitch. I don't know any software adjusting the pitch table-by-table in order to get a constant limit angle. This seems indeed very difficult to do that on a "random" terrain, as the rows may become completely erratic. I don't know if Helios3D performs this operation, but i don't thinks so. All the helios3D drawings I have seen have perfectly aligned tables. NB: The batch mode allows to vary some specific parameters, not to do everything you could imagine. Each modifiable parameter has to be specifically programmed.

Probably you want to Export from PVsyst, not to Import these data. You can create a csv file of hourly or daily values for any variable of the simulation, for use in another program like MS Excel. Please use the button "Output file" just before performing the simulation. Here you can also specify the units.

I don't understand why the calculation of electrical losses with Module Layout gives a null result, when it is not null with the calculation "according to module strings". There is probably another difference in your simulations. With calculation "according to module strings", the rectangles-strings will be different with portrait and landscape arrangement. And you have obviously a difference also in the Modules layout definition.

The Pac(STC) is indeed used as reference when defining the external transformer losses. See the FAQ How to determine the parameters for External Transfo Losses ? But this is a reference value, not a realistic one. Remember that the STC values concern a run under 25°C. Under 1000 W/m2, the temperature may attain say, 60°, i.e. a loss of roughly 15% ((60°-25°) * 0.44% = 15.44%). Therefore the yield under 1000 W/m2 ad 60° is roughly equivalent to a yield under 1150 W/m2 and 25°C. I am aware that this definition is not very convenient for the evaluation of the transformer losses parameters. We will improve this in a next version. The resistivity of the wires is defined in "Detailed Losses > Ohmic losses > Detailed computations > Wires". It corresponds to pure copper (or alumuînium), but you can change it as you like. The default value is specified in the "Hidden Parameters". The final energy loss evaluation is explained in the FAQ Why the losses in the results are different of those specified ?. This is a pure calculation result of quadratic losses, there is nothing to confirm.

No, this is not possible in the present time. You should do some approximations, or eventually use multi-MPPT inverters.

You are right. For all diffuse calculations (namely integrals for shading or IAM factor), PVsyst assumes the strong hypothesis that the diffuse is isotropic. And the circumsolar, included in the transposed diffuse value, is treated as isotropic in the same way. However these are approximations. A more realistic calculation associating the circumsolar component to the beam component for these treatments would seriously complexify the simulation. Moreover, this component is rather well defined with the Hay model (but not necessarily realistic), but not evident to extract when using the Perez model. Its exact determination is extremeny dependent on the Linke coefficient (especially the aerosols). This approximation may be justified by the fact that the circumsolar contribution is relatively low: in your diagram, it would correspond to the difference between your red and blue points, and for high Kt only. The evaluation of induced errors could be a nice subject for an academic research project.

In thin film modules, each cell is a strip of about 10 mm width, usually on the full size of the module. Now in shading situations, you should put the strips perpendicularly to the potential shades. In this way the shades will affect all the cells of each module in the same way, so that there is no electrical mismatch. Therefore the "Linear shadings" are representative. With thin film modules you should not use the "Partition in Module strings" nor the "Module Layout" options when calculating shading losses. By the way thin film modules usually don't have internal by-pass diodes (no submodules), there is only one diode for the full module. NB: The strips may be along the little or the longer side. This information is not included in the database of PVsyst, you have to refer to the datasheets. This is important for deciding if you put your modules in portrait or in landscape.

Sometimes this doesn't work with Adobe. We don't know why. Please see our FAQ I can't use Acdrobat for creating PDF's

The basic required data for the definition of a PAN file are listed in How to establish the PAN files?. The PNom, STC values and temperature coefficients are always available in the datasheets. The main unknown parameters are the Rshunt and the Rserie, as well as the exponential behavior of Rshunt. If not specified, the default values of PVsyst are: - Rshunt = Vmp / (0.2 * (Isc-Imp)). The 0.2 coefficient may be different for other technologies (0.33 for amorphous). - Rshexp default is 5.5 for all technologies. It should be modified only if explicit measurements of Rshunt at different irradiances are available. - Rsh(0) = Mult * Rshunt. In the present time, Mult = 4 for crystalline and 12 for all other technologies. Perhaps a value of 10 for crystalline modules would be more suitable (observed with many indoor low-light measurements) . - Rserie is determined according to the low-light performance resulting from the model, in order to obtain a relative efficiency of -3% at 200 W/m2. NB: the effect of Rshunt and its irradiance behavior is rather marginal when we set the Rserie value according to low-light performance. Submission of data by manufacturers Now when receiving data from manufacturers, we use to check the following values: - The first requirement is that the Pnom value is close to the Imp * Vmp product. If the difference is greater than 0.2%, we use to redefine Imp = Pnom / Vmpp (therefore Imp is no more in conformity with the datasheet). - All values Rshunt, RshExp, Rsh(0) and Rserie may be left blank, in this case they will be taken at their default value. - If some of these values are explicitely specified (which is not advised without a very deep understanding of these parameters), we only accept them "as such" if the resulting low-light performance is lower than the default. Otherwise we will require a full report of an independent institute, describing complete measurements at 200, 400, 600, 800 and 1000 W/m2 and 25°C. Analysis of the low-light measurements Attenuation filters uncertainties When using a report, we have first to check/correct the irradiance reference data. The problem is indeed that the filters are never perfect. They may have inaccuracies either in irradiance and in spectral response. Then, an error of 1 % on the irradiance means an error of 1% on the relative efficiency (remember that we analyze efficiency differences of fractions of %). For avoiding this problem we can admit the hypothesis that the short circuit current is proportional to the irradiance (including spectral mismatch). From experimental basis, this hypothesis is proposed by the Sandia National Laboratories (USA), as a direct measurement of the incident irradiance. In the "theory", it is the basic hypothesis of the one-diode model. When doing this the efficiency points - sometimes erratic - become very close to the one-diode model results. Low-light report Our techincal report (see below) includes all the file parameters suited for this measured Module. It allows to adjust the Rserie for matching the measurements at best, and identifying namely the relative efficiency to be fixed in the model. The report shows the accuracy of the modele for representing the STC measured points, and provides some additional information, namely about the Rshunt behaviour. The STC parameters shown here are not the parameters of the database, as they correspond only to this specific module under measurements. Setting in the database The main result waited from this report is the low-light performance (quantized by the efficiency at 200 W/m2), which will allow to fix the Rserie value in the database. In the database, we use to keep the values Rshunt and RshExp to their default values. The last graph gives an information about the choice of Rsh(0), and also the pertinence of the RshExp parameter fixed at 5.5. Some manufacturers propose very high values for RshExp (more than 10 or 12), which boosts the global low-light efficiency when the value at 200 W/m2 is fixed. As we observe a good agreement with 5.5 for most of the crysrtalline modules, we will not accept anymore values higher than 5.5. Now in the database, the STC basic values (Vmp, Imp, Voc, Isc) are those of the datasheets, different from the measured values shown here. Therefore the Rserie value will be different for getting the waited 200 W/m2 efficiency. In fact the Rserie has to be adjusted for each power class for getting this 200 W/m2 performance. NB: We use to set the same low-light efficiency for each power class of the modules of a same model. Nothing ensures that this hypothesis is valid (it is probably not the case). However in spite of repeated requests to laboratories, we never got measurements of modules of different power classes nor saw any publication about this subject, so that we don't have any idea of the low-light performance as function of the power (quality of the module). PVsyst technical report for parameter analysis Global fit methodology Some laboratories perform the measurements proposed by the IEC 61863, i.e. at a specified set different irradiances and temperatures (i.e. 22 measurements at 4 temperatures fron 15 to 75°C). And they perform a global fit over all these points, using all the 5 parameters Rshunt, RshExp, Rsh(0), Rserie, muPmpp as variables. Increasing the number of parameters in the fit allows obviously to get a better match at all the measured points. However this fit may be very unstable: intermediate values present hills and valleys, and a little variation of one of the points may lead to a completely different solution. Therefore: - Using the STC basic values (of the datasheets) instead of the measured ones in the model may become irrelevant, - The extrapolation of the measurements of one only module to several power classes becomes very difficult (they use to scale all the the data points and perform the fit again - what is the justification?). - This extrapolation leads to very different low-light performances between different power classes, - Some institutes use the same data set (i.e. measurements of 3 or more modules of the same power), scale the "measured" values according to some algorithms (not described) as a function of the power class desired, and perform the 5-parameters fit on these values for each power class. This doesn't make much sense, as these data are obviously not representative of the real modules of each power class. - Moreover, the Temperature behavior of the Pmpp issued from the global fit may be significantly different from the direct measurement at 1000 W/m2 and 25°C specified on the datasheets. Therefore in a general way, we don't accept the results of these multi-parameters fits for the database, as we don't have a mean for extending it to other modules. The methodology is too different from the standard parameter's choice used by all other manufacturers, and this may lead to irrelevant discrepancies between manufacturers in the simulation results. Therefore when receiving such a report, we treat the original measured data as for other laboratories, using only the low-light data at 25°C, but applying stable and comprehensive methods for the extension to other power classes.

You shouls ask the manufacturer that he takes contact with us for including their devices in the database.

In the present time, the Mismatch tool only works on the basis of random STC distributions (specified by statistical parameters). We have not yet implemented a tool for importing a "real" distribution list of modules.

I don't understand well what you mean. We should take the questions one after the other with more details. 1. - E_Load is the energy needs, E_User is the energy really provided to the user. If you have a back-up generator, it is quite normal that these values are equal. A part comes from the PV, and another part from the Genset. The PV yield is named "E_Avail" (available solar energy). 2. - If you have a back-up generator, if it is sufficient it will fulfill the user's needs in any case. I don't see how your load is not fulfilled with big generators. Please give more information. 3. - The battery size stores the produced energy, but doesn't produce any energy more... If you over-size the battery pack (over, say 5-8 days of autonomy, depending on your climate) you don't have any additional yield: the results will indeed be about the same. Now if the batteries are highly oversized, they may have losses which compensate the storage benefit. In the present time I don't see any dys-functioning in the topics you are mentioning.

The active area of the system is the sum of the PV modules area (as defined in the "system" part). The active area of the 3D shadings part is the area of the "tables"defined. PVsyst requires that you define a sufficient area in the 3D scene for positioning all your modules, this seems quite logical ... The "available area" in the System part is in a frame named "Presizing Help". You can specify here the available area that you have at disposal for installing your PV system if it is known. It will allow PVsyst to warn you when you don't have sufficient room for positioning all the modules you have asked for.

It doesn't make sense to simulate a tracking array without defining the 3D shading scene. - Without backtracking the shade cannot be neglected of course. - With backtracking there is always a shading loss on the diffuse part (see How is calculated the Shading Loss on diffuse with tracking systems ?. Normally with recent versions, PVsyst will prevent you to run a simulation with backtracking and without defining the 3D scene. Now for the irradiance yield (including linear shadings), both strategies are usually rather equivalent. The electrical losses present in the not-backtracking system may do the difference (especially with narrow trackers, here with only 2 modules in the width).