André Mermoud

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.

No sorry, there is no possibility for identifying the PV module's parameters used in a simulation. This is indeed a weakness of the result's report of PVsyst. I have to think about some solution, but it is really not easy ... By the way the parameters of the PVsyst database are proposed by the manufacturers, and may also be "biased" (although I try to have some control on this, see What explains the difference of yield between different modules?

The PV array is sized in order to provide sufficient energy during the worst conditions along the year, therefore based on the worst days series in your weather data. Now if you diminish the autonomy period, the probability of "bad weather" series will significantly increase on short periods, therefor requiring a higher PV power. In other words: if you have 2 day autonomy, your PV array should be sized for ensuring the energy needs during the worst 2-days periods of the year. If you have 10 days, the probability of better days duting this time is much higher. In practice, PVsyst proposes an autonomy of 4 days. This may be slightly diminished in southern countries (but not less than 3 days), and significantly increased in northern countries with highly marked seasons. When you undersize the batteries, they will work more. Then, the price of the battery pack is not only the initial investment, but also related to the ageing, i.e. the number of charge/discharges (replacement costs). On the other hand, if you design a very big battery pack (more than 10 days), the PVsyst calculation will propose a reduced PV power, and the batteries may stay in discharged state during long periods, which is also not goos for their health. With the present cost of PV modules, it is wise to slightly oversize the PV array.

In the main menu of PVsyst, please use "Files" / "Import database components". Now if you want to put these files manually, a detailed description of the data structure is available in the help "Technical aspects > File organisation > Directories contents"

No sorry, this is not possible in the present time. Writing simulation parameters is a difficult task as there are many different ones, for each kind of system or simulation choices. The CSV hourly file refers to a given "Variant", and the parameters are on the report of this simulation report. In the version 6, you have now the opportunity of performing simulations in Batch mode. You can define some varying parameters on an EXCEL document, perform the concerned simulations and get chosen results on the EXCEL document, thus allowing for direct parametric studies in EXCEL.

As explained in the FAQ referenced above, you have many different strategies when mixing solar system, batteries and grid. In your case the batteries may be charged either by the solar array or by the grid. Which will be the conditions and strategy for chooosing one or the other source ? The batteries will probably feed only emergency circuits in your system, involving a double-circuit in your building. How to define these needs ? When the batterie are full the solar array will inject its energy into the grid - through which kind of inverter ? (probably a standard grid-connected), In case of a weak grid, how to model the grid unavailability ? etc... Such an installation and operational conditions are too complex for being defined in a general software like PVsyst in the present time.