André Mermoud

If so this it is a bug. However there are so much possibilities with custom ASCII files... Please send us the original data file, the corresponding *.SIT file, as well as the *.MEF file you have used for this import. Please address them to support@pvsyst.com.

Yes, if you are using the tool "Databases > Import ASCII meteo data", you have the opportunity of importing Array temperatures in hourly values. And afterwards, to use these values during the simulation.

The clear day model is well established, and represents thre real data with an accuracy of 2 to 3% (depending on the Linke coefficient). If you have measured data far over these values (daily sums), either you are not using the correct solar geometry (the latitude or altitude is incorrect), or your data are not correct. I can't see any other possibility. This is physically impossible. NB: It is possible to measure temporarily high irradiances, up to 1300 or even 1500 W/m2 perpendicularly to the sun. This is due to a bright sun cumulated with a reflexion on a neighbour cloud. But these are transitory phenomenons, during some few seconds or minutes. Never a full day.

No sorry, we did not yet have time for developing this.

Importing "Plane of Array" (POA) data is not possible with daily values, because we don't have any model for creating a random distribution (synthetic hourly data model) from POA values. The error message is probably erroneous.

Yes, sorry. The import of ASCII measured data (for a system) don't work in the versions 6.60 to 6.68. This will be corrected in the version 6.69. NB: This concerns System data import (creation of *.DAM files). The import of Meteo data works correctly.

For the temperature evaluation at eac hour, PVsyst doesn't use EffArrC nor EffArrR, which are yearly averages, and for the whole system. It calculated a first evaluation of the Tarray with the STC efficiency. Then it recalculates the PV module output at Geff and evaluates the real efficiency at this temperature. Finally it will use this efficiency in the temperature evaluation (i.e: one iteration).

We update the database using the requests of the manufacturers, and publish it with each new issue of PVsyst. We can't of course follow all the new products of all manufacturers. It would be very big task, and we don't want to include data without the acknowledgement of the manufacturer. Therefore, please ask your provider/manufacturer to take contact with us for updating the database. The database of PVsyst holds now about 13'800 PV modules and 4'800 inverters. Nevertheless you can easily create your own components by yourself. The easiest way is to choose a similar existing device in the database, modify its parameters according to the manufacturer's datasheets, and save it under a new name, therefore creating a new file in your database. For Crystalline modules, except Isc, Vco, Impp and Vmpp, nb of cells in series and module sizes, you can let all the other parameters (mainly Rserie, Rshunt, Rsh(0) and RshExp) at their default value. You have a checkbox near to each parameter for retrieving the values proposed by PVsyst.

If your system is a tracking system (one axis), you have indeed the following variables in the variables list: - Tracking plane tilt - Tracking plane azimuth - Tracking phi angle

Sorry, these 3 additional lines in the report are in development. It was a mistake that they appeared in the version 6.68 (also the GCR os incorrect: expressed ar ratio instead of percentage). . This will be correct in the next version 6.69.

The only way of estimating the Uc and Uv values corresponding to your site is to avail of on-site measured data (Tcell, Tamb, Gincid and Wind velocity). Theses measurements should be performed in hourly values (or sub-hourly), and cover a significant period, representing all meteo situations (ideally several months). The Uc and Uv values will then be derived from these data by a bi-linear fit. Now what you are doing here is to use the PVsyst model (which involves the Uc value, and Uv=0) for trying to evaluate Uc and Uv values (that you are "supposing"). This doesnt make sense: It's the snake biting its tail. The only thing you are doing here is to check the calculation of PVsyst. And of course, if you don't use the exact calculation mode (variables) used by PVsyst, you will have different results. NB: The Uv = 20 W/m2K that you have chosen here corresponds to a semi-integrated system. Please carefully read the help "Project design > Array and system losses".

The 4th decimal is really not significant here. A limit of 27.2 or 27.17 MW will probably have exactly the same results.

The basic information is indeed the cables resistance, as seen from the input of the inverters. You should calculat this using your usual electrician rules. The STC percentage is only a simplified way of defining a "reasonable" value for a new project. You don't need to calculate it (it will be calculated automatically when you will enter the cable resistance).

It is one module in the width of the shed of course.

Easy to imagine for a simple system. Most of the PVsyst projects use several inverters (sometimes dozens or hundreds of string inverters), connected to several kinds of sub-array (sometimes different sub-arrays on the MPPT inputs of a given inverter), etc. We are preparing such a tool but this is extremely complex in the general case. This tool will not be ready before several months.

Do you really think that PV plant managers will adjust the tilt of their PV array 8 times a year during 20 years ? By the way, the differences (gains) are probably very low. You can easily evaluate them by performing the simulation for different tilts, and gather the monthly results by choosing different monthts in these simulations.

1 - Is there any difference between simulation and reports in evaluation mode VS licensed software ? The capabilities of the software are exactly the same in "Evaluation mode" and in the the licensed mode. 2 - But at the reports, production of two systems was the same. In the simulation, the production result is mainly related to the STC specifications of your modules. If these are the same the result will be the same. In real, mono string is producing 7% more energy. So what could be the reason ? I don't know what allows you to affirm this. If the production is 7% better with Mono crystalline modules, it is because the STC values of these modules are 7% better. Do we need to use paid weather data ? It depends on what you want to do. An evaluation from Meteonorm V7.1 is quite sufficient for the first evaluation and the optimization of your system. Now paid data (especially for a set of 10 + years) may indeed be useful if you want to estimate the evolution along the future years (P50-P90 estimation). But nothing ensures that these data will better represent the present and future weather. Paid data for a specific year are useful also if you need real data for the present time, for a direct comparison of your simulated data with respect to measured ones.

You can do different simulations. You can use the "Batch mode" for doing several simulations at a time with different situations, and gather the results on an EXCEL document. There is a "ready-to-use" tool performing this optimization of sheds (choose "Advanced simulation > Optimization tool").

We have completely rechecked the import of SolarGIS data for the next version 6.68, to be released very soon.

I can't understand that. Please try again, using "Databases > Geographic Site > New". And make sure that before saving your site, the data are indeed what you have specified. The site will be saved when you click "OK", and at this time you can check the filename.

Probably you are using a very old version of PVsyst (V 5), where I think I remember that there were indeed no sites in Brazil. In the present version, the native Meteonorm 7.1 database shows 14 sites in Brazil. And of course, you can always choose any location using "Databases > Geographic sites > New", and here either choose a location on the google map, or define it by its GPS coordinates.

If you choose the option of applying the limit at the injection point, you will very probably obtain a clean output E_Grid of 27'200 kW.

We intend to improve this situation in the future. But this is really not simple, and it is not in our priorities.

In the present time, PVsyst only allows to define a simple output circuit, with one transformer. The loss is expressed in terms of percentage of the Peff (corresponding to STC) value. Now if you have several transformers, the easiest way id to simply add the ohmic loss (in terms of percentage) of the first and the second transformer. Working explicitly on the resistance of the transmission lines is also possible, but more complex. You should define an "equivalent" resistance (as "seen" from the output of the inverters) of the circuits before the first transformet, between both transformers and up to the injection point, taking the voltage ratios into account.

The use of "AC modules" has indeed been implemented in PVsyst since several years. For the association (PV-module - Micro-inverter), the remarks of the AC module should mention: "AC module (with LM305UE-G1 (240V) AC module of LG Electronics)" and inversely the remarks of the inverter will mention "AC module (with LG 300 A1C-B3 ACModule 240V of LG Electronics)". However only one device has been proposed by manufacturers up to now. This is the LG Electronics LG 300 A1C-B3 AC Module 240V (or --- 208V). When choosing this device, the corresponding micro-inverter LG Electronics LM305UE-G1 (240 or 208V) is automatically selected. In the sub-array, please make sure that you define the same number of inverters than the number of modules.