André Mermoud

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).

No sorry, this is not yet possible in PVsyst. You cannot import POA from a tracking solarimeter. We intend to implement this opportunity in a next version.

I don't understand well the question. The orientation doesn't change during the simulation (during the year). But the Optimal orientation is depending on the period you consider for the optimization. In some situations, you may want to optimize the winter performance, not to get the higher irradiation during the whole year.

No, in PVsyst all the trackers have the same orientation at a given time.

Sorry, this was a limit which seemed reasonable when I wrote this dialog. I have diminished it for the next version 6.44. However this limit is not very significant (only used for sizing conditions).

In any version of PVsyst, you can define pairs of (Azimuth, Height) as you like (not necessarily with identical azimuth steps). Usually points spaced by 5-10° (or following the significant points of your horizon) are largely sufficient. For diffuse calculations, you are advised to define the horizon all around the site (azimuth -180 .. 180°). In the version 4, the number of points was limited. Some software gave horizon with 1 point every degree, which is completely useless. In these cases PVsyst reduced the number of points by performing some averages.

This is not yet implemented. See our FAQ How can i include an inverter in a stand-alone system?

Yes you can only define 2 different orientations for seasonal tilt. It is a limitation of PVsyst. You have to construct your 3D construction with the summer tilt.

The PV module tolerance is used as default value in a project. You can put here any value. Therefore this value is not of big importance: you can choose it as you like. See our FAQ How to define the "Module Qualits Loss" parameter?. At the time of the version 5, most of the modules were specified with -/+ tolerance (usually -/+ 3%). Therefore a loss of half the lower value (1.5%) was pertinent. Positive sorting appeared more recently on the market. This is the reason why this definition had to be updated.

I can't understand that. Please make sure that you have clicked "Show all available meteos".

The unlimited option has not been developed for trackers up to now.

They are not yet implemented yet. This will probably be done in the version 6.45, within some few months. In the mean time, you can define an equivalent pack (in terms of capacity) of existing Lead-acid batteries: the simulation will be very similar.

I don't know the format of the PV*SOL horizon files, but in PVsyst you can simply create a CSV file of (Azimuth, Height) pairs values. See the help for the exact format. Now defining points every degree doesn't make sense. If so, PVsyst will "simplify" the horizon line by eliminating the unnecessary points, in order to get a max. of 120 points.

The EArrRef is the STC energy according to the "nameplate" reference power of the modules. This value is used as reference for the PR calculation. The EArrNom is the result of the one-diode model at STC. It should be the same, but may have a slightly higher value than the EArrRef. It is used as starting point in the Array Loss diagram. See our FAQ Why is the Pmpp of my module different than the specified value ?

This is an estimation. I have done some "experiments" with the Mismatch tool, using different PV modules distribution values from "out of factory" STC data and usual tolerance. However it is not easy to determine a number valid for any situation. Now most of other software take 2% as default value. You can also ask them why.

The "Back-tracking" strategy and the "shadings" strategy are usually relatively equivalent, as you intercept the same tube of light. What you loose as shadings with the latter case, you loose it as incidence orientation loss with the Backtracking. Now this equivalence is not strict. It may be slightly different according to other parameters (like GCR, axis tilt, number of trackers, etc). I don't understand well your statement. See our FAQ Which gain can I expect from Backtrackintg strategy ?

Nothing prevents you to use a google image for the definition of the horizon, if you can define the "horizontal line" (here the lake) on the photography. Without this reference it would be more difficult. Now if you avail of ground measured data, they already include the horizon effect. If these are hourly data, there is no real problem: you will not take an horizon line into account in the simulation. But if these are monthly values, the hourly data should be created using the synthetic generation, and this model "ignores" the horizon line. Please see our FAQ How to deal with meteo data which include horizon loss ?

This problem appeared in the version 6.43. We have corrected it for the next version 6.44.

I don't know how it could work in the version 6.38, as we never implemented this opportunity. We intend to do so in a rather near future.

The calculations of shadings in PVsyst don't indeed like the "holes" in the shading objects. Therefore you are advised to define fences as 1 or two long parallelepipeds (and define them as thin objects). The result will be the same. The vertical poles of the fences don't contribute significantly.