André Mermoud

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.

I don't understand your affirmation. It is quite possible to define a tracking system with axis tilt = -1° or +1°, event in the 3D tool. There is no restriction here. I know that architects are often using percentages for the tilt. They also use to take the North as azimuth reference. However in most solar applications this is expressed in terms of degrees. It would be very confusing to work in two different units for a such fundamental parameter in PVsyst.

Sorry, this dialog is not always optimal for some complex projects. We are working on the improvement (and refinement) of this possibility, for a next version. But I don't know when this will be available.

In version 6.22, there was an error in the simulation when you are using the "Mixed orientations" on a same inverter, which had the effect of diminishing the Inverter losses. This error has been corrected in the version 6.23. A loss of 0.4% only for the inverter efficiency is indeed not realistic.

We just did this modification as simultaneous running is the cause of many reported crashes of the program. Now there are some files which are permanently used by PVsyst, not only the project's files. We will perhaps try to secure the simultaneous running of multiple instances of PVsyst in a future version.

The lifetime of the batteries is split into two contributions: - a "static" ageing (specified in the battery's component definition). For lead-acid batteries, this is very dependent on the battery temperature: an increase of the temperature results in halving the lifetime. - an ageing according to the number of cycles: this is continuously calculated by the detailed simulation process. The wearing state is a result of the simulation. The economic evaluation doesn't take a controller lifetime into account. The economic evaluation of Stand-alone systems evaluates the maintenance cost as the fourth of the battery price (i.e. a lifetime of 4 years), without any other contribution. This is a very simplified assumption. However in the presizing part, please take these costs with great care: it is quite impossible to give a serious information about the prices in the framework of such simplified simulation and assumptions. The costs are depending on many factors, and specific to each situation (country, time, etc).

This depends on the technology. With crystalline modules, this is the LID (Light Induced Degradation) and may be specified as such in the "Detailed losees" dialog. This loss arises usually during the first hours or days of exposition to the sum. With amorphous, the initial degradation (some months) is not taken into account in the simulation: the STC specified values are supposed to be the stabilized values.

A better accuracy in the monthly values of temperature is not really meaningfull. These Monthly values are not used as such in the simulation. They are the basis for a synthetic generation of hourly values. This process is completely random: with 2 different executions you can have completely different sequences of days and hours within the month. Therefore you will never be able to strictly compare simulations for a same system based on different synthetic meteo data files.

No, because there is no optimum: this is a multi-criteria and multi-variable problem. See for example the article Optimization of row-arrangement in PV Systems, shading loss evaluations according to module positioning and connexions (A. Mermoud, EPVSEC 2012), on our site.

Thank you for the detailed report of the problem. Sorry, the logics for forbidding modifications of the PV module definition was inverted. This is corrected for the next version 6.23.

Thank you for noticing this. I have corrected for the next version 6.23.

I can't understand that. Please check (at the top of the column) that the values are not expressed in W instead of kW. If the problem persists, please send your whole project to Support@pvsyst.com.