André Mermoud

The "Low-light efficiency" is mainly dependent on the Rserie and Rshunt (exponential behaviour) parameters (as well as di²MuTau for amorphous technology). Rserie impact The loss goes with the square of the current (Rs * I²), therefore increasing quadratically with power. Take now a module designed for an irradiance under 100 W/m2: if the Rserie is high (bad), the losses are higher at high irradiances (orange curve). Now the characteristics of the module you buy is specified at STC. Therefore if you want to design a module of the same Power at STC as your "good" module, this new module with high Rseries should be globally of better quality at low irradiances: Therefore a module of same STC performance, but with bad Rseries will give better low-light performances ! In other words: the module is globally of much better quality, but the high Rserie value penalizes the STC performances. Rshunt impact The shunt resistance at STC has a very low impact on the Low-light efficiency. However the exponential behavior as function of the irradiance will decrease the Rshunt loss, and therefore enhance the efficiencies under 400 W/m². The picture shows the case of a crystalline module, with a dynamics Rsh(0) / Rsh(STC) of 4. However the amorphous modules have a much lower Rshunt at STC, and a much higher dynamic Rsh(0) / Rsh(STC) of around 12. The figure shows that the efficiency difference would be significant between different Rshunt if they were constant. But the recovery of the exponential behavior leads to very similar curves. Therefore the recovery of low-light efficiency is better with low Rshunts and high exponential dynamics.

The Rserie specified in the parameters of the module is not the measured Rserie dV/dI, but the intrinsic Rserie of the one-diode model. It doesn't include the exponential contribution that you see on the graph below. In the PV module's parameters dialog, the measured value dV/dI, named "Apparent Rserie" is mentioned just below this value in the program. When the Rserie is specified by manufacturers (as "measured Rserie"), it corresponds to this "apparent" value. I/V curve with Rshunt and Rserie

The model implemented in PVsyst includes a spectral correction for amorphous modules, but not for crystalline nor other technologies. The correction for amorphous modules is based on a parametrization as a function of air mass and Kt proposed by Betts and al "SPECTRAL IRRADIANCE CORRECTION FOR PV SYSTEM YIELD CALCULATIONS", 19th European Photovoltaic Solar Energy Conference, 7-11 June 2004, Paris, France. According to my own experiments, when putting amorphous modules (tandem or tripple juction) at sun, recording one I/V curve every 10 minutes, and applying the one-diode model to each measurement, the errors Pmpp (measure-model) have RMSD of the order of 2.3% of Pnom over a full year (i.e. under any irradiance and temperature conditions). Without applying the spectral correction, this RMSD increases by about 0.6%, which is therefore the order of magnitude of the spectral effect over a full year for this amorphous module. (see my article "Performance assessment of a simulation model for PV modules of any available technology", Mermoud, A. & Lejeune, T., 2010, 25-th European Photovoltaic Solar Energy Conference and Exhibition (EU PVSEC), Valencia, Spain, 6-10 september 2010) For crystalline modules, the sensitivity to the spectral variations according to weather are rather small (see the conclusions of the article of Betts). My measurements show errors Pmpp (measure-model) with a RMSD of the order of 1.2% of Pnom over a full year, in any irradiance and temperatures conditions. And still less for CIS (RMSD = 1% over 6 years!). Therefore if a spectral corrections has to be applied, it would be within this 1% to 1.2 % dispersion. Now the one-diode model is based on the STC performances, which are specified for an AM1.5 spectrum. The eventual variations of spectrum along the year would be around this STC Pmpp value. But who knows exactly the spectral contents of the irradiance for any weather (and especially the covered conditions), except through Air mass and Kt correlations ? NB: The Sandia model does indeed define a spectral correction for crystalline modules, as a correlation by respect to the Air mass (therefore valid for clear sky conditions). Applied to simulations in middle-Europe, this induces a spectral gain of the order of 0.4 to 0.5% over the year. However this correlation is probably over-estimated during the simulation, because it is not related to the clearness index Kt, so that it is applied identically to cloudy conditions.

The Pmpp value calculated by the one-diode model in PVsyst may be different from the Nameplate value. Indeed you have 3 values which may all be different: - Pnom (nameplate), - specified Vmpp*Impp at STC, - Vmpp*Impp as computed by the model at STC. - The Nameplate Pmpp is sometimes not equal to the Impp*Vmpp as specified by the manufacturer at STC. Since recently, some manufacturers include the positive sorting in the STC values. That is, for a given nameplate module, they define STC Vmpp*Impp values superior by 1-3%. This of course distorts the interpretation of the PR in the simulation results (produces an artifical increase of the PR). In the database of PVsyst, we don't accept a discrepancy (PNom - Imp*Vmp(STC)) higher than 0.2%, and we correct the Imp value in order to get the exact Pnom (some old modules may have not been corrected). In the versions >= 6.39, you have an information when a discrepancy occurs. And the modules imported from PHOTON are corrected in this way. - The Impp*Vmpp calculated by the one-diode model at STC may be higher than the Imp*Vmp specified value. Indeed, the model is established for passing the I/V (or P/V) curve through the 3 specified points (0,Isc), (Vmp, Imp), (Voc,0). Now, nothing ensures that the specidied (Vmp,Imp) point is the true maximum of this P/V curve. If the true maximum is different, it will of course be higher. This discrepancy may be sometimes up to 1% ! This last effect could be considered as a weakness of the one-diode model: the model doesn't reproduce the exact I/V curve shape of the manufacturer. But more likely this indicates that the manufacturer's specifications are not correct! For establishing their datasheets, manufacturere usually avail of the mesurements of one set or identical modules (of very close powers). We don't know how they extend the (Vmp, Imp) specifications to the other power classes. According to the matching of most modules, we consider that the one-diode model is reliable in this respect. NB: in the PV module definition dialog, when pointing the mouse on the PNom value, all 3 values will be displayed. Effect on the PR and the Specific production The PR (Performance ratio) is related to the Pmpp(STC) value. The "official" definition (as shown on the results page) uses the Nameplate value PNom. But if you evaluate the PR from the simulation results (e.g. the loss diagram), it will involve the Pmpp of the module at STC, as computed by the one-diode model. The PR will be increased in the same proportion as the ratio Pmpp (Model)/Pmpp(Nameplate).

The temperature Coefficient of the open circuit voltage muVoc is not an input parameter, it is a result of the one-diode model. It is closely related to the choice of the Rserie value. You could try to choose the RSerie value giving your specified coefficient, but it is not always possible (the Rserie values may be out of its allowed range "0 to Rsmax"), and it is not a good idea, as other criteria are much more significant for the choice of Rserie (namely the low-light efficiency). NB: Rsmax is the maximun possible value allowing the curve to pass through the 3 reference points (i.e. solving the equations). It is not possible to adjust at the same time a specidfied muPmpp value (temperature coefficient on Pmpp) and muVoc. This is a property of the one-diode model. And the muPmpp value is very important, as it is involved in the operation during the simulation. While the muVoc is not implied in the simulation process. It essentially acts on the sizing limit for the determination of the maximum possible voltage (which should not overcome the VmaxAbs of the inverter, nor the Vmax of the modules, for the lower design temperature conditions). You have the choice of using two different values during the system sizing: - by default, the muVco as result of the model (which depends on the temperature) - if you define the muVoc as specified by the manufacturer in the module's parameters, you can ask for using this value during the sizing process ("Project's settings" button in the project's dialog) NB: you will find the "manufacturer" specification for muVoc value in the PV module definition dialog, page "Additional data > Secondary parameter" NB: In some special conditions (namely with modules specified with a very low gamma value, i.e. Rseries very close to its maximum), for calculation reasons the the lower value of the diode saturation current is limited to 0.1 pA. This limit is sometimes attained with very low temperatures (< 0°C), which leads to positive muVco values. Don't worry: the model still works correctly, only the temperature behavior below this temperature is slightly affected ! We are here at the boundaries of the one-diode model. If you want to decrease this low-temperature limit behaviour, you should increase a little bit the Voc (STC) value, and readjust the Rserie for getting the equivalent Low-light behaviour. This will result is a more robust model.

For amorphous modelling, I have performed a research project for determining the better way to model this technology. Comparing model results with long-term module measurements at sun, in any irradiance and temperature conditions, I have found that we can use the standard one-diode model, with 3 corrections: - The Rshunt resistance (inverse of the slope around Isc) has an exponential-like behavior according to Irradiance. This partly explains the better yields of amorphous at low irradiance. - One should add a specific term for taking the recombination loss in the -i- layer into account. This acts mainly on the Voltage (especially Voc), but has a significant implication on the thermal behaviour of Pmpp. If this is not sufficient for retrieving the manufacturer's temperature specification on Pmpp, sometimes we have still to adjust the gamma thermal behaviour for obtaining the required muPmpp (but is it really correct ?). - PVsyst also applies a spectral correction as a function of Air Mass and Clearness Index Kt which has been proposed by the University of Loughborough. See the publications Mermoud 2010 and Mermoud 2005 (in french) on our web site. NB: To my opinion (and according to this model), the improvement of performance at low irradiances is not related to diffuse spectral effects (as stated by many manufacturers) , but essentially to electrical effects like exponential behaviour of the Rshunt as function of irradiance, and high Rserie values which induces losses going with the square of the current).

The main basic parameter of the inverter is the Nominal AC power Pnom, that is the maximum power the inverter is able to deliver to the grid in any conditions. Some manufacturers specify also a Maximum AC power Pmax, as a power which may be attained in specific conditions. They usually have a vague criteria like for example "during half an hour". To our understanding, this is related to the internal temperature of the device. However PVsyst has no mean for the determination of this internal temperature (which would require to describe the whole environment of the inverter in great detail), and therefore in the present time it cannot use this information. In other words, PVsyst doesn't take the Pmax value into account, this may be considered as a "bonus" diminishing the overpower losses issued from the simulation. Model: Maximum power attainable as function of the internal device temperature

The Power threshold of most inverters is of the order of 1% or less of Pnom. In the version 5, PVsyst fixes a limit at 0.5%. Many manufacturers contest this limit. In the version 6, this limit is only required when PVsyst has to build an automatic efficiency profile from the Effmax and EffEURO parameters. In irradiance terms, 0.5% of 1000 W/m2 corresponds to 5 W/m2. Now by very covered weather you have still an irradiance of about 30 to 50 W/m2! Therefore this 0.5% threshold is far below the lower irradiances you can observe in the reality ! And even if you would recover a little power below this threshold, it would represent a negligible amount of energy along the year. In the final results of PVsyst (loss diagram), the loss below the threshold is referenced as "Inverter loss due to power threshold". This is usually 0.0% (i.e. less than 0.05%). You can do the exercise of increasing the Power threshold of your inverter, to see when this loss becomes significant (attains 0.1 %) !

The sizing tool (available by the button "Show sizing" when defining the system), is based on a simplified calculation of the Array power distribution, which is computed at an hypothetic temperature and doesn't include all losses of the system. Therefore the loss of the simulation (which is the reference) is usually lower that the loss at the design time. Sometimes you can also have significantly higher (unexpected) losses during the simulation; this arises when the voltage of the overpower point is greater than the inverter's maximum Vmpp voltage. This situation is not taken into account in the pre-sizing tool (where we don't have a reliable value of the array voltage). Now when your definition of the sub-array implies different numbers of strings on the inverter's inputs (i.e. number of strings not divisible by the number of MPPT inputs): - In the version 5, the calculation was done globally for the whole sub-array, and the number of strings was averaged (for example 21 strings on 6 inverters: the simulation assuned 3.5 strings on each inverter. => the sizing result for overpower is coherent with the simulation. - In the version 6, the calculation is performed for each inverter independently, and some inverters may operate in overpower conditions. With our example: 3 inverters with 3 strings, and 3 inverters with 4 strings: in this particular case, the PNom ratio is 1.19 for the average (quite acceptable), but 1.03 for 3 strings and 1.36 for 4 strings. The overpower loss on the second case may be significamt.

Already asked by many users ! However it is not simple: unlike most 3D programs, the PVsyst shading 3D data are constructed with a very strict structure (the "native" data are elementary objects with their sizes and position/orientation, which are reconstructed and repositioned by the program at each execution). This structure is very difficult to reconstruct from other unstructured data in an automatic way. Unless we ask the user to construct his objects in Autocad with very rigid rules, which withdraws 99% of the interest of the Autocad import facility ! (and checking the topology and the integrity of these data would be a titanesc work). On the other hand, architect drawings usually include many details not relevant for the shading calculations. Then PVsyst cannot deal with too complex objects (the calculation time grows with the square of the number of elements), and will probably have to simplify the drawings. However we will start soon to study the possibility of a link with Sketchup. If it is really feasible, this should not be available before several months (autumn ?).

I'm not sure that for the usual use of PVsyst, i.e. long-term forecast of PV yield, we gain much accuracy with sub-hourly simulations. The first reason is that with grid-connected systems, the global system's behaviour is very linear with the irradiance. The only differences in yield may come with non-linear effects, the main one being the operation in over-power conditions. Any other effect (including the shading effects) will be averaged over long periods, so that the final result will be very close. Now Meteo data in sub-hourly values are very scarce: they usually only concern on-site measurements or research projects. This restricts the use of sub-hourly simulation to the close analysis of measured data. Probably the articles mentioning a better accuracy essentially concern these cases (i.e. the "instantaneous" accuracy). Passing to sub-hourly values is not just a question of memory or calculation time. Implementing simulation in sub-hourly values in PVsyst is not a straightforward task. Many fundamental options and organizations in the program are based on the hourly steps choice. Passing to sub-houly values would imply to completely review the "physical" variables organization in the program (which is not simple), the tables, data storage, data presentation, etc... This would represent many hundreds of working hours, and we have other priorities in the pèresent time.

Thank you for this information, I have corrected this for the next version 6.04 (to be released within 2-3 weeks). This is only a problem of display, this doesn't affect the simulation results in any way. In the meanwhile: the IAMLoss is the sum of IAMBLss + IAMDLss + IAMALss (Beam diffuse and albedo losses).

The Satellight site is indeed again available. (when you register on the site, don't use special characters in your name or address, as they are not accepted, but without notice!) The format of these files has slightly changed. They are no more readable correctly by the old versions of PVsyst (the longitude becomes equal to the latitude, which has strange consequences...). I have corrected this for the versions 5.65 and 6.03, released just today.

Yes you can import data from your own measurements using POA (but you can't use a diffuse measured in the plane of Array). In this case be careful with the time definition, already at the import time (see "My transposed POA values don't match the imported values"). PVsyst will then calculate (for each hour) GlobH and DiffH values which will restitute exactly your measured POA values if you use the Hay model. For the second question, it is just an example (DEMO). In the data of PVsyst (folder \UserData\), I have included 2 meteo files Geneva_PVsyst_Std_GHI.csv and Geneva_PVsyst_Std_GPI.csv with respectively Global horiz. and Global plane(POA) values, as examples. These format protocols are the particular ones suited for reading each of them. NB: these files are also here as an example of the specific standard format I have specified for meteo import in PVsyst.

This is a completely different question. If you don't avail of measured hourly temperatures in your datafile, don't define a column with monthly values. When temperature reading is not specified in the importing format protocol, at the execution of the importation the program will ask you for Monthly values (which you can take from another near site), and will generate hourly values using the usual model for synthetic hourly generation (see "What are Synthetic Hourly Data ?")

The transposition is highly dependent on the diffuse part. And the models for the diffuse are usually rather coarse. However the calculations in this tool are only meant for a quick evaluation when you are choosing an orientation. They are computed very quickly using a simplified algorithm based on the Montly meteo data (calculation of 3 average days for each month). Please don't use it for accurate evluations. The tool in "Tools" / "Transposition Factor" provides more accurate optimizations, evaluated on the basis of the hourly data, and for different conditions (different months, eventual horizon shading, etc).

The shading scene is stored within the "Calculation Version" file (*VCi). The opportunity of saving shading scenes as *.SHD is useful for intermediate saves when elaborating a complex scene, or for reusing the scene in another project.

Please exit PVsyst and renter it again: sometimes the internal lists are not refreshed.

The version 6 is a major release of the software PVsyst. Warning As in most complex software, deep modifications may lead to unexpected behaviors in parts which were previously stable. Although we intensively check before issuing each issue, it is really impossible to test or re-test every feature of the program, in any situation. Some improvements may have consequences on other parts of the program, and some parts will probably have to be updated according to these new features. Therefore you are asked for carefully reporting the errors you can encounter when using the program, by providing explanations of the problem, screenshots of the error messages, Log files, etc. From V 6.21, there is a powerful tool for reporting crashs of the program to the developers. When it appears, please don't hesitate to accept sending the error report to us. We also encourage any suggestion for the improvement of the software. We list here the main improvements by respect to the previous version 5: "Meteonorm Inside" - Direct search of any location on the earth, using the well-known GoogleMap tool. - Immediately get the monthly meteo values for any site, using the interpolating possibilities of Meteonorm 6.1. - Synthetic generation of hourly values uses now the Meteonorm algorithm, improved by respect to the old PVsyst algorithm. - Included import of meteo values from new databases, for example SolarAnywhere (SUNY model) satellite recent data covering the whole USA. - Transposition model on tilted planes: Perez model now proposed as default instead of Hay, leqading to an increase of 0 - 2% yearly sum according to climate and orientation. New Project management and simulation process - New Project management Dashboard, with direct access to all parameters, simulation and results in a single dialog. - Improved project management: copy, saving, transfers of calculation versions from projects to projects, copy of full projects. - Losses: new organization of the loss diagram. New losses like LID, System unavailability, Inverter auxiliary or night consumption, Light-soaking gains for CIS. - Batch mode for parametric studies: allowing to vary parameters in an EXCEL document, and get chosen simulation results of multiple runs as a table. Improved shading calculations - Direct shading factor calculation during the simulation (avoiding the interpolation uncertainties in the shading factor table). - Optimization of the calculation of the shading factor, allowing calculations of big PV plants without limitation to some hundredth of trows or trackers (factor of 10 on the speed). - Plants following the terrain, imported by Helios3D: analysis of the spread of orientations, management of the orientation average. Detailed electrical shading losses - Refinement of the "module layout" part, which allows to define the position of each PV module on the areas ("tables") defined in the 3D shading tool. - Modules arrangement in portrait or landscape, sub-modules in length or width within each module. - Attribution of each module to a given string and inverter. - Detailed calculation of the I/V characteristics under partial shadings in each Inverter input, either as pedagogic plot, and during the simulation for the determination of the "electrical losses" due to the shading mismatch. PV modules - Tools for specifiying low-light performances, and adjustment of the Rserie parameter accordingly. Low-light efficiencies may be included in the parameters in the database. - Modification of the default values for Gamma, when Rseries is not explicitely defined by the manufacturer, giving significant higher yields of 2-3%. - Import of a measured I/V curve for the establishment of the model's parameters. - Sandia model implementation, and comparison with the one-diode model. - New parameters: IAM profile in the module's parameters, Vmax(UL) for use in US, full tolerance definition, LID for crystalline and Light-soaking for CIS. - Easy choice of modules by manufacturers. Inverters - Multi-MPPT with unbalanced inputs - define main and secondary inputs. - Additional parameters: transformer specification, CEC average efficiency for US, auxiliary and night losses. - Easy choice of inverters by manufacturers. Software Installation and Background - New file organization, with clear distinction between internal database and custom files. - New data management, easy copy of the the full custom data set from previous installations, no problems of Administration rights anymore. - Certified installing package by PVsyst SA, registered in Windows. - Easy automatic updates. - New protection management. Some main novelties in the versions up to 6.22: - Multiple orientations, up to 8 different possible orientations, with correct shading calculations. - Improvement of the diffuse shading calculation with tracking (and especially backtracking) systems. - P50/P90 probability évaluation of the simulation result. - Power factor, grid power limitation. - Easier definition of 3D shading fields, directly with modules. Tools for easier Module Layout management.

For the near shadings, there is a Tutorial with an example in the help ("Overview" / "Tutorials"). For the Module Layout, we did not write a tutorial up to now, but the procedure is described in detail (step by step) in the Help of the version 6: "Project design" / "Module Layout" / "Summary of the Procedure".

I really don't understand what you want to do. - For analyzing the behaviour under different irradiance classes along the year, you can do an histogram (see for example in the results "Predefined graphs", "Incident irradiation distribution" or "Incident energy distribution"). - In hourly data you cand choose hours with a given POA Irradiance (for example 500 W/m2). Now if you want to manipulate the input hourly data for getting specific values, you can do this in an EXCEL CSV file that you will import using "Import ASCII meteo files". But be aware that if you specify for example an irradiance of 500 W/m2 (GHI): - If the diffuse is null, the system will receive a beam of 500 W/m2 * cosi/cosHsol (where i = incidence angle, Hsol = sun's height ) - But the diffuse is never null, and the resulting irradiance on the array will be the result of the transposition model.

Yes, PVsyst doesn't understand the dot within a filename (except the dot of the extension of course). Please simply remove the dots (and other eventual special characters) and everything should be OK.

As they are connected in series, all the cells in the module are submitted to the same current. Now if this current is forced over the Isc of a given cell (horizontal line on the graph above), this cell is reverse-biased and "consumes" power (positive current, negative voltage).

PVsyst puts a default value of 1.5% for the array ohmic loss. It is an reasonable initial guess for your first simulations of a system. But after that you have of course to estimate your real array wiring resistance according to your own cabling options. There is a tool for helping you in this task.

I just defined the "Unbalanced" option for inverters that I knew. Now most of the inverters of the database were proposed by their manufacturers before defining this feature, and they didn't mention this capability. You can of course define this by yourself in the Inverter's parameters.