André Mermoud

You cannot identify peak values over 15 minutes interval, as PVsyst only performs simulations on 1-hour time step data. However an indirect way would be to identify the peak irradiance in your original 15-minute meteo data. As the output of a PV system (without Power limitation) is very linear with the input irradiance, you can calculate the ratio E_Grid/GlobInc for a similar hour in your hourly data, and appliy this ratio to the 15-minutes peak irradiance. NB: you can get a table of the maximum hourly values for each month and each hour of the day in the results "Tables" / "E_Grid hourly averages". Here you can choose Maximums instead of averages.

If the shade was very sharp (shading object very close), only a contribution of 3 cm width would affect the elecrtrical mismatch. The concerned cells are not completely shaded, and the shade contribution will be around 3 cm/15.6 cm, i.e about 20% of the full beam. Now the apparent diameter of the sun as seen from the earth is 0.54° (Sun's diameter is 1.4 Mkm, sun-earth distance is 150 Mkm). Therefore the shade of one point at 50 m will be a patch of about 50m * sin(0.54°) = 0.47 m. The shade of this 3 cm wire will be spread over around 50 cm width. This will cover several cells, and will not produce significant electrical mismatch losses. The shading effect will therefore be limited to the irradiance deficit, i.e. the "Linear shading" corresponding to 3 cm width obstruction. As a conclusion, at this distance you should use the "Thin object" option for this wire, but with a negligible contribution (1%, i.e. the minimum allowed in the program).

It seems that several people have developed their own techniques for using data from external drawing software. Few of them are publicly available. Here at PVsyst, we are on the way of developing the import of terrain drawings from AutoCAD, as well as the positioning of tables of modules on this terrain within PVsyst. This should be available within some few months. But we didn't yet study the possibility of a general import of full scenes or shading objects from AutoCAD.

We are on the way of developing the import of terrain drawings from AutoCAD, as well as the positioning of tables of modules on this terrain. This should be available in PVsyst within some few months.

When importing this module: The main problem in your definition is the number of cells in series. Of course a thin film module is made of cells, each cell being a long strip (usually 10 mm width). The one-diode model is applied to one cell (between 0.4 and 0.5V for CIS), which is the module voltage divided by the number of cells. If you apply the one-diode model to the full module voltage, it will obviously completely fail. The CIGS is very similar to the CIS technology. In PVsyst they are not distinguished. The negative temperature coefficient is due to your wrong number of cells. When defining the correct number of cells you will be able to correct for getting the specified muPmpp value. But the muVoc is not adjustable (see out FAQ How to adjust the Voc temperature coefficient ?. NB: the NOCT is not defined in the database of PVsyst (see the FAQ How to adjust the NOCT value ?.

There is a way of exchanging the PVsyst component data (Geographical sites, PV modules, Inverters, Batteries), with an EXCEL document in tabular form (one line for one component). The concerned file is named "Components.XLS", stored in the installation directory: c:\program files (x86)\PVsyst6\DataRO\PVsyst6_data\UserData When using (modifying) this file, you are advised to save it in your PVsyst data workspace: ...\User\Documents\PVsyst6_Data\UserData\ The procedure is fully explained in the Excel document, page "Help". Basically, if you select a whole line in the EXCEL document, you will get a button "Import from table" when opening a new component in PVsyst. Inversely, in the PVsyst definition dialog of these components, you have a buttin "Export to Table". In the component's list ("Database" part), you have also a button "Export", allowing the selection of several components at a time.

This is typically a time shift between the time definition of your data and the internal time of PVsyst. Please analyze your meteo file in "Meteo tables and graphs" / "Check Data quality". You have detailed explanations in the help "Geographical and Meteorological data > Hourly meteorological data > Hourly meteo data quality check" and " >....> Time shift".

The calculation involves curve approximations in some cases, and there may be some calculation artefact errors. Now 0.5 kW/800 kW represents 0.06% error. If this arises, say, 100 times in the year, this will represent 50 kWh. Your installation will probably produce around 1'000 MWh/year or more. Does really an error of 0.005 % affect your financial balance ? However I will analyze this situation when I will have some time.

No, there is no way for importing nor editing a shading factor table in the present time. The shading factor table is a result of PVsyt shading calculations, it doesn't make much sense to modify it explicitely.

Yes in principle the ZIP file contains the project *.PRJ, the meteo file *.MET, the variants *.VCi, and the components which are not present in the original database. Please check that your project contains indeed sohttp://forum.pvsyst.com/index.php?sid=9a56d2e74fa0a16b827fcf5adc6152afme saved calculation versions.

It depends where you are. In the US territories, you have some providers for recent data (SolarAnywhere). But for other places in the world, the only data I know are SolarGIS, 3Tiers, or perhaps Helioclim. These data are for pay. You can try also the meteorological service of your country.

For the 1990 reference in meteo data: please see the FAQ How to obtain meteo data other than for 1990 ?

Please see the FAQ How to get previous versions of PVsyst ?

You should use the tool "Database" / "Import ASCII meteo files".

Yes, there were many improvements and corrections between these 2 versions, including in the simulation process. You have a list of all the modifications in the program on our site www.pvsyst.com, "Software" / "Software developments".

Sorry, PVsyst can only work with one hour time steps. This is a fundamental choice.

Please see the help " Physical models used > Grid inverter model".

As I explained in the last post, you have to use "Databases" / "Meteo tables and Graphs", and open "Tables" with hourly values. In the table dialog you have the opportunity of exporting the data as a CSV file for the whole year.

The module layout is based on the 3D scene. It only becomes active when there is a valid 3D scene defined.

For exporting a meteo file, please use "Databases" / "Meteo tables and Graphs". Here you can get a table of the data in hourly values, and export it as a CSV file. NB: By contract with Meteonorm, the files obtained from Meteonorm 6.1 (internal Meteonorm tool) are not exportable. You should choose another meteo data source.

This has been fixed in the version 6.24.

I don't know how you are cooling your module to 12°C at sun, without consuming quite a lot of energy. There is one (indirect) way of fixing the PV module temperature: you can specify the TArray in the Meteo file (usually the measured on-site temperature), and use it in the simulation. For this you should export your Meteo data as CSV file, add a column for the temperature, and reimport it into PVsyst with this information.

The synthetic generation is a statistical model, based on the real measured data of dozens of sites. The elaboration of such a model is very complex, and it required very sophisticated checks. It is not possible to modify it, by addin such "fuzzy" conditions. The only way for your evaluation is to use really measured hourly values.

In the DC part: you should check the "Default" checkbox. And if the default value doesn't meet your requirements, you can modify it in the "Hidden parameters", "System design parameters", item "Default wiring resistance loss ratio". For the AC part, there is no default and I don't see how to specify a stable loss whatever the power in the present state.

This is indeed a very special case, probably the only one implying a random parameter. We have to allow some new parameters to be varied in the batch mode. We will think about that.