André Mermoud

No. PVsyst is only able to treat data of at most one year at a time. Several years will give rise to several meteo files (*.MET files), and therefore several Simulation runs. After performing these simulations you can average the results if you want. Please note that the TMY2/3 databases don't provide 30 years of data, as often believed.

The simulation is based on an hourly data file (*.MET). When only monthly values are available, PVsyst generates hourly values according to a model in a stochastic (random) process. For irradiances, PVsyst uses the "Collares-Pereira" model, which generates a series of daily irradiations, and then hourly irradiances within each day, using fully stochastic process (Markov matrices). This model tries to reproduce irradiance time series, with a statistical behaviour analogous to measured values in several sites in the world. The result will be a synthetic hourly year, which is completely different from one execution to another one. During simulation of a grid-connected system, the differences on the yearly yield may be usually up to 0.5 to sometimes 1%. The effect will be higher when simulating systems with non-linear beghaviour like stand-alone. For temperatures, as the temperatures are mainly governed by atmospheric circulations rather than irradiation, we don't have any model relying the daily temperature to the irradiations. Nevertheless the temperature within a given day is rather well correlated to the irradiance. It takes a rather sinusoidal shape, with an amplitude about proportional to the daily irradiation, and a phase-shift of about 3 hours. In absence of a day-to-day model, the passage to the next day is randomly modified in order to obtain the required monthly average and a reasonable amplitude. Therefore, the model waits for the "meteo" monthly average temperature (24h)" (not the Daytime average !), and irradiance data. For constructing a Synthetic Meteo file, please use "Tools" / "Synthetic Hourly Data Generation". When choosing a site within a project, PVsyst will automatically create the corresponding Synthetic file if there is no corresponding file in the \Meteo\ database elaborated by Meteonorm. NB: The Collares-Pereira model has been established in the 1980's, when the irradiance was not so well understood as nowadays. To my knowing nobody has published about this model since these early researches. The version 5.xx of PVsyst uses this original version of the model. However the Meteonorm team has significanntly improved the model, and implemented it in the new Meteonorm program. The version 6 of PVsyst makes use of this new version of the synthetic generation model.

You can import hourly or daily meteo data from almost any Text (ASCII) file, provided that there are data of one recording time step on one line. For this please use "Databases" / "Import ASCII meteo file" and press F1 for getting the detailed procedure. After importing, please carefully check the quality of your imported values, especially their time definition, with the tool "Meteo tables and Graphs" / "Check data quality". You have information about data quality in the help (typing F1): "Geographical and Meteorological data > Hourly meteorological data > Hourly meteo data quality check".

PVsyst is only able to perform simulations starting from the Horizontal irradiance GlobHor. This is motivated by the fact that we only avail of models for estimating the Diffuse irradiance in the horizontal plane (the diffuse irradiance is used namely for transposition model and shading or IAM calculations). Therefore starting from Plane irradiance (POA) requires first to perform a retro-transposition for getting the horizontal global and diffuse irradiances, which will lead to the specified POA after transposition. This uses the Liu-Jordan (or Erbs) model for the evaluation of diffuse. When using these data, the simulation should retrieve the exact input POA value. If this is not the case, it indicates that there was a problem during the import process. The usual problem is a time shift between the measurement time and the PVsyst time. If the measurements are not accumulated at the exact time (for example between 9:00 and 10:00 for the PVsyst 9:00 step), the solar geometry is not computed at the right time (middle of the interval) and the transposition my lead to very high errors in the morning or the evening, i.e. when the sun is low on the horizon (as the POA irradiance is divided by sin Hsol). This may lead to very high erroneous horizontal Global, which will be limited to the clear day model. In these cases a Time shift correction should be applied, already during the import process.

In PVsyst I have taken the convention of always labelling the beginning of a time step (8:00 corresponds 8:00 to 9:00 average). This allows to label the hours, days or months in the same way. Now if your own data are referred to the end of the hour (or other time step, you have an option in the importing format for taking this into account). See My transposed POA values don't match the imported values in this forum.

I have done a comparison between the different sources of data imported in PVsyst, and available for Europe: we can observe a discrepancy of the order of +/- 10 % (yearly sums) between all these sources, and this is of course the first uncertainty of the PV production forecast. This comparison is available in the PVsyst help "Geographical and Meteorological data > Import from Meteorological data sources > Meteorological data comparisons", or summarized on our site http://www.pvsyst.com. The differences may be attributed to the different years or periods concerned (climatic variations), the accuracy of the mesurements (sensor calibration, or models for satellite data), the quality of the data recording, etc. For example, the European climate has significantly evolved: we observe an increase of the order of 5% on an average since the beginning of this century in all measurements. This is namely apparent with the PVGIS database: the new SAF irradiation measurements (based on recent satellite data) are about 5% over the "classic" data from terrestrial measurements of the ESRA project (1981-1990). I don't have such a study for other regions of the world. For the USA, the TMY3 are probably reliable data, based on 1961-1990 measurements, and used as reference by everybody. A new database managed by the NREL (SolarAnywhere - SUNY model) provides recent satellite data for the whole territory. The direct import from this database will be available in the version 6, but you can already import these data as ASCII files in the present version. Please also refer to the works of Pierre Ineichen, available on our site http://www.pvsyst.com: "Global irradiation: average and typical year, and year to year annual variability", Ineichen, P., 2011, Research report of the Institut of the Environnemental Sciences, University of Geneva. and "Five satellite products deriving beam and global irradiance validation on data from 23 ground stations (IEA)", Ineichen, P., 2011, Research report of the Institut of the Environnemental Sciences, University of Geneva. Now please observe: we can have some quality criteria. But probably nobody knows which source is the most reliable, and which one will represent at best the future climate of a given site !

It is often believed that the TMY2/3 databases provide 30 years of real data. This is not true. The definition of "TMY - Typical Meteorological Year" (or "DRY - Design reference Year") is a one-year data construction, which gathers pieces of measurements (2-4 weeks) picked up from usually 30 years of real measurements, in order to construct a representative year for systems sizing or building thermal behaviour analysis. This construction obeys precise rules, and aims to provide an average year, but including some extreme values. The TMY3 are constructed using more recent data than the TMY2 (1991-2005 against 1961-1990 respectively). Please refer to the NREL site for TMY3 data. Now if you can get some real years of recent measurements (for example from SolarAnywhere of NREL), you can do the simulation for each available year, and then average the results (on a monthly or yearly basis).

The global irradiance is always a sum of the Beam, Diffuse, and Albedo components. With meteo data (on horizontal plane) there is no albedo of course, as the horizontal plane doesn't "see" the surrounding ground; therefore GlobH = BeamH + DiffH. If the global and DNI are available in the data, but not the diffuse, PVsyst calculates the corresponding Diffuse component from these data, and at execution the specified DNI will be restituted. Now if Diffuse and Beam (horizontal or DNI) are both specified in a dataset, there is a redundancy. The DNI can be deduced from the GlobH and DiffH (it is a definition, using the solar geometry, and doesn't imply any physical model). If there is a discrepancy with the DNI given in the file, it is an inconsitancy in the data, and PVsyst has no mean for managing this of course.

The format of the data structure obtained by "Copy" has indeed been changed with Firefeox V 13 (mid-June 2012). I have adapted the importing tool in the version 5.58 of PVsyst. Therefore please update PVsyst, or use another browser !

In the optimization diagram obtained by "Tools" / "Transposition Factor", the optimum may not be at azimuth = 0°. First please observe that this optimum is extremely flat: a little deviation is not significant concerning the actual value of the transposition Factor. Now this may have several causes: With Synthetic hourly data, the optimum shoud theoretically be centered. It is indeed often slightly shifted towards west, probably due to an insignificant anisotropy in the Collares-Pereira model ? With measured values in hourly values: - If ground measurements, there may be an horizon shading, either in the morning or in the evening, - Weather asymmetries like morning smogs (West shift) or evening storms (East shifts), - With your own measurements, there may be a time shift in your recorded data by respect to the PVsyst time, - With original POA measurements there may be an inaccurcy in the solarimeter orientation definition. NB: This tool deals with irradiance only. The temperature of the array - which is higher in the afternoon - is not taken into account in this optimization, and could deviate the optimum towards east.

In PVsyst, the import of POA values uses a retro-transposition (with Hay model) and creates a file with GlobHor and DiffHor hourly values. During the simulation, the transposition should indeed restitute exactly (within epsilon) the input POA values, provided that the input data are correct and correctly imported, and you use the Hay model in your simulation. An error in the time defintion may produce very high errors in the morning or the evening, when the sun's height is low (as the POA beam has to be divided by sin(Hsol)). In case of errors the horizontal beam in the early morning may become several tausends of W/m2... PVsyst limits it to the Clear day model, and this is the main source of your "errors". (I have event seen POA bad data with significant values before sunrise or after sunset... ) Please carefully check your meteo file using "Tools" / "Meteo Tables and Graphs" / "Check data quality". If there is a time shift you should correct it already at the import time (as the retro-transposition depends on the solar geometry of course). You can also verify whether your POA and transposition values are identical: - Either using the Table in Hourly values, and display both POA and Transposed values - Or with this table, by producing a CSV file and check (in EXCEL) which hourly values are not identical: these will only be morning or evening values! For correcting the time step you have several possibilities: - The importing format protocol has a specification "Interval Beginning" and "Interval End", corresponding to the time step definition of your original data. NB: If your data time step is less than 1 hour, this will act on the interval itself (i.e. produce a time shift of 5 minutes for 5 min steps). - You can change the timezone of the site used as geographic reference. - You can eventually shift the column of hours by one hour in your original data file (be careful with 24H00 and 0H00), - Please make sure that you have defined "Legal Time" and not "Solar Time" as time base. "Solar time" is the time definition for which the sun passes through south at 12:00 (days don't have 24H anymore). It is never used. Additional information You will find more information in the help of the software: "Meteo Database > Notes on Meteo > Meteonote8_Hourly data quality check" and " ... > Meteonote9_Time shift in meteo files". Or simply press F1 from the "Check data quality" page.

Sorry, I will correct this for the next version.

You can use the "Financial balance" option only when you have completely defined the Investment and financing part, which is the starting point of the long term balance.

You should use the "Tracking Tilted or Horizontal N/S axis" option. Your axis is N/S , not E/W oriented.

The counties listed in the definition of a geographic site are just a list of the countriesof already defined sites in the database. If you create a new site and don't find your country, you can simply type it in the ComboBox.

I have done a comparison between the different sources of data imported in PVsyst, and available for Europe: we can observe a discrepancy of the order of +/- 10 % (yearly sums) between all these sources, and this is of course the first uncertainty of the PV production forecast. Please see the FAQ What is the accuracy of the different meteo data ? And I agree with Marvin: nobody knows where is the truth (if truth exists) ...

There is necessarily a combination of Time zone definition and time shift which should match the internal time of PVsyst. This is defined as the beginning of the interval (8:00 means the period of 8:00 to 9:00). If you have constructed an hourly file from 5 min data, you can define the hours in this way, and therefore the time shift should be 0 (you have put 30 min). You can also change the time stamps of you data (i.e. just shift the column of hours by one hour - i.e. one cell). You have specified GHI (Global Horizontal) irradiances, when you have defined a plane of 50° tilt: is your irradiance measured with a solarimeter in this plane ? In this case you shoud define GPI (Global plane Irradiance, or POA), and not GHI, so that PVsyst understands that this is an irradiance oin a tilted plane. But this is not the best suited tool for importing your data: the "standard format" of PVsyst is meant for representing a full year of clean data (i.e. from "official" database"). You should use "Tools" / "Import ASCII meteo files" instead, which accepts almost any format of data. When in this tool you press F1 for getting the procedure. This tool will accept your 5-minutes data as such, and gather them into hourly data in a clean way. It will also create a file just matching your data (i.e. one month, up to one day, accepting holes, an so on), without the necessity of defining dummy values. And as you don't avail of temperatures, it will manage the generation of temperatures, on the basis of externally specified monthly values. Please carefully read the Help "Geographical and Meteorological data > Import of hourly data ASCII files" and "Geographical and Meteorological data > Import of custom hourly data ASCII files > Conversion protocol".

You are right: I tried to define your pump and did not succeed. There is a problem in the software with the definition of centrifugal pumps using the efficiency as input parameters, that I have to analyse and correct for a next version of PVsyst.

In the PV module: The area is defined as the gross size of the module: Length x Width. Except with tile-modules, where this is may be defined as the apparent area. This is the reference surface for the determination of the efficiency. Now in the PV module you can also define the area of the cells (sensitive area): this is only used for the evaluation of the cell's efficiency, i.e. a characteristics of the PV module technology. The simulation uses the rough area of the modules for the evaluation of the efficiency. In the 3D shading part: In a first step, the areas are defined independtly of the modules: these are generic surfaces which may receive the installation of modules, whatever their size, disposition, and spacing between them. The shading factor calculation is not very sensitive to the real area. These plane areas may (should) be over-sized in order to be sufficient for receiving the modules. When you exit the 3D editor, PVsyst will check that you have defined sufficient room for placing the modules defined in the System part. This should not be less than the total modules area, but may be largely oversized. In a final step (in the future version 6) the layout of the modules will have to be fully defined on these surfaces, in order to compute the electrical effects of the shadings. After this definition the 3D areas will be readjusted to the real position of the modules and their eventual spacing.

Unlike most 3D programs, the PVsyst shading 3D data are constructed using a very elaborated 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 not well-organized elementary data in an automatic way. On the other hand, the shading calculation time in PVsyst is strongly dependent on the number of elementary surfaces defined in the scene. As in drawing software this is not a limitation, people create complex scenes with many realistic details, not relevant for the shading calculations. We have to find some algorithms for analysing and suppressing the useless elements. This is a complex task. We are now on the way of developing the import of Sketchup drawings. This should be available within a few months. But the import of Autocad *.DWG files is not possible in the present time. We are studying the possibility of importing some specific objects like terrain descriptions, or 2D roof layouts (chimneys, technical elements).

Solmetric "SunEye" provides an horizon line: this is a list of (Height/Azimuth) points. You can easily import the SunEye data (file "ObstructionElevations.CSV") in PVsyst, option "Horizon", button "Read/Import". Please be aware that the SunEye results are only useable for defining far shadings (i.e. an horizon line). Shading obstacles are considered as "far" when at a given time the full array may be considered shaded or not: the sun is or is not present on the array. As an order of magnitude, when the obstacle is at a distance of, say, 10 times the array size. For near obstacles - which produce partial shades - you must use the "Near shadings" option, i.e. create a 3D representation of your PV field and its environmnet. The SunEye data are completely unuseable for this. NB: Solmetrics had established a specific file for use in PVsyst. Please don't use this file, which was developed for verion 4 and is not satisfactory.

This is a complex problem indeed. In the years 1990 we had passed a full-day seminar on this question with all involved people in Switzerland (including the Meteonorm team), and did not find any satisfactory solution. With our mountains, meteo measurements in Switzerland are especially concerned with this question of course ! With any ground-measured data, the horizon loss of irradiance is already included in the meteo data. This is very difficult to use because: - the horizon line is very sensitive to the exact location: the horizon at the exact sensor position may be very different of the horizon seen by the PV system. - if applied to monthly values, the synthetic generation doesn't "know" the horizon, and will generate values with beam component below the horizon. Which will be incorrect in the simulation of course. Therefore in any case (except on-site meteo measurements), the horizon data should ideally be horizon-free and the horizon effect should be computed within PVsyst, using the effective horizon line of the site. There is no simple mean for avoiding the problem. With monthly values, we could generate a full year of hourly values, evaluate the loss (on beam) due to the pre-specified horizon of the site, and then add these losses to the monthly original values and re-generate a synthetic hourly file. This file will have better "free horizon" values on which we can apply the real horizon of the PV system. With hourly values, we should reconstruct the supposed beam component below (and behind) the horizon. We have now models for doing this with some confidence (probabilistic continuity of the weather). We have tested these methods, and they can give acceptable results. But sorry, I did not yet implement this special case in PVsyst.

There is no optimal solution. This is a multicriteria choice resulting in a compromise between several requirements. You have to decide which aspect is to be optimized (maximum installed power on the available area, investment, efficiency, amount of energy yield, price of the energy, simplcity and price of the supports, etc). PVsyst provides a pedagogic tool for the understanding of the performances as function of plane tilt and row pitch (for a given limit shading angle): in the "Orientation" part, choose "Unlimited sheds" / "Show optimization". The graph shows the annual yield (by respect to horizontal) for unshaded plane (in green) and shaded system (irradiance or electrical effect). This tool clearly shows that the optimal tilt angle for unshaded plane is significantly reduced when considering the shaded performances. And this becomes dramatically worse when considering sheds not well oriented toward the south. Further, the power which can be installed on a given area decreases when the tilt increases. With 30° collector tilt, you can in general not put more collectors area than 45-50% of the available area. With low tilt angles (around 3°), this increases to 80% or more. The mechanical structures are much more simple with low tilts (reduced wind sensitivity). But the low tilts may induce cleaning problems with rain. You are advised to use frameless modules. NB: for the final optimization of your system, you are advised to perform the full hourly simulation and vary the parameters. You can easily do that by using the "Batch mode" (version 6 only).

Yes, this is quite normal. When you tilt the baseline of a collector (rotating around the azimuth line), the plane "true" orientation will change. For understanding this: please take a cardboard as collector, and position it at, say, 30°south. Then give a tilt to the base (baseline slope). Now the plane azimuth is defined as the perpendicular to the intersection of your cardboard and the horizontal plane. And the plane tilt is the tilt accounted perpendiculary to this horizontal line (i.e. the angle between the plane of your cardboard and the horizontal plane) At the limit of a vertical base line, the azimuth will be (90°-plane tilt) (by respect to original Azimuth if not south). The calculation of these new orientation angles is not straightforward: it implies 3D rotations matrices. But you can trust the proposition of PVsyst... This arises on a roof when the tables are set perpendicularly to the slope, and also when you put tables on a sloped terrain (hill). In the case of a hill, you have usually many different slopes, and PVsyst performs an average for the incident irradiance calculation. You have a detailed tool for analyzing this situation in the 3D shadings editor, menu "Tools > Edit orientations".

This is not a problem of computer performances. 3D shadings calculation In the 3D tool of old versions, the calculation of the shading factor went with the square of the number of elements; the elaboration time of the shading factor table becomes prohibitive above some few tausends of elements. In the version 6, this calculation has been optimized, with a gain of up to a factor of 10 in speed. For using this feature, make sure that in the menu of the 3D editor, the option "Tools" / "Optimized shading calculation" is checked. Since then Version 6.6, this calculation uses the "OpenGL" tool, and this is no more a problem. In your 3-D shading scene, you should not define one rectangle for each PV module. This is not the right way. The "tables" (sheds or rectangles) of PVsyst are generic surfaces, intended for receiving a set of PV modules. You are advised to define each table as big as possible according to the constraints of your configuration. For example, when you have side-by-side sheds, you can define a big one instead. Calculation on partial systems NB: Since V 6.44, it is possible to specify a representative sub-part of the system (for example the input of one only inverter), and during the simulation the shading calculation will only be performed on this sub-system, but applied to the full system. This concerns the "Linear shadings calculation", and the calculation "According to modules strings". This tool doesn't apply to the "Module layout" calculation. However this is no more really useful as the normal calculation is sufficiently fast now, event with very big systems. Advice: with very big power plants, if the configuration is regular (i.e. with flat ground) you are advised to perform your first simulations (for optimization purpose) using the generic option "Unlimited sheds" in the "Orientation" part. In this case you don't have to define a 3D shadings scene, and the calculation will be straightforward. This is for example useful for optimization analysis of the row-to-row distance and shed tilt Module Layout calculation The detailed calculation of the electrical effect according to the Module layout option is also very time-consuming, without possible optimization. This option is not suited for very big system. For multi-MW systems, you should evaluate the electrical shading loss with the "ModuleLayout" option using a part of the system (say - one inverter, i.e. one MW) and extend this to the whole system. Since version 6.67, PVsyst puts a warning for systems over 1 MW, and prevents the definitions of ModuleLayout for systems bigger than 5 MW. This upper limit may be increased in the hidden parameters, topic "System design parameters, losses, shadings". For evaluating the electrical shading loss in bigger systems, you should: - Define a variant with a representative sub-system of your full big system (for example a sub-array connected to one central inverter, i.e. around 1 MWp). - Define the "Module Layout" for this sub-system, and perform the simulation. You will get an electrical shading loss value. - Recaclulate the Electrical losses with the option "According to Module strings" for this sub-system, with "Fraction for electrical effect" = 100%. - Comparing the results for electrical loss will allow to estimate a "Fraction for electrical effect" leading to a same loss value. - You can now define the option "According to Module strings" for the whole system, and apply this new "Fraction for electrical effect".